[U-Boot] [PATCH V3 1/2] power: domain: add dev_power_domain_on

[U-Boot] [PATCH V3 1/2] power: domain: add dev_power_domain_on

[Peng Fan]

Add this new API to power on multiple domains attached
to a device.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

V3:
 Fix build break
 Add R-b tag
V2:
 create dev_power_domain_on

 drivers/power/domain/power-domain-uclass.c | 22 ++++++++++++++++++++++
 include/power-domain.h                     | 17 +++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/power/domain/power-domain-uclass.c b/drivers/power/domain/power-domain-uclass.c
index 2ea0ff24c7..6eb4267de3 100644
--- a/drivers/power/domain/power-domain-uclass.c
+++ b/drivers/power/domain/power-domain-uclass.c
@@ -107,6 +107,28 @@ int power_domain_off(struct power_domain *power_domain)
 	return ops->off(power_domain);
 }
 
+
+#if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA))
+int dev_power_domain_on(struct udevice *dev)
+{
+	struct power_domain pd;
+	int i, count, ret;
+
+	count = dev_count_phandle_with_args(dev, "power-domains",
+					    "#power-domain-cells");
+	for (i = 0; i < count; i++) {
+		ret = power_domain_get_by_index(dev, &pd, i);
+		if (ret)
+			return ret;
+		ret = power_domain_on(&pd);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+#endif
+
 UCLASS_DRIVER(power_domain) = {
 	.id		= UCLASS_POWER_DOMAIN,
 	.name		= "power_domain",
diff --git a/include/power-domain.h b/include/power-domain.h
index ef15dc9f60..490fedbb12 100644
--- a/include/power-domain.h
+++ b/include/power-domain.h
@@ -155,4 +155,21 @@ static inline int power_domain_off(struct power_domain *power_domain)
 }
 #endif
 
+/**
+ * dev_power_domain_on - Enable power domains for a device .
+ *
+ * @dev:		The client device.
+ *
+ * @return 0 if OK, or a negative error code.
+ */
+#if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) && \
+	CONFIG_IS_ENABLED(POWER_DOMAIN)
+int dev_power_domain_on(struct udevice *dev);
+#else
+static inline int dev_power_domain_on(struct udevice *dev)
+{
+	return 0;
+}
+#endif
+
 #endif
-- 
2.16.4

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Peng Fan]

When multiple power domains attached to a device, need power on
them all, so use dev_power_domain_on to do that.

Signed-off-by: Peng Fan <peng.fan@nxp.com>

Reviewed-by: Simon Glass <sjg@chromium.org>
---

V3:
 Add R-b tag
V2:
 Use dev_power_domain_on

 drivers/core/device.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 05dadf98f9..f4d7140698 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -307,7 +307,6 @@ static void *alloc_priv(int size, uint flags)
 
 int device_probe(struct udevice *dev)
 {
-	struct power_domain pd;
 	const struct driver *drv;
 	int size = 0;
 	int ret;
@@ -390,8 +389,9 @@ int device_probe(struct udevice *dev)
 
 	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
 	    device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) {
-		if (!power_domain_get(dev, &pd))
-			power_domain_on(&pd);
+		ret = dev_power_domain_on(dev);
+		if (ret)
+			goto fail;
 	}
 
 	ret = uclass_pre_probe_device(dev);
-- 
2.16.4

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Oliver Graute]

Hello Peng,

this patch broke my u-boot on a IMX8 QM ROM 7720a1 board.

f0cc4eae9a1702a768817ea25d9f23cece69d021

I bisect it and that is the first broken commit. The commits before are
working fine.

I tried to remove your changes but then  I run into this errrors:

sc_rm_get_memreg_info: mr:38 res:22
Memreg get info failed, -110
mu_hal_sendmsg timeout
sc_rm_is_memreg_owned: mr:39 res:21
sc_rm_is_memreg_owned: mr:39 res:21
mu_hal_sendmsg timeout

Some clue whats wrong here? Do I need to adapt my imx8qm board file?

Best regards,

Oliver

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Peng Fan]

