Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Felipe Balbi]

Hi,

Tony Lindgren  writes:
> * Felipe Balbi  [151023 09:48]:
>> 
>> Hi,
>> 
>> Tony Lindgren  writes:
>> > From: Tony Lindgren 
>> > Date: Fri, 23 Oct 2015 09:03:22 -0700
>> > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>> >  change
>> >
>> > Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
>> > probe") started automatically ensuring the parent device is enabled when
>> > the child gets probed.
>> >
>> > This however caused a regression for MUSB omap2430 interface as the
>> > runtime PM for the parent device needs the child initialized to access
>> > the MUSB hardware registers.
>> >
>> > Let's delay the enabling of PM runtime for the parent until the child
>> > has been properly initialized as suggested in an earlier patch by
>> > Grygorii Strashko .
>> >
>> > In addition to delaying pm_runtime_enable, we now also need to make sure
>> > the parent is enabled during omap2430_musb_init. We also want to propagate
>> > an error from omap2430_runtime_resume if struct musb is not initialized.
>> >
>> > Note that we use pm_runtime_put_noidle here for both the child and parent
>> > to prevent an extra runtime_suspend/resume cycle.
>> >
>> > Let's also add some comments to avoid confusion between the
>> > two different devices.
>> >
>> > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
>> > trying probe")
>> > Suggested-by: Grygorii Strashko 
>> > Signed-off-by: Tony Lindgren 
>> 
>> I'm fine with this patch to fix this v4.3 regression. Greg, do you want
>> a pull request or can you take this in as a patch ? In any case:
>> 
>> Acked-by: Felipe Balbi 
>
> OK no response for a few days, so I'll pick this up into
> omap-for-v4.3/fixes as I have another fix there too.

all right, thanks


-- 
balbi


signature.asc
Description: PGP signature

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Felipe Balbi  [151023 09:48]:
> 
> Hi,
> 
> Tony Lindgren  writes:
> > From: Tony Lindgren 
> > Date: Fri, 23 Oct 2015 09:03:22 -0700
> > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
> >  change
> >
> > Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
> > probe") started automatically ensuring the parent device is enabled when
> > the child gets probed.
> >
> > This however caused a regression for MUSB omap2430 interface as the
> > runtime PM for the parent device needs the child initialized to access
> > the MUSB hardware registers.
> >
> > Let's delay the enabling of PM runtime for the parent until the child
> > has been properly initialized as suggested in an earlier patch by
> > Grygorii Strashko .
> >
> > In addition to delaying pm_runtime_enable, we now also need to make sure
> > the parent is enabled during omap2430_musb_init. We also want to propagate
> > an error from omap2430_runtime_resume if struct musb is not initialized.
> >
> > Note that we use pm_runtime_put_noidle here for both the child and parent
> > to prevent an extra runtime_suspend/resume cycle.
> >
> > Let's also add some comments to avoid confusion between the
> > two different devices.
> >
> > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
> > trying probe")
> > Suggested-by: Grygorii Strashko 
> > Signed-off-by: Tony Lindgren 
> 
> I'm fine with this patch to fix this v4.3 regression. Greg, do you want
> a pull request or can you take this in as a patch ? In any case:
> 
> Acked-by: Felipe Balbi 

OK no response for a few days, so I'll pick this up into omap-for-v4.3/fixes
as I have another fix there too.

Regards,

Tony


> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
> > }
> > musb->isr = omap2430_musb_interrupt;
> >  
> > +   /*
> > +* Enable runtime PM for musb parent (this driver). We can't
> > +* do it earlier as struct musb is not yet allocated and we
> > +* need to touch the musb registers for runtime PM.
> > +*/
> > +   pm_runtime_enable(glue->dev);
> > +   status = pm_runtime_get_sync(glue->dev);
> > +   if (status < 0)
> > +   goto err1;
> > +
> > status = pm_runtime_get_sync(dev);
> > if (status < 0) {
> > dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> > +   pm_runtime_put_sync(glue->dev);
> > goto err1;
> > }
> >  
> > @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
> > phy_power_on(musb->phy);
> >  
> > pm_runtime_put_noidle(musb->controller);
> > +   pm_runtime_put_noidle(glue->dev);
> > return 0;
> >  
> >  err1:
> > @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
> > goto err2;
> > }
> >  
> > -   pm_runtime_enable(>dev);
> > +   /*
> > +* Note that we cannot enable PM runtime yet for this
> > +* driver as we need struct musb initialized first.
> > +* See omap2430_musb_init above.
> > +*/
> >  
> > ret = platform_device_add(musb);
> > if (ret) {
> > @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
> > struct omap2430_glue*glue = dev_get_drvdata(dev);
> > struct musb *musb = glue_to_musb(glue);
> >  
> > -   if (musb) {
> > -   omap2430_low_level_init(musb);
> > -   musb_writel(musb->mregs, OTG_INTERFSEL,
> > -   musb->context.otg_interfsel);
> > -   }
> > +   if (!musb)
> > +   return -EPROBE_DEFER;
> > +
> > +   omap2430_low_level_init(musb);
> > +   musb_writel(musb->mregs, OTG_INTERFSEL,
> > +   musb->context.otg_interfsel);
> >  
> > return 0;
> >  }
> 
> -- 
> balbi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Grygorii Strashko]

