Hi, Vishal Thanki <vishalthanki@xxxxxxxxx> writes: > It is vanilla kernel v4.0, except for some ASoC patches and v5 of Dave's PM > series from kernel v3.19-rc5 rebased to it. Care to try *real* vanilla v4.4 instead ? v4.5-rc3 would be even better. Take *no* extra patches. > If a USB storage device is plugged in before suspend and keep is plugged in > during resume, the resume is taking ~15+ seconds. I noticed that it fails while > sending USB control messages in hub_port_init(): > > http://lxr.free-electrons.com/source/drivers/usb/core/hub.c#L4390 > > After the failure, the USB device is logically disconnected and rediscovered > again. So I can see the device mounted once the system is resumed, but it > takes more time during resume. > > I observed that during system resume, there is a CONNECT interrupt received > by MUSB controller: > > http://lxr.free-electrons.com/source/drivers/usb/musb/musb_core.c#L772 > > If the hub_port_init() is started before the CONNECT interrupt is > served, I am hitting the issue. Almost every time the CONNECT > interrupt is occurring ~150ms after musb_start() is invoked from > musb_resume(). If I add a wait of ~200ms in musb_resume() just to make > sure that CONNECT interrupt is received, I never hit the issue. interesting, sounds like a bug in the ordering of calls in musb_resume(). Can you see if you're falling in either of these branches on the failing case ? mask = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_FSDEV | MUSB_DEVCTL_LSDEV; if ((devctl & mask) != (musb->context.devctl & mask)) musb->port1_status = 0; if (musb->need_finish_resume) { musb->need_finish_resume = 0; schedule_delayed_work(&musb->finish_resume_work, msecs_to_jiffies(USB_RESUME_TIMEOUT)); } Any differences in this regard on the working case? > I see that hub_port_init() is calling hub_port_reset before actually > sending the USB > control messages. The hub_port_reset() internally sets the RESET bit > in MUSB POWER > register, but I am not sure if that is a valid operation before > getting the CONNECT interrupt. hub_port_reset(), IMO, shouldn't run before it knows there are devices connected to the bus... -- balbi
Attachment:
signature.asc
Description: PGP signature