> Subject: [U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on
> 
> Hello Peng,
> 
> this patch broke my u-boot on a IMX8 QM ROM 7720a1 board.
> 
> f0cc4eae9a1702a768817ea25d9f23cece69d021
> 
> I bisect it and that is the first broken commit. The commits before are working
> fine.
> 
> I tried to remove your changes but then  I run into this errrors:
> 
> sc_rm_get_memreg_info: mr:38 res:22
> Memreg get info failed, -110
> mu_hal_sendmsg timeout
> sc_rm_is_memreg_owned: mr:39 res:21
> sc_rm_is_memreg_owned: mr:39 res:21
> mu_hal_sendmsg timeout
> 
> Some clue whats wrong here? Do I need to adapt my imx8qm board file?

Update your scfw/atf and they try again.

Regards,
Peng.

> 
> Best regards,
> 
> Oliver

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Peng,

On Tue, Dec 10, 2019 at 11:50 PM Peng Fan <peng.fan@nxp.com> wrote:

> Update your scfw/atf and they try again.

Please update board/freescale/imx8qm_mek/README to point to the
correct ATF/SCFW versions.

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Oliver,

On Tue, Dec 10, 2019 at 11:50 PM Peng Fan <peng.fan@nxp.com> wrote:

> Update your scfw/atf and they try again.

Does it boot if you use the imx_4.19.35_1.0.0 ATF branch?

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Oliver Graute]

On 11/12/19, Fabio Estevam wrote:
> Hi Oliver,
> 
> On Tue, Dec 10, 2019 at 11:50 PM Peng Fan <peng.fan@nxp.com> wrote:
> 
> > Update your scfw/atf and they try again.
> 
> Does it boot if you use the imx_4.19.35_1.0.0 ATF branch?

Unfortunately, not. I checked out imx-atf in that branch. Build it with:

make PLAT=imx8qm bl31

copied the resulting bl31.bin into my u-boot folder and rebuild that.

But the imx8qm board is not booting with the resulting u-boot.

do I need a new scfw from my vendor?

Best Regards,

Oliver

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Igor Opaniuk]

Hi Oliver, Fabio, Peng,

On Thu, Dec 12, 2019 at 9:20 AM Oliver Graute
<oliver.graute@kococonnector.com> wrote:
>
> On 11/12/19, Fabio Estevam wrote:
> > Hi Oliver,
> >
> > On Tue, Dec 10, 2019 at 11:50 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Update your scfw/atf and they try again.
> >
> > Does it boot if you use the imx_4.19.35_1.0.0 ATF branch?
>
> Unfortunately, not. I checked out imx-atf in that branch. Build it with:
>
> make PLAT=imx8qm bl31
>
> copied the resulting bl31.bin into my u-boot folder and rebuild that.
>
> But the imx8qm board is not booting with the resulting u-boot.
>
> do I need a new scfw from my vendor?
>
> Best Regards,
>
> Oliver

FYI,

I do face the same boot issues on colibri-imx8qxp_defconfig ,
In my case using imx_4.19.35_1.0.0 TF-A(ATF) doesn't help too.

Bi-secting also points to this commit.

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Igor,

On Mon, Dec 16, 2019 at 12:29 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> I do face the same boot issues on colibri-imx8qxp_defconfig ,
> In my case using imx_4.19.35_1.0.0 TF-A(ATF) doesn't help too.
>
> Bi-secting also points to this commit.

As we are close to the release, I think we should do a revert.

Could you please send a revert patch to fix the regression?

Thanks

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Igor Opaniuk]

Hi Fabio,

On Mon, Dec 16, 2019, 18:24 Fabio Estevam <festevam@gmail.com> wrote:

> Hi Igor,
>
> On Mon, Dec 16, 2019 at 12:29 PM Igor Opaniuk <igor.opaniuk@gmail.com>
> wrote:
>
> > I do face the same boot issues on colibri-imx8qxp_defconfig ,
> > In my case using imx_4.19.35_1.0.0 TF-A(ATF) doesn't help too.
> >
> > Bi-secting also points to this commit.
>
> As we are close to the release, I think we should do a revert.
>
> Could you please send a revert patch to fix the regression?
>

Sure, will do tomorrow morning asap.Btw, there is also a regression in MMC
subsystem (currently AFK, will look into it and provide more details also
tomorrow), probably the same as explained in the "i.MX8MM-EVK Boot failure"
thread.
Thanks


> Thanks
>

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Igor,