On 10/23/2015 07:48 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Tony Lindgren  writes:
>> From: Tony Lindgren 
>> Date: Fri, 23 Oct 2015 09:03:22 -0700
>> Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>>   change
>>
>> Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
>> probe") started automatically ensuring the parent device is enabled when
>> the child gets probed.
>>
>> This however caused a regression for MUSB omap2430 interface as the
>> runtime PM for the parent device needs the child initialized to access
>> the MUSB hardware registers.
>>
>> Let's delay the enabling of PM runtime for the parent until the child
>> has been properly initialized as suggested in an earlier patch by
>> Grygorii Strashko .
>>
>> In addition to delaying pm_runtime_enable, we now also need to make sure
>> the parent is enabled during omap2430_musb_init. We also want to propagate
>> an error from omap2430_runtime_resume if struct musb is not initialized.
>>
>> Note that we use pm_runtime_put_noidle here for both the child and parent
>> to prevent an extra runtime_suspend/resume cycle.
>>
>> Let's also add some comments to avoid confusion between the
>> two different devices.
>>
>> Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
>> trying probe")
>> Suggested-by: Grygorii Strashko 
>> Signed-off-by: Tony Lindgren 
> 
> I'm fine with this patch to fix this v4.3 regression. Greg, do you want
> a pull request or can you take this in as a patch ? In any case:
> 
> Acked-by: Felipe Balbi 

Reviewed-by: Grygorii Strashko 

It always fun when DD/PM core is updated to fix some driver/subsystem's
specific PM issue :(

> 
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
>>  }
>>  musb->isr = omap2430_musb_interrupt;
>>   
>> +/*
>> + * Enable runtime PM for musb parent (this driver). We can't
>> + * do it earlier as struct musb is not yet allocated and we
>> + * need to touch the musb registers for runtime PM.
>> + */
>> +pm_runtime_enable(glue->dev);
>> +status = pm_runtime_get_sync(glue->dev);
>> +if (status < 0)
>> +goto err1;
>> +
>>  status = pm_runtime_get_sync(dev);

