Re: [PATCH] usb: musb: Check devctl status again for a spurious session request

[Andreas Kemnade <andreas@kemnade.info>]

On Fri, 28 May 2021 08:57:56 +0300
Tony Lindgren <tony@atomide.com> wrote:

> Hi,
> 
> * Andreas Kemnade <andreas@kemnade.info> [210527 19:15]:
> > Hi,
> > 
> > On Tue, 18 May 2021 18:06:15 +0300
> > Tony Lindgren <tony@atomide.com> wrote:
> >   
> > > On start-up, we can get a spurious session request interrupt with nothing
> > > connected. After that the devctl session bit will silently clear, but the
> > > musb hardware is never idled until a cable is plugged in, or the glue
> > > layer module is reloaded.
> > > 
> > > Let's just check the session bit again in 3 seconds in peripheral mode
> > > to catch the issue.
> > >   
> > Tested this together with the other musb patch you sent on gta04.
> > This has some interesting side effects.
> > 
> > Test done:
> > - loading kernel+ramdisk via usb-dfu
> > - disconnecting usb cable
> > - loading omap_hdq (to see battery status)
> > - idling serial ports
> > - checking battery current 1.
> > - loading omap2430, phy-twl4030-usb, g_ether
> > - checking battery current 2 (again with idled serial ports).
> > - rtcwake -s 20 -m mem
> > - checking current during suspend (3)
> > 
> > Without your patches: current 2 is current 1 + approx 15 mA, current 3
> > is near current 1.
> > With your patches: current 2 is near current 1, current 3 is approx
> > 15mA higher.  
> 
> Interesting, so power consumption is now better for runtime with cable
> disconnected, and after booting, but now somehow is now worse for
> suspended state. I'll try to reproduce.
> 
I inserted some more dev-dbg
[   60.241790] PM: suspend entry (deep)
[   60.245513] Filesystems sync: 0.000 seconds
[   60.251312] Freezing user space processes ... (elapsed 0.001 seconds) done.
[   60.260040] OOM killer disabled.
[   60.263275] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[   60.272338] printk: Suspending console(s) (use no_console_suspend to debug)
[   60.281311] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_resume
-> this is triggered by what?

[   60.281341] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume
-> and here something stays on...

[   60.346374] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_phy_power_on
[   60.796630] musb-hdrc musb-hdrc.0.auto: musb_suspend begin
[   60.796722] musb-hdrc musb-hdrc.0.auto: musb_suspend end
[   60.796752] musb-omap2430 480ab000.usb_otg_hs: omap2430 suspend
[   60.796783] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_suspend
[   60.796783] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_phy_power_off
[   60.796813] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_suspend
[   60.806549] Disabling non-boot CPUs ...
[   60.806579] Successfully put all powerdomains to target state

forcing omap2430 runtime on before suspend:
[  160.467742] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_resume
[  165.001495] PM: suspend entry (deep)
[  165.005218] Filesystems sync: 0.000 seconds
[  165.010284] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  165.018981] OOM killer disabled.
[  165.022247] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  165.031311] printk: Suspending console(s) (use no_console_suspend to debug)
[  165.040496] musb-hdrc musb-hdrc.0.auto: musb_suspend begin
[  165.040618] musb-hdrc musb-hdrc.0.auto: musb_suspend end
[  165.040618] musb-omap2430 480ab000.usb_otg_hs: omap2430 suspend
[  165.040649] musb-omap2430 480ab000.usb_otg_hs: omap2430 runtime_suspend
[  165.040679] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: twl4030_usb_suspend
[  165.050506] Disabling non-boot CPUs ...
[  165.050537] Successfully put all powerdomains to target state

Regards,
Andreas