On Thu, Dec 12, 2019 at 08:09:46AM -0800, Tony Lindgren wrote: > Hi, > > * Bin Liu <b-liu@xxxxxx> [191212 16:02]: > > Hi Tony, > > > > Sorry for my late response. > > No worries. > > > On Mon, Nov 25, 2019 at 07:41:51PM -0800, Tony Lindgren wrote: > > > When disconnected as USB B-device, we sometimes get a suspend interrupt > > > after disconnect interrupt. In that case we have devctl set to 99 with > > > VBUS still valid and musb_pm_runtime_check_session() wrongly things we > > > have an active session. We have no other interrupts after disconnect > > > coming in this case at least with the omap2430 glue. > > > > I don't have an omap2430 platform to test, but its musb doesn't generate > > DISCONNECT interrupt at all when disconnected from USB host in any case? > > It is a surprise, the musb core driver expects the DISCONNECT interrupt > > after VBUS is lost and relies on it to tear down the gadget driver and > > the state machine. I am wondering how its USB is functional without the > > DISCONNECT event... > > We do get DISCONNECT, but we can then get a SUSPEND after DISCONNECT > has already happened.. Ahh, I missed the first sentence in the commit log... Now I understand the issue. Thanks. > > That will wake up musb waiting for further interrupts thinking it's > connected. But after that there are no more interrupts as the cable > is disconnected so we need to poll the status again. > > If we see SUSPEND before DISCONNECT, then things idle fine. Does SUSPEND always comes after DISCONNECT on omap2430, or just sometimes? I guess the USB connector has some issue - when DP/DM pins are disconnected, SUSPEND interrupt is generated; when VBUS/GND pins are disconnected, DISCONNECT interrupt is generated. Because DP/DM pins are shorter than VBUS/GND, SUSPEND should come before DISCONNECT. -Bin.