Hm. My assumption was that *Parent* device (omap2430) will be enabled
here :( But as I can see this will not happen:

static int rpm_resume(struct device *dev, int rpmflags)
{...
if (!parent && dev->parent) {
/*
 * Increment the parent's usage counter and resume it if
 * necessary.  Not needed if dev is irq-safe; then the
 * parent is permanently resumed.
 */
parent = dev->parent;
if (dev->power.irq_safe)
goto skip_parent;

^^^ and musb device is irq_safe :( 



>>  if (status < 0) {
>>  dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
>> +pm_runtime_put_sync(glue->dev);
>>  goto err1;
>>  }
>>   
>> @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
>>  phy_power_on(musb->phy);
>>   
>>  pm_runtime_put_noidle(musb->controller);
>> +pm_runtime_put_noidle(glue->dev);
>>  return 0;
>>   
>>   err1:
>> @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
>>  goto err2;
>>  }
>>   
>> -pm_runtime_enable(>dev);
>> +/*
>> + * Note that we cannot enable PM runtime yet for this
>> + * driver as we need struct musb initialized first.
>> + * See omap2430_musb_init above.
>> + */
>>   
>>  ret = platform_device_add(musb);
>>  if (ret) {
>> @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
>>  struct omap2430_glue*glue = dev_get_drvdata(dev);
>>  struct musb *musb = glue_to_musb(glue);
>>   
>> -if (musb) {
>> -omap2430_low_level_init(musb);
>> -musb_writel(musb->mregs, OTG_INTERFSEL,
>> -musb->context.otg_interfsel);
>> -}
>> +if (!musb)
>> +return -EPROBE_DEFER;
>> +
>> +omap2430_low_level_init(musb);
>> +musb_writel(musb->mregs, OTG_INTERFSEL,
>> +musb->context.otg_interfsel);
>>   
>>  return 0;
>>   }
> 


-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Alan Stern]

On Fri, 23 Oct 2015, Grygorii Strashko wrote:

> Reviewed-by: Grygorii Strashko 
> 
> It always fun when DD/PM core is updated to fix some driver/subsystem's
> specific PM issue :(
> 
> > 
> >> --- a/drivers/usb/musb/omap2430.c
> >> +++ b/drivers/usb/musb/omap2430.c
> >> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
> >>}
> >>musb->isr = omap2430_musb_interrupt;
> >>   
> >> +  /*
> >> +   * Enable runtime PM for musb parent (this driver). We can't
> >> +   * do it earlier as struct musb is not yet allocated and we
> >> +   * need to touch the musb registers for runtime PM.
> >> +   */
> >> +  pm_runtime_enable(glue->dev);
> >> +  status = pm_runtime_get_sync(glue->dev);
> >> +  if (status < 0)
> >> +  goto err1;
> >> +
> >>status = pm_runtime_get_sync(dev);
> 
> Hm. My assumption was that *Parent* device (omap2430) will be enabled
> here :( But as I can see this will not happen:
> 
> static int rpm_resume(struct device *dev, int rpmflags)
> {...
>   if (!parent && dev->parent) {
>   /*
>* Increment the parent's usage counter and resume it if
>* necessary.  Not needed if dev is irq-safe; then the
>* parent is permanently resumed.
>*/
>   parent = dev->parent;
>   if (dev->power.irq_safe)
>   goto skip_parent;
> 
> ^^^ and musb device is irq_safe :( 

This way of doing things looks very strange.

If the omap2430 is the parent of the musb device, and
pm_runtime_irq_safe() has been called for the musb device, then after
that the omap2430 will never be runtime suspended.  Therefore it
doesn't matter whether you enable it for runtime PM or not.

It seems to me that the real problem must be that the musb device gets
runtime-enabled and marked irq_safe too early.  These things should 
happen before the musb device gets registered and exposed to userspace, 
but not before the omap2430 parent is runtime-enabled.

Thus the sequence of events should be:

Allocate the musb device;
Runtime-enable the omap2430 (since it is now safe to do so);
Runtime-enable the musb and declare it irq_safe (this will
automatically runtime-resume the omap2430);
Register the musb.

If things are done this way, no special action needs to be taken.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Grygorii Strashko]

On 10/23/2015 02:01 AM, Tony Lindgren wrote:

* Tony Lindgren  [151022 11:03]:

* Tony Lindgren  [151021 16:44]:

Hi all,

I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:

ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")

With the commit above reverted things work fine with DMA and USB gadgets.

This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.

Anybody got ideas what might be wrong? Some wrong runtime PM usage
under drivers/usb/musb?


Here's some more debug info on where things are different initializing
the USB gadgets. I added some printks and diffed the dmesg output. The
added calls from commit ddef08dd00f5 start with dd:


Well turns out the problem actually happens earlier. We end up calling
omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
probing.

No ideas yet how it should be fixed though.



I'm not sure, but below diff might help

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 70f2b8a..aba8ca7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb)
}
musb->isr = omap2430_musb_interrupt;

+   pm_runtime_enable(glue->dev);
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
@@ -626,8 +628,6 @@ static int omap2430_probe(struct platform_device *pdev)
goto err2;
}

-   pm_runtime_enable(>dev);
-
ret = platform_device_add(musb);
if (ret) {
dev_err(>dev, "failed to register musb device\n");




--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Grygorii Strashko  [151023 05:50]:
> On 10/23/2015 02:01 AM, Tony Lindgren wrote:
> >* Tony Lindgren  [151022 11:03]:
> >>* Tony Lindgren  [151021 16:44]:
> >>>Hi all,
> >>>
> >>>I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> >>>and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> >>>
> >>>ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> >>>
> >>>With the commit above reverted things work fine with DMA and USB gadgets.
> >>>
> >>>This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> >>>CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> >>>
> >>>Anybody got ideas what might be wrong? Some wrong runtime PM usage
> >>>under drivers/usb/musb?
> >>
> >>Here's some more debug info on where things are different initializing
> >>the USB gadgets. I added some printks and diffed the dmesg output. The
> >>added calls from commit ddef08dd00f5 start with dd:
> >
> >Well turns out the problem actually happens earlier. We end up calling
> >omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
> >probing.
> >
> >No ideas yet how it should be fixed though.
> >
> 
> I'm not sure, but below diff might help
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 70f2b8a..aba8ca7 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -391,6 +391,8 @@ static int omap2430_musb_init(struct musb *musb)
> }
> musb->isr = omap2430_musb_interrupt;
> 
> +   pm_runtime_enable(glue->dev);
> +
> status = pm_runtime_get_sync(dev);
> if (status < 0) {
> dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> @@ -626,8 +628,6 @@ static int omap2430_probe(struct platform_device *pdev)
> goto err2;
> }
> 
> -   pm_runtime_enable(>dev);
> -
> ret = platform_device_add(musb);
> if (ret) {
> dev_err(>dev, "failed to register musb device\n");

Well almost.. We need to now also ensure that things are enabled during
omap2430_musb_init. Something like this might be the minimal fix for the
-rc cycle.

8< -
From: Tony Lindgren 
Date: Fri, 23 Oct 2015 09:03:22 -0700
Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
 change

Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
probe") started automatically ensuring the parent device is enabled when
the child gets probed.

This however caused a regression for MUSB omap2430 interface as the
runtime PM for the parent device needs the child initialized to access
the MUSB hardware registers.

Let's delay the enabling of PM runtime for the parent until the child
has been properly initialized as suggested in an earlier patch by
Grygorii Strashko .

In addition to delaying pm_runtime_enable, we now also need to make sure
the parent is enabled during omap2430_musb_init. We also want to propagate
an error from omap2430_runtime_resume if struct musb is not initialized.

Note that we use pm_runtime_put_noidle here for both the child and parent
to prevent an extra runtime_suspend/resume cycle.

Let's also add some comments to avoid confusion between the
two different devices.

Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
trying probe")
Suggested-by: Grygorii Strashko 
Signed-off-by: Tony Lindgren 

--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
}
musb->isr = omap2430_musb_interrupt;
 
+   /*
+* Enable runtime PM for musb parent (this driver). We can't
+* do it earlier as struct musb is not yet allocated and we
+* need to touch the musb registers for runtime PM.
+*/
+   pm_runtime_enable(glue->dev);
+   status = pm_runtime_get_sync(glue->dev);
+   if (status < 0)
+   goto err1;
+
status = pm_runtime_get_sync(dev);
if (status < 0) {
dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
+   pm_runtime_put_sync(glue->dev);
goto err1;
}
 
@@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
phy_power_on(musb->phy);
 
pm_runtime_put_noidle(musb->controller);
+   pm_runtime_put_noidle(glue->dev);
return 0;
 
 err1:
@@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
goto err2;
}
 
-   pm_runtime_enable(>dev);
+   /*
+* Note that we cannot enable PM runtime yet for this
+* driver as we need struct musb initialized first.
+* See omap2430_musb_init above.
+*/
 
ret = platform_device_add(musb);
if (ret) {
@@ -675,11 +691,12 @@ 

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Felipe Balbi]

Hi,

Tony Lindgren  writes:
> From: Tony Lindgren 
> Date: Fri, 23 Oct 2015 09:03:22 -0700
> Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>  change
>
> Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
> probe") started automatically ensuring the parent device is enabled when
> the child gets probed.
>
> This however caused a regression for MUSB omap2430 interface as the
> runtime PM for the parent device needs the child initialized to access
> the MUSB hardware registers.
>
> Let's delay the enabling of PM runtime for the parent until the child
> has been properly initialized as suggested in an earlier patch by
> Grygorii Strashko .
>
> In addition to delaying pm_runtime_enable, we now also need to make sure
> the parent is enabled during omap2430_musb_init. We also want to propagate
> an error from omap2430_runtime_resume if struct musb is not initialized.
>
> Note that we use pm_runtime_put_noidle here for both the child and parent
> to prevent an extra runtime_suspend/resume cycle.
>
> Let's also add some comments to avoid confusion between the
> two different devices.
>
> Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
> trying probe")
> Suggested-by: Grygorii Strashko 
> Signed-off-by: Tony Lindgren 

I'm fine with this patch to fix this v4.3 regression. Greg, do you want
a pull request or can you take this in as a patch ? In any case:

Acked-by: Felipe Balbi 

> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
>   }
>   musb->isr = omap2430_musb_interrupt;
>  
> + /*
> +  * Enable runtime PM for musb parent (this driver). We can't
> +  * do it earlier as struct musb is not yet allocated and we
> +  * need to touch the musb registers for runtime PM.
> +  */
> + pm_runtime_enable(glue->dev);
> + status = pm_runtime_get_sync(glue->dev);
> + if (status < 0)
> + goto err1;
> +
>   status = pm_runtime_get_sync(dev);
>   if (status < 0) {
>   dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> + pm_runtime_put_sync(glue->dev);
>   goto err1;
>   }
>  
> @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
>   phy_power_on(musb->phy);
>  
>   pm_runtime_put_noidle(musb->controller);
> + pm_runtime_put_noidle(glue->dev);
>   return 0;
>  
>  err1:
> @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
>   goto err2;
>   }
>  
> - pm_runtime_enable(>dev);
> + /*
> +  * Note that we cannot enable PM runtime yet for this
> +  * driver as we need struct musb initialized first.
> +  * See omap2430_musb_init above.
> +  */
>  
>   ret = platform_device_add(musb);
>   if (ret) {
> @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
>   struct omap2430_glue*glue = dev_get_drvdata(dev);
>   struct musb *musb = glue_to_musb(glue);
>  
> - if (musb) {
> - omap2430_low_level_init(musb);
> - musb_writel(musb->mregs, OTG_INTERFSEL,
> - musb->context.otg_interfsel);
> - }
> + if (!musb)
> + return -EPROBE_DEFER;
> +
> + omap2430_low_level_init(musb);
> + musb_writel(musb->mregs, OTG_INTERFSEL,
> + musb->context.otg_interfsel);
>  
>   return 0;
>  }

