HE. Alternative workarounds would be
hacking away UL suffixes with sed or redefining BIT&co but relying on
gdb evaluation is easier and much more flexible.
Leonard Crestez (2):
scripts/gdb: Cleanup error handling in list helpers
scripts/gdb: Print cached rate in lx-clk-summary
scrip
The clk rate is always stored in clk_core but might be out of date and
require calls to update from hardware.
Deal with that case by printing a (c) suffix.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/clk.py | 21 ++---
scripts/gdb/linux/constants.py.in | 4
yield something else.
Applies to both list and hlist
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/lists.py | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
index 55356b66f8ea..c487ddf09d38 100644
ta-schemas/core.yaml#
+
+title: Generic i.MX bus frequency device
+
+maintainers:
+ - Leonard Crestez
+
+description: |
+ The i.MX SoC family has multiple buses for which clock frequency (and
sometimes
+ voltage) can be adjusted.
+
+ Some of those buses expose register areas mentioned in the m
ork.kernel.org/patch/11049429/
That part might not be accepted in clk and it might have to be moved to
devfreq also.
Leonard Crestez (3):
dt-bindings: devfreq: Add initial bindings for i.MX
PM / devfreq: Add imx driver
PM / devfreq: Add imx perf event support
.../devicetree/bindings/devfreq
Add initial support for frequency switching on pieces of the imx
interconnect fabric.
Uses clk_set_min_rate so that other subsytems can also impose minimum
rate requests.
Signed-off-by: Leonard Crestez
---
drivers/devfreq/Kconfig | 10 +++
drivers/devfreq/Makefile | 1 +
drivers
and sum them.
Signed-off-by: Leonard Crestez
---
drivers/devfreq/imx-devfreq.c | 135 ++
1 file changed, 135 insertions(+)
diff --git a/drivers/devfreq/imx-devfreq.c b/drivers/devfreq/imx-devfreq.c
index 3ee2d37883c6..fd4c8ffb8b4a 100644
--- a/drivers/devfreq/imx
pen
Signed-off-by: Leonard Crestez
---
I don't understand why PMUs outside the core are bound to a CPU anyway,
all this patch does is attempt to satisfy the assumptions made by
__perf_install_in_context and ctx_sched_out at init time so that lockdep
no longer complains.
ctx_sched_out ass
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> Simplify clock initialization code by converting it to use clk-bulk,
> devres and soc_device_match() match table. No functional change
> intended.
Subject is misspelled.
> +struct clk_bulk_caam {
> + const struct clk_bulk_data *clks;
> + int n
On 25.06.2019 15:51, Abel Vesa wrote:
> Add the initial configuration for clocks that need default parent and rate
> setting. This is based on the vendor tree clock provider parents and rates
> configuration except this is doing the setup in dts rather then using clock
> consumer API in a clock pro
This is like /sys/kernel/debug/pm/pm_genpd_summary except it's
accessible through a debugger.
This can be useful if the target crashes or hangs because power domains
were not properly enabled.
Signed-off-by: Leonard Crestez
---
scripts/gdb/linux/genpd.py
al generic "lx-device-list" functions are included to enumerate
devices by bus and class:
(gdb) lx-device-list-bus usb
(gdb) lx-device-list-class
(gdb) lx-device-list-tree &platform_bus
Similar information is available in /sys but pointer values are
deliberately hidden.
Signed-o
On 6/10/2019 3:15 PM, Abel Vesa wrote:
> i.MX8MQ is missing the wake_request signals from GIC to GPCv2. This indirectly
> breaks cpuidle support due to inability to wake target cores on IPIs.
>
> Now, in order to fix this, we can trigger IRQ 32 (hwirq 0) to all the cores by
> setting 12th bit in I
On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> On 10/06/2019 14:55, Abel Vesa wrote:
>> On 19-06-10 14:39:02, Marc Zyngier wrote:
>>> On 10/06/2019 14:29, Abel Vesa wrote:
On 19-06-10 14:19:21, Mark Rutland wrote:
> On Mon, Jun 10, 2019 at 03:13:44PM +0300, Abel Vesa wrote:
>> Basically,
On 3/13/2019 9:36 PM, Alexandre Bailon wrote:
>
> This adds support of i.MX SoC to interconnect framework.
> This is based on busfreq, from NXP's tree.
> This is is generic enough to be used to add support of interconnect
> framework to any i.MX SoC, and, even, this could used for some other
> SoC
On 7/4/2019 9:23 AM, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Assign highest OPP as suspend OPP to reduce suspend/resume
> latency on i.MX8MM.
>
> Signed-off-by: Anson Huang
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/
On 28.06.2019 06:37, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> According to latest datasheet (Rev.1, 10/2018) from below links,
> in the consumer datasheet, 1.5GHz is mentioned as highest opp but
> depends on speed grading fuse, and in the industrial datasheet,
> 1.3GHz is mentioned as h
On 28.06.2019 06:37, anson.hu...@nxp.com wrote:
> According to latest datasheet (Rev.0.2, 04/2019) from below links,
> 1.8GHz is ONLY available for consumer part, so the market segment
> bits for 1.8GHz opp should ONLY available for consumer part accordingly.
>
> opp-hz = /b
On 6/28/2019 9:16 AM, Anson Huang wrote:
>> From: Leonard Crestez
>>> From: Anson Huang
>>>
>>> According to latest datasheet (Rev.1, 10/2018) from below links, in
>>> the consumer datasheet, 1.5GHz is mentioned as highest opp but depends
>>> on
gly.
> > Fixes: f403a26c865b (arm64: dts: imx8mm: Add cpu speed grading and
all OPPs)
> Signed-off-by: Anson Huang
For both:
Reviewed-by: Leonard Crestez
The vendor tree goes through a lot of testing so switching to the exact
speed grading interpretation from there does make sense.
On 7/8/2019 10:55 AM, anson.hu...@nxp.com wrote:
> To reduce the suspend/resume latency, CPU's max supported frequency
> should be used during low level suspend/resume phase, "opp-suspend"
> property is NOT feasible since OPP defined in DT could be NOT supported
> according to speed garding and mar
On Wed, 2019-02-13 at 13:32 +, Anson Huang wrote:
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware to
Hello,
This patch seems to break network booting on imx6sx-sdb in linux-next
because the enet phy regulator is not on. Reverting the patch fixes
boot.
Here is the regulator definition:
reg_enet_3v3: regulator-enet-3v3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
This is required for the imx pci driver to send the PME_Turn_Off TLP.
Signed-off-by: Leonard Crestez
Acked-by: Shawn Guo
---
arch/arm/boot/dts/imx7d.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index
t because it touches
multiple trees. Merging out of order should be fine.
Some patches already carry acks for DT but somebody needs to ack the
pci/reset parts.
Leonard Crestez (4):
reset: imx7: Add PCIE_CTRL_APPS_TURNOFF
dt-bindings: imx6q-pcie: Add turnoff reset for imx7d
ARM: dts: imx7
This is required for the imx pci driver to send the PME_Turn_Off TLP.
Signed-off-by: Leonard Crestez
Acked-by: Rob Herring
---
drivers/reset/reset-imx7.c | 1 +
include/dt-bindings/reset/imx7-reset.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers
t yet supported) has the exact same
PCIE_CTRL_APPS_TURNOFF bit in the same location.
Signed-off-by: Leonard Crestez
---
drivers/pci/controller/dwc/pci-imx6.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/
This is documented as "required" but won't be present in old dtbs.
These resets are also present on other imx chips but right now only
imx7d implements them through the reset controller subsystem.
Signed-off-by: Leonard Crestez
Acked-by: Rob Herring
---
Documentation/devicetr
iles for legacy devices, but I did not finish that
> for this kernel cycle.
>
> Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor
> only")
> Reported-by: Leonard Crestez
> Reported-by: Fabio Estevam
> Reported-by: John Stultz
> Report
reset was only handled in the bootloader.
This fixes linux-next netboot failures previously reported here:
https://lore.kernel.org/patchwork/patch/982437/#1177900
https://lore.kernel.org/patchwork/patch/994091/#1178304
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6sx-sdb.dtsi |
The DCP block on 6ull has no major differences other than requiring
explicit clock enabling.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6ull.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
index
On 6ull and 6sll the DCP block has a clock which needs to be explicitly
enabled.
Add minimal handling for this at probe/remove time.
Signed-off-by: Leonard Crestez
---
drivers/crypto/mxs-dcp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/mxs-dcp.c b
ality issues are not SOC-specific it seems reasonable
to deal with porting separately.
Leonard Crestez (3):
dt-bindings: crypto: Mention clocks for mxs-dcp
crypto: mxs-dcp - Add support for dcp clk
ARM: dts: imx6ull: Add dcp node
.../devicetree/bindings/crypto/fsl-dcp.txt | 2 ++
arc
Explicit clock enabling is required on 6sll and 6ull so mention that
standard clock bindings are used.
Signed-off-by: Leonard Crestez
---
Documentation/devicetree/bindings/crypto/fsl-dcp.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto/fsl
On Tue, 2018-10-02 at 21:56 +0200, Linus Walleij wrote:
> On Tue, Oct 2, 2018 at 8:37 PM Leonard Crestez <
> leonard.cres...@nxp.com> wrote:
>
> > This issue was exposed by commit efdfeb079cc3 ("regulator: fixed:
> > Convert to use GPIO descriptor only")
On Wed, 2018-10-03 at 13:10 +0100, Mark Brown wrote:
> On Tue, Oct 02, 2018 at 01:42:38PM +0000, Leonard Crestez wrote:
>
> > This turns the phy off and on again instead of leaving it up from uboot
> > and it doesn't work for some reason. However looking at
> > reg_fi
On Thu, 2018-09-20 at 08:45 +0200, Jiri Slaby wrote:
> On 09/20/2018, 03:58 AM, YueHaibing wrote:
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/tty/serial/imx.c: In function 'imx_uart_probe':
> > drivers/tty/serial/imx.c:2198:20: warning:
> > variable 'rtsirq' set but not use
Signed-off-by: Uwe Kleine-König
Reviewed-by: Leonard Crestez
I'm not sure if anyone has imx1 hardware handy can is willing to test
this CTS/RTS but the fix is pretty obviously correct.
On Tue, 2018-08-28 at 15:55 +0100, Lorenzo Pieralisi wrote:
> On Tue, Aug 28, 2018 at 01:00:02PM +0000, Leonard Crestez wrote:
> > On Tue, 2018-08-28 at 11:07 +0100, Lorenzo Pieralisi wrote:
> > > On Mon, Aug 27, 2018 at 02:28:37PM +0300, Leonard Crestez wrote:
> > > &g
29018
* CONFIG_MAG3110
* CONFIG_MMA8452
Tested with raw reads from iio sysfs.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm
quot;iio: accel: mma8452: improvements to handle
multiple events")
Signed-off-by: Leonard Crestez
---
drivers/iio/accel/mma8452.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Perhaps this whole early-exit check could be dropped? It is not clear
how it helps.
If for some models we want t
On Thu, 2018-04-19 at 17:02 +0530, Naresh Kamboju wrote:
> On 12 April 2018 at 00:05, Greg Kroah-Hartman
> wrote:
> >
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
> > ------
> >
> > From: L
On Thu, 2018-04-19 at 11:32 -0700, Florian Fainelli wrote:
> +Others who reported the same problem
> On 04/19/2018 11:24 AM, Naresh Kamboju wrote:
> > On 19 April 2018 at 21:41, Leonard Crestez wrote:
> > >
> > > Looking at this dump I'm guessing that phydev-
Hello,
I have some trouble with this patch.
It seems the intention is to allow CMA to be placed in highmem. If the
CMA area is larger than highmem and no alloc-ranges is specified (just a
size) it is possible to end up allocating a area that spans from
multiple zones. This later breaks checks
d it includes a few
additional minor cleanups.
Signed-off-by: Leonard Crestez
---
I also tried to do some debugging in the fec driver and it apparently receives
corrupted packets when this happens. If I hack it to go into promiscuous mode
unconditionally it gets a whole bunch of rx errors (crc
dropout value for ldo enabled mode.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard Crestez
---
drivers/regulator/anatop-regulator.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index b041f27
This enables LDO bypass by default on the imx6qdl-sabresd boards. New
dts files with -ldo suffix are added for users who want to run with LDOs
enabled on these boards anyway.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6dl-sabresd-ldo.dts | 13 +
arch/arm/boot/dts/imx6q
The pu regulator request will return -EPROBE_DEFER if it has a supply
from PMIC and this supply is not yet registered. This does not represent
an error since the driver will call probe again later, so only print a
warning message in this case.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard
reescale vendor tree for a long time and
compatibility is desirable. Otherwise it would be a bool.
Some versions of u-boot shipped by freescale check this same property
and set regulators in bypass mode before linux actually starts so we
check for that scenario as well and finish early.
Signed-
This is a simple kernel API to query the bypass state of a regulator.
Signed-off-by: Leonard Crestez
---
drivers/regulator/core.c | 26 ++
include/linux/regulator/consumer.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/regulator/core.c b
lated consumer who requested a higher voltage.
Signed-off-by: Leonard Crestez
---
drivers/regulator/core.c | 52 ++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 53d4fc7..9d
been successfully registered.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard Crestez
---
drivers/cpufreq/imx6q-cpufreq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 7719b02..be90ee3 100644
--- a/drivers
replaced with a function in regulator_ops?
Irina Tirdea (2):
cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator
regulator: anatop: fix min dropout for bypass mode
Leonard Crestez (6):
ARM: imx: gpc: Do not print error message for EPROBE_DEFER
cpufreq: imx6q: Set max suspend_freq to avoid cha
ldo-bypass but in
theory any regulator set_voltage call can end up having to modify
external supply voltages.
Signed-off-by: Leonard Crestez
---
drivers/cpufreq/imx6q-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
On Wed, 2017-03-22 at 18:09 +0100, Lucas Stach wrote:
> Am Mittwoch, den 22.03.2017, 18:53 +0200 schrieb Leonard Crestez:
> >
> > Several imx6* socs have three built-in regulators LDO_ARM LDO_SOC and
> > LDO_PU used to control internal chip voltages. "ldo-bypass" m
On Tue, 2017-02-28 at 00:05 -0800, sb...@codeaurora.org wrote:
> On 02/25, Leonard Crestez wrote:
> >
> > On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote:
> > >
> > > On 02/20, Leonard Crestez wrote:
> > > >
> > > > Some drivers use
18)
[<801fcd08>] (vfs_read) from [<801fdb00>] (SyS_read+0x3c/0x90)
[<801fdb00>] (SyS_read) from [<80107580>] (ret_fast_syscall+0x0/0x34)
Code: e59f80c4 e1a0100b e59d2018 e1a4 (e59ce15c)
---[ end trace eca2c2e6d835da26 ]---
Signed-off-by: Leonard Crestez
---
drivers/regula
Some drivers use sprintf to build clk connection id names but the clk
core will save those strings and occasionally print them back. Duplicate
the con_id strings instead of fixing all the users.
Signed-off-by: Leonard Crestez
---
drivers/clk/clk.c | 3 ++-
1 file changed, 2 insertions(+), 1
ice the of_node from cpu_dev.
Signed-off-by: Leonard Crestez
---
drivers/cpufreq/imx6q-cpufreq.c | 75 +
1 file changed, 24 insertions(+), 51 deletions(-)
Something similar was rejected in the past:
https://patchwork.kernel.org/patch/7099051/
New vers
On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote:
> On 02/20, Leonard Crestez wrote:
> > Some drivers use sprintf to build clk connection id names but the
> > clk
> > core will save those strings and occasionally print them back.
> > Duplicate
> > the con_id
On 6/4/2019 11:44 AM, Anson Huang wrote:
> As exemple, this series implements busfreq for i.MX8MM whose
> upstreaming is in progress. Because this relies on ATF to do the
> frequency scaling, it won't be hard make it work.
>
> I have similar question as previous reviewer, is there any
On 22.05.2019 16:40, Lucas Stach wrote:
> Am Mittwoch, den 22.05.2019, 13:30 + schrieb Leonard Crestez:
>> On 22.05.2019 16:13, Guido Günther wrote:
>>> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>>> On Wed, May 08, 2019 at 02:40:18PM
On 12.05.2019 12:57, Anson Huang wrote:
> On i.MX7D SDB board, sw2 supplies 1p0d/1p2 LDO, this patch assigns
> corresponding power supply for 1p0d/1p2 LDO to avoid confusion by
> below log:
>
> vdd1p0d: supplied by regulator-dummy
> vdd1p2: supplied by regulator-dummy
>
> With this patch, the pow
this issue.
>
> Fixes: 43967d9b5a7c ("ARM: dts: imx7d-sdb: Assign corresponding power supply
> for LDOs")
> Reported-by: Leonard Crestez
> Signed-off-by: Anson Huang
Reviewed-by: Leonard Crestez
Other boards don't seem to be affected by the original series.
On 16.05.2019 06:24, Anson Huang wrote:
> Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
> driver dependency into Kconfig as CONFIG_IMX_SCU must be
> selected to support i.MX SCU SoC driver, also need to use
> platform driver model to make sure IMX_SCU driver is probed
> before i.M
On 6/3/2019 4:33 AM, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> This patch adds i.MX8MN clock driver support.
> +#include "clk.h"
> +
> +#define PLL_1416X_RATE(_rate, _m, _p, _s)\
> + { \
> + .rate = (_rat
On Fri, 2019-04-12 at 07:04 -0600, Angus Ainslie (Purism) wrote:
> +&i2c1 {
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +
> + pmic: pmic@4b {
> + reg = <0x4b>;
> + co
On Fri, 2017-03-24 at 14:43 +0800, Dong Aisheng wrote:
> Hi Leonard,
>
> On Wed, Mar 22, 2017 at 04:27:37PM +0200, Leonard Crestez wrote:
> >
> > The imx6sl-evk board has a LAN8720A ethernet phy supported by SMSC_PHY.
> > Add this driver to the default imx config sin
On Fri, 2017-03-24 at 12:54 +, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 06:53:07PM +0200, Leonard Crestez wrote:
> > + if (anatop_reg->bypass)
> > + anatop_reg->rdesc.min_dropout_uV = 0;
> > + else
> > + anatop_reg->rdesc.min_d
On Fri, 2017-03-24 at 12:52 +, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 06:53:06PM +0200, Leonard Crestez wrote:
>
> >
> > Enabling bypass mode makes a regulator passthrough the supply voltage
> > directly. It is possible that the supply voltage is set high eno
On Fri, 2017-03-24 at 12:55 +, Mark Brown wrote:
> On Wed, Mar 22, 2017 at 06:53:08PM +0200, Leonard Crestez wrote:
> > /**
> > + * regulator_is_bypass - Determine if the regulator is in bypass mode
> Bypass is a verb so this should be regulator_is_bypassed()
Very well, I will change this.
On Tue, 2017-03-28 at 17:47 +0100, Mark Brown wrote:
> On Tue, Mar 28, 2017 at 03:39:41PM +0300, Leonard Crestez wrote:
> > On Fri, 2017-03-24 at 12:52 +, Mark Brown wrote:
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80
On Thu, 2017-03-23 at 10:04 +0530, Viresh Kumar wrote:
> On 22-03-17, 18:53, Leonard Crestez wrote:
> > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > it might need to control an external PMIC via I2C or SPI but those
> > devices might
with "make savedefconfig" and it includes a few
additional minor cleanups.
Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
Acked-by: Florian Fainelli
Acked-by: Fugang Duan
---
I also tried to do some debugging in the fec driver and it apparently receives
corrupted packets whe
On Wed, 2017-03-22 at 18:13 +0100, Lucas Stach wrote:
> Am Mittwoch, den 22.03.2017, 18:53 +0200 schrieb Leonard Crestez:
> > This enables LDO bypass by default on the imx6qdl-sabresd boards. New
> > dts files with -ldo suffix are added for users who want to run with LDOs
>
On Tue, 2017-04-04 at 20:04 +0300, Leonard Crestez wrote:
> Setting the LDO regulator parent is optional but beneficial. It will cause
> the PMIC output voltage to be dynamically set to the minimum input for the
> LDOs, this should be more efficient.
>
> This propagation wa
ds fail to boot with ugly
semi-random crashes, reminiscent of memory corruption. These failures
happen the first time the lowest idle state is used. Remove the OPP
override in order to fix those crashes.
Signed-off-by: Leonard Crestez
---
It's not clear exactly why the crashes happen. Pe
On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote:
> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
> >
> > Hi Leonard,
> >
> > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> > wrote:
> > >
> > > The board file for i
On Tue, 2017-04-04 at 11:46 +0200, Lucas Stach wrote:
> Am Freitag, den 31.03.2017, 22:25 +0300 schrieb Leonard Crestez:
> >
> > The pu regulator request will return -EPROBE_DEFER if it has a supply
> > from PMIC and this supply is not yet registered. This does not represe
On imx6qp-sabresd LDO_ARM is connected to a different PMIC output than
the other imx6qdl-sabresd boards.
Setting cpu0 arm-supply to sw2_reg is wrong, this must have mistakenly
slipped out of the vendor tree where this is are used for LDO bypass.
Signed-off-by: Leonard Crestez
Reviewed-by: Lucas
been successfully registered.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard Crestez
Reviewed-by: Lucas Stach
Acked-by: Viresh Kumar
---
drivers/cpufreq/imx6q-cpufreq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q
s not clear if policy->cpuinfo.max would be preferable, at init time
they should be identical.
Link: https://lkml.org/lkml/2017/3/31/683
Irina Tirdea (1):
cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator
Leonard Crestez (3):
cpufreq: imx6q: Set max suspend_freq to avoid changes d
On Tue, 2017-04-04 at 11:51 +0200, Lucas Stach wrote:
> Am Freitag, den 31.03.2017, 22:25 +0300 schrieb Leonard Crestez:
> >
> > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > it might need to control an external PMIC via I2C or SPI but those
Setting the supply is optional but beneficial, it will cause PMIC
voltages to be dynamically changed with cpu frequency.
Signed-off-by: Leonard Crestez
Reviewed-by: Lucas Stach
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm
cpufreq to the maximum before
suspend.
Signed-off-by: Leonard Crestez
---
drivers/cpufreq/imx6q-cpufreq.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index be90ee3..786122e 100644
--- a/drivers/cpufreq
On Thu, Mar 30, 2017 at 11:15 AM, Masahiro Yamada
wrote:
>
> Some NAND controllers are using DMA engine requiring a specific
> buffer alignment. The core provides no guarantee on the nand_buffers
> pointers, which forces some drivers to allocate their own buffers
> and pass the NAND_OWN_BUFFERS
On Thu, 2017-04-06 at 19:52 +0100, Mark Brown wrote:
> On Tue, Mar 28, 2017 at 10:49:55PM +0300, Leonard Crestez wrote:
> > On Tue, 2017-03-28 at 17:47 +0100, Mark Brown wrote:
> > > To repeat what I said previously the whole point of bypassing is to not
> > > do r
On Tue, 2017-04-11 at 12:07 +0530, Viresh Kumar wrote:
> On 04-04-17, 20:04, Leonard Crestez wrote:
> > If the cpufreq driver tries to modify voltage/freq during suspend/resume
> > it might need to control an external PMIC via I2C or SPI but those
> > devices might be already
On Wed, 2017-04-12 at 12:03 +0800, Dong Aisheng wrote:
> +/**
> + * clk_bulk_enable - ungate a bulk of clocks
> + * @num_clks: the number of clk_bulk_data
> + * @clks: the clk_bulk_data table being ungated
> + *
> + * clk_bulk_enable must not sleep
> + * Returns 0 on success, -EERROR otherwise.
> +
On Wed, 2017-04-12 at 12:03 +0800, Dong Aisheng wrote:
> +static int num_clks;
> +static struct clk_bulk_data clks[] = {
> + { .id = "arm" },
> + { .id = "pll1_sys" },
> + { .id = "step" },
> + { .id = "pll1_sw" },
> + { .id = "pll2_pfd2_396m" },
> + { .id = "pll2_bus" },
>
On Thu, 2017-03-30 at 16:55 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170329:
>
> Undropped tree: xen-tip
>
> The vfs tree gained a conflict against Linus' tree.
>
> The drm tree gained conflicts against the drm-intel-fixes tree.
>
> The mailbox tree lost its build failure.
Setting the supply is optional but beneficial, it will cause PMIC
voltages to be dynamically changed with cpu frequency.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl
On imx6qp-sabresd LDO_ARM is connected to a different PMIC output than
the other imx6qdl-sabresd boards.
Setting cpu0 arm-supply to sw2_reg is wrong, this must have mistakenly
slipped out of the vendor tree where this is are used for LDO bypass.
Signed-off-by: Leonard Crestez
---
arch/arm/boot
ldo-bypass but in
theory any regulator set_voltage call can end up having to modify
external supply voltages.
Signed-off-by: Leonard Crestez
Acked-by: Viresh Kumar
---
drivers/cpufreq/imx6q-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers
The pu regulator request will return -EPROBE_DEFER if it has a supply
from PMIC and this supply is not yet registered. This does not represent
an error since the driver will call probe again later, so only print a
warning message in this case.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard
been successfully registered.
Signed-off-by: Irina Tirdea
Signed-off-by: Leonard Crestez
Acked-by: Viresh Kumar
---
drivers/cpufreq/imx6q-cpufreq.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 7719b02..be90ee3
t
other complex configurations.
These changes are required for LDO bypass but they are also useful
standalone. Here's a link to the that other discussion:
https://lkml.org/lkml/2017/3/22/640
Irina Tirdea (1):
cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator
Leonard Crestez (4):
ARM: i
On Fri, 2017-04-07 at 12:22 +0100, Mark Brown wrote:
> On Fri, Apr 07, 2017 at 01:51:52PM +0300, Leonard Crestez wrote:
> > It currently seems to work how I expect but from your statement it's
> > not clear if it's entirely intentional.
> The current behavio
On Wed, 2017-05-17 at 18:50 -0700, Jiada Wang wrote:
> Hello Leonard
>
> Thanks for the report, can you help to check if the following change
> address the issue?
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 782045f..19b30cf 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/
201 - 300 of 374 matches
Mail list logo
