[Letux-kernel] [PATCH] usb: musb: Check devctl status again for a spurious session request
andreas at kemnade.info
Fri May 28 11:37:15 CEST 2021
On Fri, 28 May 2021 08:57:56 +0300
Tony Lindgren <tony at atomide.com> wrote:
> * Andreas Kemnade <andreas at kemnade.info> [210527 19:15]:
> > Hi,
> > On Tue, 18 May 2021 18:06:15 +0300
> > Tony Lindgren <tony at 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 at 68000000/mmc at 480b4000'
[ 770.027954] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/ocp at 68000000/mmc at 480b4000'
[ 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 at 68000000/mmc at 480b4000'
[ 770.028106] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/ocp at 68000000/mmc at 480b4000'
[ 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
rmmod omap2430 seems to bring back suspend current current to low
> > 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
Ok, did not hit the send button... retested with the other console
> 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.
More information about the Letux-kernel