Hi, On Tue, Feb 9, 2016 at 3:51 PM, Vishal Thanki <vishalthanki@xxxxxxxxx> wrote: > On Mon, Feb 08, 2016 at 08:44:19PM +0200, Felipe Balbi wrote: >> >> 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. >> > > I tried on v4.4. I have to take the patches from Dave so that PM can work > on am33xx platform. The patches are taken from here, and rebased to v4.4 > vanilla kernel. > > https://github.com/dgerlach/linux-pm/commits/pm-v4.3-rc1-amx3-suspend > >> > 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? > > In both, working and non-working case, the execution is not entering into any > of the "if" blocks. I have made sure that by putting prints as can be > seen in the attached patch. > >> >> > 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... >> > > Hmm, I have attached the logs for kernel v4.4 for working and > non-working case. I noticed that the CONNECT interrupt now comes a > little late (not within ~200 ms). However in working case, it always > occurs before the hub_port_reset(). > Just to add information, the MUSB controller is acting as host and is using the TI DSPS (musb_dsps.c) glue layer driver. With that said, I noticed that commit "869c59782981" added a flag to deassert the RESET on resume. But actually the MUSB_POWER_RESET is not set while calling musb_bus_resume(). Does a de-assert of RESET really required even if MUSB_POWER_RESET is not set. If I add a condition for MUSB_POWER_RESET to be to call the deassert reset, I do not hit the issue, because in that case the musb->port1_status does not contain valid flags and hub_port_reset() fails, hence the device is logically disconnected and rediscovered again. Thanks, Vishal >> -- >> balbi > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
