On Thu, 11 Oct 2012, Peter Chen wrote: > > You could test all the port status registers. If any of them have the > > PORT_PE bit set and the PORT_SUSPEND bit clear then the delay is > > needed; otherwise it can be skipped. > > I think the condition should like below, as we need to consider remote wakeup. > When remote wakeup occurs, it doesn't need this delay either. > > if (portsc & PORT_PE) && ~(portsc & (PORT_SUSPEND | PORT_RESUME))) > do_delay; It shouldn't make any difference. Whenever PORT_RESUME is set, PORT_SUSPEND has to be set too (the hardware turns both bits off at the same time, when the resume sequence is finished). > I mean the port status before roothub sends resume, only at remote wakeup > situation, that port status will be unsuspended enabled. Yes, because of your buggy EHCI hardware, right? According to the EHCI spec, when a device sends a remote wakeup signal, the port status should continue to have PORT_SUSPEND set until after the driver clears PORT_RESUME. But your hardware doesn't wait. In the end I think it won't matter. Even if a device does send a wakeup request, it still needs the TRSMRCY delay. > > It is needed under these conditions: > > > > The HCD is not ehci-hcd. > If you have only delay above 20ms, and then clear PORT_RESUME, you > still need delay TRSMRCY, as TRSMRCY is the time after PORT_RESUME is > cleared. Whoops, you're right. I got the two delays mixed up. Okay, forget about this condition. > > There is a port on the root hub with suspend status clear > > and enabled status set (which implies there must be a device > > attached to the port, because disconnected ports can't be > > enabled). > > > > Obviously if a port isn't enabled then it doesn't need any delay. > Is it ok to set one hcd flag, like hcd->unsuspended_device_on_port > to get condition at xxx_bus_suspend? Only if you're willing to change all the host controller drivers to make them set that flag! usb_bus_resume() can poll the port statuses to see if there are any enabled, unsuspended ports. If there aren't any, the delay can be skipped. How does that sound? Alan Stern -- 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