On Mon, Dec 16, 2019 at 6:16 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> Sure, will do tomorrow morning asap.Btw, there is also a regression in MMC subsystem (currently AFK, will look into it and provide more details also tomorrow), probably the same as explained in the "i.MX8MM-EVK Boot failure" thread.

What is the MMC error you see?

It seems we need an equivalent of kernelci.org in U-Boot. We are
seeing lots of regression and we are close to the release.

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Igor Opaniuk]

Fabio,

On Tue, Dec 17, 2019 at 12:47 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Igor,
>
> On Mon, Dec 16, 2019 at 6:16 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> > Sure, will do tomorrow morning asap.Btw, there is also a regression in MMC subsystem (currently AFK, will look into it and provide more details also tomorrow), probably the same as explained in the "i.MX8MM-EVK Boot failure" thread.
>
> What is the MMC error you see?

U-Boot 2019.10-00071-g9c1e982218 (Dec 17 2019 - 12:37:14 +0200)

CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz

DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment

In:    serial at 5a090000
Out:   serial at 5a090000
Err:   serial at 5a090000
Card did not respond to voltage select!
MMC init failed
MISSING TORADEX CONFIG BLOCK
Model: Toradex Colibri iMX8X
Build: SCFW 494c97f3
Boot:  USB
Net:   Could not get PHY for FEC0: addr 2
eth-1: ethernet at 5b040000
Hit any key to stop autoboot:  0


> It seems we need an equivalent of kernelci.org in U-Boot. We are
> seeing lots of regression and we are close to the release.

BTW, we are currently working (internally in Toradex) on LAVA-based
solution for testing both U-boot (hopefully Linaro finally added support for
testing bootloaders, [1]) and Linux kernel.

We plan to automate testing of both BSP downstream and mainline
trees, so it makes sense to configure (that's still under discussion)
some interaction with ML, for example sending notification about
regressions/automatic bi-secting results (analog of
syzbot emails in LKML) etc.

If you have any ideas - we're open to any suggestions/input.

[1] https://connect.linaro.org/resources/bkk19/bkk19-409/

Thanks

--
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Igor Opaniuk]

On Tue, Dec 17, 2019 at 12:56 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
>
> Fabio,
>
> On Tue, Dec 17, 2019 at 12:47 AM Fabio Estevam <festevam@gmail.com> wrote:
> >
> > Hi Igor,
> >
> > On Mon, Dec 16, 2019 at 6:16 PM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:
> >
> > > Sure, will do tomorrow morning asap.Btw, there is also a regression in MMC subsystem (currently AFK, will look into it and provide more details also tomorrow), probably the same as explained in the "i.MX8MM-EVK Boot failure" thread.
> >
> > What is the MMC error you see?
>
> U-Boot 2019.10-00071-g9c1e982218 (Dec 17 2019 - 12:37:14 +0200)
>
> CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz
>
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... Card did not respond to voltage select!
> *** Warning - No block device, using default environment
>
> In:    serial at 5a090000
> Out:   serial at 5a090000
> Err:   serial at 5a090000
> Card did not respond to voltage select!
> MMC init failed
> MISSING TORADEX CONFIG BLOCK
> Model: Toradex Colibri iMX8X
> Build: SCFW 494c97f3
> Boot:  USB
> Net:   Could not get PHY for FEC0: addr 2
> eth-1: ethernet at 5b040000
> Hit any key to stop autoboot:  0

