diff mbox series

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

Message ID 20190927021230.4175-2-peng.fan@nxp.com
State Accepted
Commit f0cc4eae9a1702a768817ea25d9f23cece69d021
Delegated to: Simon Glass
Headers show
Series [U-Boot,V3,1/2] power: domain: add dev_power_domain_on | expand

Commit Message

Peng Fan Sept. 27, 2019, 1:55 a.m. UTC
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(-)

Comments

Oliver Graute Dec. 10, 2019, 2:18 p.m. UTC | #1
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
Peng Fan Dec. 11, 2019, 2:50 a.m. UTC | #2
> 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
Fabio Estevam Dec. 11, 2019, 3:15 a.m. UTC | #3
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.
Fabio Estevam Dec. 11, 2019, 2:15 p.m. UTC | #4
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?
Oliver Graute Dec. 12, 2019, 7:20 a.m. UTC | #5
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
Igor Opaniuk Dec. 16, 2019, 3:29 p.m. UTC | #6
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.
Fabio Estevam Dec. 16, 2019, 4:24 p.m. UTC | #7
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
Igor Opaniuk Dec. 16, 2019, 9:16 p.m. UTC | #8
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
>
Fabio Estevam Dec. 16, 2019, 10:47 p.m. UTC | #9
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.
Peng Fan Dec. 17, 2019, 1:14 a.m. UTC | #10
> 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
Igor Opaniuk Dec. 17, 2019, 10:56 a.m. UTC | #11
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@5a090000
Out:   serial@5a090000
Err:   serial@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@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@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
Igor Opaniuk Dec. 17, 2019, 11:21 a.m. UTC | #12
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@5a090000
> Out:   serial@5a090000
> Err:   serial@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@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@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk
Fabio Estevam Dec. 17, 2019, 11:22 a.m. UTC | #13
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
Fabio Estevam Dec. 17, 2019, 11:23 a.m. UTC | #14
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 :-)
Oliver Graute Jan. 21, 2020, 10:36 a.m. UTC | #15
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
diff mbox series

Patch

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);