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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

* Andreas Kemnade <andreas@xxxxxxxxxxxx> [210527 19:15]:
> Hi,
> 
> On Tue, 18 May 2021 18:06:15 +0300
> Tony Lindgren <tony@xxxxxxxxxxx> 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.

> 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.

Maybe your uart3 wakeirq is not using the uart3_rx.uart3_rx
pad but uses some alternative pad and the wakeirq is not working?

Or the twl4030 usb phy is somehow interfering with the uart3 pins
when usb is in use. Worth checking the schematics again for the
uart3 rx pin used? Sorry I don't remember if omap3 has multiple
alternative pins for uart3, but I think it does.

Regards,

Tony




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux