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

[Andreas Kemnade <andreas@kemnade.info>]

Hi,

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.

dmesg of high power suspend:
[  769.181793] PM: suspend entry (deep)
[  769.181915] Filesystems sync: 0.000 seconds
[  769.183410] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  769.184875] OOM killer disabled.
[  769.184906] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  769.186462] printk: Suspending console(s) (use no_console_suspend to debug)
[  769.514526] Disabling non-boot CPUs ...
[  769.514556] Successfully put all powerdomains to target state
[  770.024322] musb-hdrc musb-hdrc.0.auto: musb_set_peripheral: already in peripheral mode: 80
[  770.026641] pwrseq_simple wifi_pwrseq: GPIO lookup for consumer reset
[  770.026672] pwrseq_simple wifi_pwrseq: using device tree for GPIO lookup
[  770.026702] pwrseq_simple wifi_pwrseq: No GPIO consumer reset found
[  770.027862] omap_hsmmc 480b4000.mmc: GPIO lookup for consumer cd
[  770.027893] omap_hsmmc 480b4000.mmc: using device tree for GPIO lookup
[  770.027923] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/ocp@68000000/mmc@480b4000[0]'
[  770.027954] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/ocp@68000000/mmc@480b4000[0]'
[  770.028015] omap_hsmmc 480b4000.mmc: using lookup tables for GPIO lookup
[  770.028015] omap_hsmmc 480b4000.mmc: No GPIO consumer cd found
[  770.028045] omap_hsmmc 480b4000.mmc: GPIO lookup for consumer wp
[  770.028045] omap_hsmmc 480b4000.mmc: using device tree for GPIO lookup
[  770.028076] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/ocp@68000000/mmc@480b4000[0]'
[  770.028106] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/ocp@68000000/mmc@480b4000[0]'
[  770.028137] omap_hsmmc 480b4000.mmc: using lookup tables for GPIO lookup
[  770.028137] omap_hsmmc 480b4000.mmc: No GPIO consumer wp found
[  770.028594] OOM killer enabled.
[  770.028625] Restarting tasks ... done.
[  770.142852] PM: suspend exit

yes, some gpio driver is not loaded (not included in
omap2plus_defconfig).

rmmod omap2430 seems to bring back suspend current current to low
currents. 

> 
> > Another strange thing I have hit (I have not done this test before, no
> > idea yet if it is related, but it is also about musb):
> > Connecting a usb cable while serial ports are idle (not in system
> > supend), console serial port does not wake up by input, it reacts again
> > if I unplug usb. If I give usb0 an IP address, I can ping it. No
> > intensive debugging done there yet. Just stumbled across it.  
> 
> Hmm so if you have a usb cable connected and gta04 is a b-device, and
> there is vbus, musb should not currently idle at all.
> 
hmm, if musb and serial idle, and I connect usb, musb should power up.
It seems to work. I have no idea about serial state there. I used the
non-8250-based driver for that test (not the other one), so I do not
need to detach console. Maybe I created some wakeup race when
musb/serial wake up at the same time. because musb causes some console
messages. 

Ok, did not hit the send button... retested with the other console
driver.

> Maybe your uart3 wakeirq is not using the uart3_rx.uart3_rx
> pad but uses some alternative pad and the wakeirq is not working?
> 
Console rx is connected to H20, which is
uart3_rx_irrx = CONTROL_PADCONF_UART3_RTS_SD[31:16]
Nothing strange connected there.

Regards,
Andreas