Hi Vishal Thanki <vishal.thanki@xxxxxxxxx> writes: > 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. that might be the correct fix. Bin, any comments ? -- balbi
Attachment:
signature.asc
Description: PGP signature