Sorry for the noise about mmc, there was a bug introduced in
c20851b3d8("dm: pinctrl: introduce PINCONF_RECURSIVE option"), which
is already fixed in 44510daea4("dm: pinctrl: fix for introduce
PINCONF_RECURSIVE option")

>
>
> > It seems we need an equivalent of kernelci.org in U-Boot. We are
> > seeing lots of regression and we are close to the release.
>
> BTW, we are currently working (internally in Toradex) on LAVA-based
> solution for testing both U-boot (hopefully Linaro finally added support for
> testing bootloaders, [1]) and Linux kernel.
>
> We plan to automate testing of both BSP downstream and mainline
> trees, so it makes sense to configure (that's still under discussion)
> some interaction with ML, for example sending notification about
> regressions/automatic bi-secting results (analog of
> syzbot emails in LKML) etc.
>
> If you have any ideas - we're open to any suggestions/input.
>
> [1] https://connect.linaro.org/resources/bkk19/bkk19-409/
>
> Thanks
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opaniuk at gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk



-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opaniuk at gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Igor,

On Tue, Dec 17, 2019 at 8:21 AM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> Sorry for the noise about mmc, there was a bug introduced in
> c20851b3d8("dm: pinctrl: introduce PINCONF_RECURSIVE option"), which
> is already fixed in 44510daea4("dm: pinctrl: fix for introduce
> PINCONF_RECURSIVE option")

Excellent: one less regression for us to care about then :-)

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Fabio Estevam]

Hi Igor,

On Tue, Dec 17, 2019 at 7:56 AM Igor Opaniuk <igor.opaniuk@gmail.com> wrote:

> U-Boot 2019.10-00071-g9c1e982218 (Dec 17 2019 - 12:37:14 +0200)

Does it also happen with 2020.01-rc5?

> CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz
>
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... Card did not respond to voltage select!

Looks like a different MMC issue than the one we saw with i.MX8MM EVK.

> BTW, we are currently working (internally in Toradex) on LAVA-based
> solution for testing both U-boot (hopefully Linaro finally added support for
> testing bootloaders, [1]) and Linux kernel.
>
> We plan to automate testing of both BSP downstream and mainline
> trees, so it makes sense to configure (that's still under discussion)
> some interaction with ML, for example sending notification about
> regressions/automatic bi-secting results (analog of
> syzbot emails in LKML) etc.
>
> If you have any ideas - we're open to any suggestions/input.

It would be very helpful to have regression notifications in the
U-Boot mailing lists.

Thanks

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Peng Fan]

> Subject: Re: [U-Boot] [PATCH V3 2/2] core: device: use
> dev_power_domain_on
> 
> Hi Igor,
> 
> On Mon, Dec 16, 2019 at 12:29 PM Igor Opaniuk <igor.opaniuk@gmail.com>
> wrote:
> 
> > I do face the same boot issues on colibri-imx8qxp_defconfig , In my
> > case using imx_4.19.35_1.0.0 TF-A(ATF) doesn't help too.
> >
> > Bi-secting also points to this commit.
> 
> As we are close to the release, I think we should do a revert.
> 
> Could you please send a revert patch to fix the regression?

No, the previous method not check return value of power domain on, so
even if fails, it still continue. However this patch will check the return
value, if power fails, if will return failure. I think this is the issue,
you need check which power domain fails in your side.
Revert this patch is not good.

Thanks,
Peng.

> 
> Thanks

[U-Boot] [PATCH V3 2/2] core: device: use dev_power_domain_on

[Oliver Graute]

On 16/12/19, Igor Opaniuk wrote:
> Hi Oliver, Fabio, Peng,
> 
> On Thu, Dec 12, 2019 at 9:20 AM Oliver Graute
> <oliver.graute@kococonnector.com> wrote:
> >
> > On 11/12/19, Fabio Estevam wrote:
> > > Hi Oliver,
> > >
> > > On Tue, Dec 10, 2019 at 11:50 PM Peng Fan <peng.fan@nxp.com> wrote:
> > >
> > > > Update your scfw/atf and they try again.
> > >
> > > Does it boot if you use the imx_4.19.35_1.0.0 ATF branch?
> >
> > Unfortunately, not. I checked out imx-atf in that branch. Build it with:
> >
> > make PLAT=imx8qm bl31
> >
> > copied the resulting bl31.bin into my u-boot folder and rebuild that.
> >
> > But the imx8qm board is not booting with the resulting u-boot.
> >
> > do I need a new scfw from my vendor?
> >
> > Best Regards,
> >
> > Oliver
> 
> FYI,
> 
> I do face the same boot issues on colibri-imx8qxp_defconfig ,
> In my case using imx_4.19.35_1.0.0 TF-A(ATF) doesn't help too.
> 
> Bi-secting also points to this commit.

Did you made some progress here?

I tried this combination but without success for the imx8qm_rom_7720:

u-boot 2020.01
imx-atf imx_4.19.35_1.1.0
imx-sc-firmware-1.2.7.1.bin
imx-seco-2.3.1.bin

Which latest combination is vaild for the imx8qm_mek board?

Best Regards,

Oliver