diff mbox series

[RFC,1/2] hack to boot with 2020.01

Message ID 20200203135619.10180-2-oliver.graute@kococonnector.com
State Superseded
Headers show
Series [RFC,1/2] hack to boot with 2020.01 | expand

Commit Message

Oliver Graute Feb. 3, 2020, 1:59 p.m. UTC
As proposed here:

https://lists.denx.de/pipermail/u-boot/2020-January/396749.html

Both of my imx8qm boards (Advantech and Congatec) aren't booting
2020.01 without this change. Whats the proper way to fix this on my side?
---
 drivers/core/device.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

Comments

Simon Glass Feb. 3, 2020, 5:15 p.m. UTC | #1
Hi Oliver,

On Mon, 3 Feb 2020 at 06:59, Oliver Graute
<oliver.graute at kococonnector.com> wrote:
>
> As proposed here:
>
> https://lists.denx.de/pipermail/u-boot/2020-January/396749.html
>
> Both of my imx8qm boards (Advantech and Congatec) aren't booting
> 2020.01 without this change. Whats the proper way to fix this on my side?

Possibly one of the drivers is doing something in ofdata_to_platdata()
that it should be doing in probe()?

You should check what error dev_power_domain_on() is returning.

One trick is to add

   return log_msg_ret("some msg", ret);

to all the error returns, define CONFIG_LOG and LOG_ERROR_RETURN and
you should get some detail.

Regards,
Simon


> ---
>  drivers/core/device.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 4e037083a6..8358051d60 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -395,11 +395,8 @@ int device_probe(struct udevice *dev)
>
>         if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
>             (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> -           !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> -               ret = dev_power_domain_on(dev);
> -               if (ret)
> -                       goto fail;
> -       }
> +           !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> +               dev_power_domain_on(dev);
>
>         ret = uclass_pre_probe_device(dev);
>         if (ret)
> --
> 2.17.1
>
Tom Rini Feb. 4, 2020, 5:07 p.m. UTC | #2
On Mon, Feb 03, 2020 at 01:59:14PM +0000, Oliver Graute wrote:
> As proposed here:
> 
> https://lists.denx.de/pipermail/u-boot/2020-January/396749.html
> 
> Both of my imx8qm boards (Advantech and Congatec) aren't booting
> 2020.01 without this change. Whats the proper way to fix this on my side?
>
> ---
>  drivers/core/device.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 4e037083a6..8358051d60 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -395,11 +395,8 @@ int device_probe(struct udevice *dev)
>  
>  	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
>  	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> -	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> -		ret = dev_power_domain_on(dev);
> -		if (ret)
> -			goto fail;
> -	}
> +	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> +		dev_power_domain_on(dev);
>  
>  	ret = uclass_pre_probe_device(dev);
>  	if (ret)

Adding Lokesh and quoting him from
http://patchwork.ozlabs.org/patch/1211325/

"Can you check by not returning on failure here? If yes then check the
power-domain/driver that is failing. If any driver doesn't expect core
to enable power-domain then enable DM_FLAG_DEFAULT_PD_CTRL_OFF in the
respective driver."
Oliver Graute Feb. 5, 2020, 8:48 a.m. UTC | #3
On 04/02/20, Tom Rini wrote:
> On Mon, Feb 03, 2020 at 01:59:14PM +0000, Oliver Graute wrote:
> > As proposed here:
> > 
> > https://lists.denx.de/pipermail/u-boot/2020-January/396749.html
> > 
> > Both of my imx8qm boards (Advantech and Congatec) aren't booting
> > 2020.01 without this change. Whats the proper way to fix this on my side?
> >
> > ---
> >  drivers/core/device.c | 7 ++-----
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/core/device.c b/drivers/core/device.c
> > index 4e037083a6..8358051d60 100644
> > --- a/drivers/core/device.c
> > +++ b/drivers/core/device.c
> > @@ -395,11 +395,8 @@ int device_probe(struct udevice *dev)
> >  
> >  	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
> >  	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
> > -	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
> > -		ret = dev_power_domain_on(dev);
> > -		if (ret)
> > -			goto fail;
> > -	}
> > +	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
> > +		dev_power_domain_on(dev);
> >  
> >  	ret = uclass_pre_probe_device(dev);
> >  	if (ret)
> 
> Adding Lokesh and quoting him from
> http://patchwork.ozlabs.org/patch/1211325/
> 
> "Can you check by not returning on failure here? If yes then check the
> power-domain/driver that is failing. If any driver doesn't expect core
> to enable power-domain then enable DM_FLAG_DEFAULT_PD_CTRL_OFF in the
> respective driver."

I tried, if I'am not returning on failure here. U-Boot boots well and
any logging shows me a return value 0 for dev_power_domain_on(). As soon
as I add the if statement with the goto fail U-Boot is stuck and I don't
see any msg on the uart neither return value for dev_power_domain_on.

So currently I can't tell which power-domain driver cause the issue.

Best Regards,

Oliver
diff mbox series

Patch

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 4e037083a6..8358051d60 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -395,11 +395,8 @@  int device_probe(struct udevice *dev)
 
 	if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
 	    (device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
-	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
-		ret = dev_power_domain_on(dev);
-		if (ret)
-			goto fail;
-	}
+	    !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
+		dev_power_domain_on(dev);
 
 	ret = uclass_pre_probe_device(dev);
 	if (ret)