On Tue, 2018-07-10 at 00:33 +0200, Ulf Hansson wrote:
> On 9 July 2018 at 14:23, Leonard Crestez
> wrote:
> > The imx6sl chip errata document describes ERR006287 like this:
> >
> > """
> > Upon resuming from power gating, the modules in the di
On Tue, 2018-07-10 at 00:33 +0200, Ulf Hansson wrote:
> On 9 July 2018 at 14:23, Leonard Crestez
> wrote:
> > The imx6sl chip errata document describes ERR006287 like this:
> >
> > """
> > Upon resuming from power gating, the modules in the di
On Tue, 2018-07-03 at 10:42 +0200, Lucas Stach wrote:
> Am Montag, den 02.07.2018, 17:18 + schrieb Leonard Crestez:
> > On Fri, 2018-06-08 at 16:33 +0200, Lucas Stach wrote:
> > > Am Dienstag, den 29.05.2018, 22:39 +0300 schrieb Leonard Crestez:
> > > >
On Tue, 2018-07-03 at 10:42 +0200, Lucas Stach wrote:
> Am Montag, den 02.07.2018, 17:18 + schrieb Leonard Crestez:
> > On Fri, 2018-06-08 at 16:33 +0200, Lucas Stach wrote:
> > > Am Dienstag, den 29.05.2018, 22:39 +0300 schrieb Leonard Crestez:
> > > >
on the
display power domain.
"""
Link: https://www.nxp.com/docs/en/errata/IMX6SLCE.pdf#page=62
Handle this in linux in the same way as imx6qp ERR009619: make the DISP
domain return -EBUSY on power_off.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 10 ++
on the
display power domain.
"""
Link: https://www.nxp.com/docs/en/errata/IMX6SLCE.pdf#page=62
Handle this in linux in the same way as imx6qp ERR009619: make the DISP
domain return -EBUSY on power_off.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 10 ++
here, treat it like on 6qp.
Previous version included a patch to improve lcdif power management, but
since ERR006287 effectively disables runtime PM for display it is no
longer strictly required.
This doesn't depend on other GPC patches I sent either, it's an
unrelated fix.
Leonard Crestez (2
here, treat it like on 6qp.
Previous version included a patch to improve lcdif power management, but
since ERR006287 effectively disables runtime PM for display it is no
longer strictly required.
This doesn't depend on other GPC patches I sent either, it's an
unrelated fix.
Leonard Crestez (2
the newly-defined _disp domain from
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6sl.dtsi | 36 +++
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 994e48dc1df0..3aaa8d5d4
the newly-defined _disp domain from
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6sl.dtsi | 36 +++
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 994e48dc1df0..3aaa8d5d4
the PU domain to the pgc platform_device.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 88 +++
1 file changed, 73 insertions(+), 15 deletions(-)
Link to v2: https://lkml.org/lkml/2018/7/5/564
Changes since v2: Add device links on attach
the PU domain to the pgc platform_device.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 88 +++
1 file changed, 73 insertions(+), 15 deletions(-)
Link to v2: https://lkml.org/lkml/2018/7/5/564
Changes since v2: Add device links on attach
On imx6qp power gating on the PU domain is disabled because of errata
ERR009619. However power gating during suspend/resume can still be
performed.
Enable this by implementing SLEEP_PM_OPS in imx_pgc_power_domain_driver.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 72
On imx6qp power gating on the PU domain is disabled because of errata
ERR009619. However power gating during suspend/resume can still be
performed.
Enable this by implementing SLEEP_PM_OPS in imx_pgc_power_domain_driver.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 72
If the gpc device is removed the platform_devices for its
imx-pgc-power-domains are still registered and trying to probe gpc again
results in an error.
Fix this by iterating children inside imx_gpc_remove and calling
platfrom_device_unregister.
Signed-off-by: Leonard Crestez
---
drivers/soc
If the gpc device is removed the platform_devices for its
imx-pgc-power-domains are still registered and trying to probe gpc again
results in an error.
Fix this by iterating children inside imx_gpc_remove and calling
platfrom_device_unregister.
Signed-off-by: Leonard Crestez
---
drivers/soc
On Fri, 2018-06-08 at 16:33 +0200, Lucas Stach wrote:
> Am Dienstag, den 29.05.2018, 22:39 +0300 schrieb Leonard Crestez:
> > On imx7d the phy is turned off in suspend and must be reset on resume.
> > Right now lspci -v fails after a suspend/resume cycle, fix this by
> > a
On Fri, 2018-06-08 at 16:33 +0200, Lucas Stach wrote:
> Am Dienstag, den 29.05.2018, 22:39 +0300 schrieb Leonard Crestez:
> > On imx7d the phy is turned off in suspend and must be reset on resume.
> > Right now lspci -v fails after a suspend/resume cycle, fix this by
> > a
On Mon, 2018-07-02 at 14:15 +0200, Lucas Stach wrote:
> Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:
> > With current code (even without my patches) attempting to dynamically
> > remove/probe the GPC fils since since the per-pgc platform_device
> > inst
On Mon, 2018-07-02 at 14:15 +0200, Lucas Stach wrote:
> Am Montag, den 02.07.2018, 14:52 +0300 schrieb Leonard Crestez:
> > With current code (even without my patches) attempting to dynamically
> > remove/probe the GPC fils since since the per-pgc platform_device
> > inst
Simplify the code by doing less dynamic allocation.
This also allows easier direct manipulation of individual power domains.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git
Simplify the code by doing less dynamic allocation.
This also allows easier direct manipulation of individual power domains.
Signed-off-by: Leonard Crestez
---
drivers/soc/imx/gpc.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git
On imx6qp power gating on the PU domain is disabled because of errata
ERR009619. However power gating on suspend/resume can still work.
Enable this by calling the on/off functions directly from suspend code in
mach-imx.
Signed-off-by: Leonard Crestez
---
arch/arm/mach-imx/gpc.c | 10
t of changes in gpc code and this causes
a lot of trouble when doing upgrades so I am trying to push some of the
internal features upstream.
Maybe instead of direct calls from mach-imx the gpc could implement
SLEEP_PM_OPS instead? It would still need a way to access the pgc
devices directly.
Leonar
On imx6qp power gating on the PU domain is disabled because of errata
ERR009619. However power gating on suspend/resume can still work.
Enable this by calling the on/off functions directly from suspend code in
mach-imx.
Signed-off-by: Leonard Crestez
---
arch/arm/mach-imx/gpc.c | 10
t of changes in gpc code and this causes
a lot of trouble when doing upgrades so I am trying to push some of the
internal features upstream.
Maybe instead of direct calls from mach-imx the gpc could implement
SLEEP_PM_OPS instead? It would still need a way to access the pgc
devices directly.
Leonar
This makes it possible to enable earlycon for debugging by just passing
an empty "earlycon" argument on the kernel command-line.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4
arch/arm/boot/dts/imx6sl-evk.dts | 4
arch/arm/boot/d
This makes it possible to enable earlycon for debugging by just passing
an empty "earlycon" argument on the kernel command-line.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 4
arch/arm/boot/dts/imx6sl-evk.dts | 4
arch/arm/boot/d
transceiver so remove the first definition.
The second definition entirely overrides the first so this already
worked and this patch results in no DTB change, just a cleanup.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx7d-sdb.dts | 8
1 file changed, 8 deletions(-)
diff --git
transceiver so remove the first definition.
The second definition entirely overrides the first so this already
worked and this patch results in no DTB change, just a cleanup.
Signed-off-by: Leonard Crestez
---
arch/arm/boot/dts/imx7d-sdb.dts | 8
1 file changed, 8 deletions(-)
diff --git
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
Reviewed-by: Fabio Estevam
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2
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
Reviewed-by: Fabio Estevam
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2
* 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(+)
Changes since v1:
* adjusted node names (Fabio)
Link: https://lkml.org/lkml/2018/6/7/970
diff
* 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(+)
Changes since v1:
* adjusted node names (Fabio)
Link: https://lkml.org/lkml/2018/6/7/970
diff
On Thu, 2018-06-07 at 14:07 -0300, Fabio Estevam wrote:
> Hi Leonard,
>
> On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez
> wrote:
>
> > +
> > + isl29023@44 {
>
> According to Devicetree Specification v0.2 document:
>
> "T
On Thu, 2018-06-07 at 14:07 -0300, Fabio Estevam wrote:
> Hi Leonard,
>
> On Thu, Jun 7, 2018 at 2:00 PM, Leonard Crestez
> wrote:
>
> > +
> > + isl29023@44 {
>
> According to Devicetree Specification v0.2 document:
>
> "T
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
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
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
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
* 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.dtsi
* 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.dtsi
ona and also calling it from
mxsfb_crtc_mode_set_nofb.
Also add fields to mxsfb_drv to keep track of enabled/suspended states.
Signed-off-by: Robert Chiras
Signed-off-by: Leonard Crestez
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 38 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.c |
ona and also calling it from
mxsfb_crtc_mode_set_nofb.
Also add fields to mxsfb_drv to keep track of enabled/suspended states.
Signed-off-by: Robert Chiras
Signed-off-by: Leonard Crestez
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 38 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.c |
variants.
Tested on imx7d-sabresd with an Intel 5622ANHMW wireless pcie adapter.
The original author is mostly Richard Zhu , this
patch adjusts the code to the upstream imx7d implemention using reset
controls and power domains.
Signed-off-by: Leonard Crestez
---
drivers/pci/dwc/pci-imx6.c | 94
but for
other registers like MIPIPHY and HSICPHY the bits are explicitly
documented as "1 means assert, 0 means deassert".
The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN.
Signed-off-by: Leonard Crestez
---
drivers/reset/reset-imx7.c | 2 +-
1 file changed, 1 insertion(+),
variants.
Tested on imx7d-sabresd with an Intel 5622ANHMW wireless pcie adapter.
The original author is mostly Richard Zhu , this
patch adjusts the code to the upstream imx7d implemention using reset
controls and power domains.
Signed-off-by: Leonard Crestez
---
drivers/pci/dwc/pci-imx6.c | 94
but for
other registers like MIPIPHY and HSICPHY the bits are explicitly
documented as "1 means assert, 0 means deassert".
The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN.
Signed-off-by: Leonard Crestez
---
drivers/reset/reset-imx7.c | 2 +-
1 file changed, 1 insertion(+),
on first PCI read from PCI-PM core. It
is not strictly related to PCI but pci-imx6 is the only user of gpcv2
power domains.
Patch 1 in this series is also technically an unrelated bugfix, however
pci-imx6 is the only user.
Leonard Crestez (2):
reset: imx7: Fix always writing bits as 0
PCI: imx
on first PCI read from PCI-PM core. It
is not strictly related to PCI but pci-imx6 is the only user of gpcv2
power domains.
Patch 1 in this series is also technically an unrelated bugfix, however
pci-imx6 is the only user.
Leonard Crestez (2):
reset: imx7: Fix always writing bits as 0
PCI: imx
On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
> design RTL, the value on Reference Manual are incorrect.
>
> The correct offset should be as below:
>
> -#define PGC_MIPI 4
> -#define PGC_PCIE 5
>
On Tue, 2018-05-29 at 16:02 +0800, Anson Huang wrote:
> Correct MIPI/PCIe/USB_HSIC's PGC offset based on
> design RTL, the value on Reference Manual are incorrect.
>
> The correct offset should be as below:
>
> -#define PGC_MIPI 4
> -#define PGC_PCIE 5
>
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 <leonard.cres...@nxp.com> wrote:
> > >
> > > Looking at this
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-&g
On Thu, 2018-04-19 at 17:02 +0530, Naresh Kamboju wrote:
> On 12 April 2018 at 00:05, Greg Kroah-Hartman
> <gre...@linuxfoundation.org> wrote:
> >
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
> > -----
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
When the definition of this struct was removed a forward declaration and an
unused struct member were still left around. Remove them because they serve
no purpose.
Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and
imx_drm_crtc_helper_funcs")
Signed-off-by: Leona
When the definition of this struct was removed a forward declaration and an
unused struct member were still left around. Remove them because they serve
no purpose.
Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and
imx_drm_crtc_helper_funcs")
Signed-off-by: Leona
on a similar issue here: https://lkml.org/lkml/2018/3/8/1379
Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
Cc: <sta...@vger.kernel.org>
---
arch/arm/crypto/Makefile | 2 ++
arch/arm64/crypto/Makefile | 2 ++
2 files changed, 4 insertions(+)
Not clear if this needs to go through c
on a similar issue here: https://lkml.org/lkml/2018/3/8/1379
Signed-off-by: Leonard Crestez
Cc:
---
arch/arm/crypto/Makefile | 2 ++
arch/arm64/crypto/Makefile | 2 ++
2 files changed, 4 insertions(+)
Not clear if this needs to go through crypto or arm but all commits in these
directories start
On Thu, 2018-03-08 at 07:02 +, Ard Biesheuvel wrote:
> On 8 March 2018 at 05:00, Masahiro Yamada <yamada.masah...@socionext.com>
> wrote:
> > 2018-03-08 4:25 GMT+09:00 Leonard Crestez <leonard.cres...@nxp.com
> > > If a decision to rerun the rule i
On Thu, 2018-03-08 at 07:02 +, Ard Biesheuvel wrote:
> On 8 March 2018 at 05:00, Masahiro Yamada
> wrote:
> > 2018-03-08 4:25 GMT+09:00 Leonard Crestez > > If a decision to rerun the rule is made based on their relative
> > > timestamps but both .S_shipped and s
Hello,
I am using a toolchain with a broken/old version of perl which doesn't
include integer.pm and I noticed it triggers occasional build failures
on arch/arm64/crypto/sha512-core.S_shipped. Workarounds are easy, but
if the purpose of the .S_shipped is to avoid the need to have all
dependencies
Hello,
I am using a toolchain with a broken/old version of perl which doesn't
include integer.pm and I noticed it triggers occasional build failures
on arch/arm64/crypto/sha512-core.S_shipped. Workarounds are easy, but
if the purpose of the .S_shipped is to avoid the need to have all
dependencies
On Sat, 2018-02-24 at 16:02 +0800, Anson Huang wrote:
> This patch adds i.MX7 thermal sensor support, most
> of the i.MX7 thermal sensor functions are same with
> i.MX6 except the registers offset/layout, so we move
> those registers offset/layout definitions to soc data
> structure.
>
> i.MX7
On Sat, 2018-02-24 at 16:02 +0800, Anson Huang wrote:
> This patch adds i.MX7 thermal sensor support, most
> of the i.MX7 thermal sensor functions are same with
> i.MX6 except the registers offset/layout, so we move
> those registers offset/layout definitions to soc data
> structure.
>
> i.MX7
On Tue, 2018-01-09 at 02:17 +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 8, 2018 at 4:51 PM, Leonard Crestez wrote:
> > On Mon, 2018-01-08 at 15:14 +, Patrick Bellasi wrote:
> > > On 08-Jan 15:20, Leonard Crestez wrote:
> > > > On Mon, 2018-01-08 at 0
On Tue, 2018-01-09 at 02:17 +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 8, 2018 at 4:51 PM, Leonard Crestez wrote:
> > On Mon, 2018-01-08 at 15:14 +, Patrick Bellasi wrote:
> > > On 08-Jan 15:20, Leonard Crestez wrote:
> > > > On Mon, 2018-01-08 at 0
On Mon, 2018-01-08 at 15:14 +, Patrick Bellasi wrote:
> On 08-Jan 15:20, Leonard Crestez wrote:
> > On Mon, 2018-01-08 at 09:31 +0530, Viresh Kumar wrote:
> > > On 05-01-18, 23:18, Rafael J. Wysocki wrote:
> > > > On Fri, Jan 5, 2018 at 9
On Mon, 2018-01-08 at 15:14 +, Patrick Bellasi wrote:
> On 08-Jan 15:20, Leonard Crestez wrote:
> > On Mon, 2018-01-08 at 09:31 +0530, Viresh Kumar wrote:
> > > On 05-01-18, 23:18, Rafael J. Wysocki wrote:
> > > > On Fri, Jan 5, 2018 at 9
On Mon, 2018-01-08 at 09:31 +0530, Viresh Kumar wrote:
> On 05-01-18, 23:18, Rafael J. Wysocki wrote:
> > On Fri, Jan 5, 2018 at 9:37 PM, Leonard Crestez <leonard.cres...@nxp.com>
> > wrote:
> > > When using the schedutil governor together with the softloc
On Mon, 2018-01-08 at 09:31 +0530, Viresh Kumar wrote:
> On 05-01-18, 23:18, Rafael J. Wysocki wrote:
> > On Fri, Jan 5, 2018 at 9:37 PM, Leonard Crestez
> > wrote:
> > > When using the schedutil governor together with the softlockup detector
> > > all C
Hello,
When using the schedutil governor together with the softlockup detector
all CPUs go to their maximum frequency on a regular basis. This seems
to be because the watchdog creates a RT thread on each CPU and this
causes regular kicks with:
cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
Hello,
When using the schedutil governor together with the softlockup detector
all CPUs go to their maximum frequency on a regular basis. This seems
to be because the watchdog creates a RT thread on each CPU and this
causes regular kicks with:
cpufreq_update_this_cpu(rq, SCHED_CPUFREQ_RT);
On Thu, 2017-12-07 at 06:36 +0100, Oleksij Rempel wrote:
>
> On 07.12.2017 00:11, Christoph Hellwig wrote:
> >
> > >
> > > void (*pm_power_off_prepare)(void);
> > > +EXPORT_SYMBOL(pm_power_off_prepare);
> > EXPORT_SYMBOL_GPL for something this deeply internal, please.
> Ok,
> probably all
On Thu, 2017-12-07 at 06:36 +0100, Oleksij Rempel wrote:
>
> On 07.12.2017 00:11, Christoph Hellwig wrote:
> >
> > >
> > > void (*pm_power_off_prepare)(void);
> > > +EXPORT_SYMBOL(pm_power_off_prepare);
> > EXPORT_SYMBOL_GPL for something this deeply internal, please.
> Ok,
> probably all
Fix this by making the arrays flat. This also saves a little memory
because the regulator_desc arrays become smaller.
Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
Fixes: 83b2a3c2ab24 ("regulator: rn5t618: add RC5T619 PMIC support")
---
An alternative would be to r
Fix this by making the arrays flat. This also saves a little memory
because the regulator_desc arrays become smaller.
Signed-off-by: Leonard Crestez
Fixes: 83b2a3c2ab24 ("regulator: rn5t618: add RC5T619 PMIC support")
---
An alternative would be to restore the check if (!regulators[i].
On Sun, 2017-08-27 at 15:58 +0200, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
>
> @@ -101,10 +131,7 @@ static int rn5t618_regulator_probe(struct
> platform_device *pdev)
> config.dev =
On Sun, 2017-08-27 at 15:58 +0200, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
>
> @@ -101,10 +131,7 @@ static int rn5t618_regulator_probe(struct
> platform_device *pdev)
> config.dev =
Enable cpuidle support on i.MX6DL starting from IMX_CHIP_REVISION_1_1.
This also makes the code cleaner because 6q and 6dl actually have
different revision histories.
Signed-off-by: Bai Ping <ping@nxp.com>
Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
---
Changes sin
Enable cpuidle support on i.MX6DL starting from IMX_CHIP_REVISION_1_1.
This also makes the code cleaner because 6q and 6dl actually have
different revision histories.
Signed-off-by: Bai Ping
Signed-off-by: Leonard Crestez
---
Changes since v1: https://www.spinics.net/lists/arm-kernel
On Mon, 2017-09-18 at 11:08 -0700, Stefano Stabellini wrote:
On Fri, 15 Sep 2017, Greg KH wrote:
> On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote:
> > Hi all,
> >
> > We are getting reports from Xen on ARM users about DMA issues. The
> > problem is that the commit below
> >
On Mon, 2017-09-18 at 11:08 -0700, Stefano Stabellini wrote:
On Fri, 15 Sep 2017, Greg KH wrote:
> On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote:
> > Hi all,
> >
> > We are getting reports from Xen on ARM users about DMA issues. The
> > problem is that the commit below
> >
at the
Kconfig level.
> Fixes: 7fe5ba04fcdc ("thermal: imx: Add support for reading OCOTP through
> nvmem")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Leonard Crestez <leonard.cres...@nxp.com>
> diff --git a/drivers/thermal/Kconfig b/drivers/th
at the
Kconfig level.
> Fixes: 7fe5ba04fcdc ("thermal: imx: Add support for reading OCOTP through
> nvmem")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Leonard Crestez
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 07002df4f83a..cb14f1ec5953
gy patch made
it's way into Linus's tree after the 4.13 release.
Perhaps when there is long debate about the "proper" fix the original
patch should be reverted first, separately? In this particular case the
series fixing the bug actually includes the revert.
Anyway, I check that this v3 works on my board which was reproducing
the issue while booting from nfs (imx6sl-evk). The most likely reason
it's easy to reproduce here is a network driver issue where headers are
not correctly aligned to 4. This causes lots of alignment faults.
Tested-by: Leonard Crestez <leonard.cres...@nxp.com>
--
Regards,
Leonard
everted first, separately? In this particular case the
series fixing the bug actually includes the revert.
Anyway, I check that this v3 works on my board which was reproducing
the issue while booting from nfs (imx6sl-evk). The most likely reason
it's easy to reproduce here is a network driver issue where headers are
not correctly aligned to 4. This causes lots of alignment faults.
Tested-by: Leonard Crestez
--
Regards,
Leonard
r the rate is change to deal
with this. Otherwise from the clk framework perspective pll1_sys is
unused and gets turned off.
Signed-off-by: Leonard Crestez <leonard.cres...@nxp.com>
---
Changes since v1:
- Link: https://lkml.org/lkml/2017/7/19/302
- Only keep pll1_sys enabled until after ARM
r the rate is change to deal
with this. Otherwise from the clk framework perspective pll1_sys is
unused and gets turned off.
Signed-off-by: Leonard Crestez
---
Changes since v1:
- Link: https://lkml.org/lkml/2017/7/19/302
- Only keep pll1_sys enabled until after ARM rate is changed.
- Incorporate more
On Fri, 2017-08-25 at 10:07 +0100, Srinivas Kandagatla wrote:
> On 14/07/17 15:11, Leonard Crestez wrote:
> >
> > This function does a quick and easy read of an u32 value without any
> > kind of resource management code on the consumer side.
> >
> > Signed-off-
On Fri, 2017-08-25 at 10:07 +0100, Srinivas Kandagatla wrote:
> On 14/07/17 15:11, Leonard Crestez wrote:
> >
> > This function does a quick and easy read of an u32 value without any
> > kind of resource management code on the consumer side.
> >
> &g
On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > On 08/08/17 12:38, Leonard Crestez wrote:
> > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > On 08/08/17 08:21, Zhang
On Tue, 2017-08-08 at 20:58 +0800, Zhang Rui wrote:
> On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > On 08/08/17 12:38, Leonard Crestez wrote:
> > > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > > On 08/08/17 08:21, Zhang
On Wed, 2017-08-16 at 12:04 +0530, Viresh Kumar wrote:
> On 28-07-17, 10:58, Viresh Kumar wrote:
> >
> > At this point I really feel that this is a hardware specific problem
> > and it was working by chance until now. And I am not sure if we
> > shouldn't be stopping this patch from getting
On Wed, 2017-08-16 at 12:04 +0530, Viresh Kumar wrote:
> On 28-07-17, 10:58, Viresh Kumar wrote:
> >
> > At this point I really feel that this is a hardware specific problem
> > and it was working by chance until now. And I am not sure if we
> > shouldn't be stopping this patch from getting
On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> On 08/08/17 08:21, Zhang Rui wrote:
> > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> > > > On newer imx SOCs accessing O
On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> On 08/08/17 08:21, Zhang Rui wrote:
> > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> > > > On newer imx SOCs accessing O
On Thu, 2017-08-03 at 09:32 +0200, Sébastien Szymanski wrote:
> On 08/03/2017 04:03 AM, Shawn Guo wrote:
> > On Fri, Jul 28, 2017 at 10:36:33AM +0200, Sébastien Szymanski wrote:
> > > Setting the frequency higher than 528Mhz actually sets the ARM
> > > clock to 528MHz. That's because PLL2 is used
On Thu, 2017-08-03 at 09:32 +0200, Sébastien Szymanski wrote:
> On 08/03/2017 04:03 AM, Shawn Guo wrote:
> > On Fri, Jul 28, 2017 at 10:36:33AM +0200, Sébastien Szymanski wrote:
> > > Setting the frequency higher than 528Mhz actually sets the ARM
> > > clock to 528MHz. That's because PLL2 is used
301 - 400 of 648 matches
Mail list logo