-- 
balbi


signature.asc
Description: PGP signature

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Alan Stern  [151023 11:27]:
> On Fri, 23 Oct 2015, Grygorii Strashko wrote:
> 
> > Reviewed-by: Grygorii Strashko 
> > 
> > It always fun when DD/PM core is updated to fix some driver/subsystem's
> > specific PM issue :(
> > 
> > > 
> > >> --- a/drivers/usb/musb/omap2430.c
> > >> +++ b/drivers/usb/musb/omap2430.c
> > >> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
> > >>  }
> > >>  musb->isr = omap2430_musb_interrupt;
> > >>   
> > >> +/*
> > >> + * Enable runtime PM for musb parent (this driver). We can't
> > >> + * do it earlier as struct musb is not yet allocated and we
> > >> + * need to touch the musb registers for runtime PM.
> > >> + */
> > >> +pm_runtime_enable(glue->dev);
> > >> +status = pm_runtime_get_sync(glue->dev);
> > >> +if (status < 0)
> > >> +goto err1;
> > >> +
> > >>  status = pm_runtime_get_sync(dev);
> > 
> > Hm. My assumption was that *Parent* device (omap2430) will be enabled
> > here :( But as I can see this will not happen:

Yes the parent child stuff here is very confusing right now :)

> > static int rpm_resume(struct device *dev, int rpmflags)
> > {...
> > if (!parent && dev->parent) {
> > /*
> >  * Increment the parent's usage counter and resume it if
> >  * necessary.  Not needed if dev is irq-safe; then the
> >  * parent is permanently resumed.
> >  */
> > parent = dev->parent;
> > if (dev->power.irq_safe)
> > goto skip_parent;
> > 
> > ^^^ and musb device is irq_safe :( 
> 
> This way of doing things looks very strange.
> 
> If the omap2430 is the parent of the musb device, and
> pm_runtime_irq_safe() has been called for the musb device, then after
> that the omap2430 will never be runtime suspended.  Therefore it
> doesn't matter whether you enable it for runtime PM or not.
> 
> It seems to me that the real problem must be that the musb device gets
> runtime-enabled and marked irq_safe too early.  These things should 
> happen before the musb device gets registered and exposed to userspace, 
> but not before the omap2430 parent is runtime-enabled.
> 
> Thus the sequence of events should be:
> 
>   Allocate the musb device;
>   Runtime-enable the omap2430 (since it is now safe to do so);
>   Runtime-enable the musb and declare it irq_safe (this will
>   automatically runtime-resume the omap2430);
>   Register the musb.
> 
> If things are done this way, no special action needs to be taken.

Yes good point, that requires changing the init for the whole
drivers/musb though. Also, we should reorganize the whole musb and make
the platform glue and musb core drivers completely separate using a
shared interrupt where needed.

For the regression for the -rc series? Do you see any better
alternatives to what I posted?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Alan Stern  [151023 13:34]:
> On Fri, 23 Oct 2015, Tony Lindgren wrote:
> 
> > > Thus the sequence of events should be:
> > > 
> > >   Allocate the musb device;
> > >   Runtime-enable the omap2430 (since it is now safe to do so);
> > >   Runtime-enable the musb and declare it irq_safe (this will
> > >   automatically runtime-resume the omap2430);
> > >   Register the musb.
> > > 
> > > If things are done this way, no special action needs to be taken.
> > 
> > Yes good point, that requires changing the init for the whole
> > drivers/musb though.
> 
> This will have to be done anyway, since the way it is now (if I 
> understand correctly), the musb is registered and made available to 
> userspace before its parent is operational (i.e., at full power).

Yes I agree.

> > Also, we should reorganize the whole musb and make
> > the platform glue and musb core drivers completely separate using a
> > shared interrupt where needed.
> > 
> > For the regression for the -rc series? Do you see any better
> > alternatives to what I posted?
> 
> No.

OK thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Alan Stern]

On Fri, 23 Oct 2015, Tony Lindgren wrote:

> > Thus the sequence of events should be:
> > 
> > Allocate the musb device;
> > Runtime-enable the omap2430 (since it is now safe to do so);
> > Runtime-enable the musb and declare it irq_safe (this will
> > automatically runtime-resume the omap2430);
> > Register the musb.
> > 
> > If things are done this way, no special action needs to be taken.
> 
> Yes good point, that requires changing the init for the whole
> drivers/musb though.

This will have to be done anyway, since the way it is now (if I 
understand correctly), the musb is registered and made available to 
userspace before its parent is operational (i.e., at full power).

> Also, we should reorganize the whole musb and make
> the platform glue and musb core drivers completely separate using a
> shared interrupt where needed.
> 
> For the regression for the -rc series? Do you see any better
> alternatives to what I posted?

No.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Tony Lindgren  [151021 16:44]:
> Hi all,
> 
> I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> 
> ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> 
> With the commit above reverted things work fine with DMA and USB gadgets.
> 
> This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> 
> Anybody got ideas what might be wrong? Some wrong runtime PM usage
> under drivers/usb/musb?

Here's some more debug info on where things are different initializing
the USB gadgets. I added some printks and diffed the dmesg output. The
added calls from commit ddef08dd00f5 start with dd:


+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 0-0048
 twl4030_usb 4807.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
+dd driver_probe_device pm_runtime_put parent 0-0048
+dd __device_attach pm_runtime_get_sync parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 480ab000.usb_otg_hs
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, 
HB-ISO Rx, HB-ISO Tx, SoftConn)
@@ -273,11 +695,24 @@
 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 usb usb1: Product: MUSB HDRC host driver
-usb usb1: Manufacturer: Linux 4.3.0-rc6-5-gb037ac9 musb-hcd
+usb usb1: Manufacturer: Linux 4.3.0-rc6-5-g24b084c musb-hcd
 usb usb1: SerialNumber: musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent musb-hdrc.0.auto
+dd driver_probe_device pm_runtime_get_sync parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent usb1
+dd driver_probe_device pm_runtime_get_sync parent usb1
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 1 port detected
+dd driver_probe_device pm_runtime_put parent usb1
+dd __device_attach pm_runtime_put parent usb1
+dd driver_probe_device pm_runtime_put parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_put parent musb-hdrc.0.auto
 musb musb-hdrc.0.auto _pm_runtime_put
+dd driver_probe_device pm_runtime_put parent 480ab000.usb_otg_hs
+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
 modprobe: module 'usb_core' not found
 userial_init: registered 4 ttyGS* devices
 Mass Storage Function, version: 2009/09/11

The musb driver is using autosuspend like Felipe pointed out offline,
so maybe that's where things go wrong with commit ddef08dd00f5?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Tony Lindgren  [151022 11:03]:
> * Tony Lindgren  [151021 16:44]:
> > Hi all,
> > 
> > I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> > and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> > 
> > ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> > 
> > With the commit above reverted things work fine with DMA and USB gadgets.
> > 
> > This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> > CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> > 
> > Anybody got ideas what might be wrong? Some wrong runtime PM usage
> > under drivers/usb/musb?
> 
> Here's some more debug info on where things are different initializing
> the USB gadgets. I added some printks and diffed the dmesg output. The
> added calls from commit ddef08dd00f5 start with dd:

Well turns out the problem actually happens earlier. We end up calling
omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
probing.

No ideas yet how it should be fixed though.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html