On Wed, 3 Aug 2005, Alan Stern wrote:
> On Wed, 3 Aug 2005, Olav Kongas wrote: > > > Hi Alan, > > > > I started to look at the new polling scheme for root hub > > status implemented by you in usb core recently. > > > > As the isp116x supports status change interrupts in both > > running and suspended states, I just had to set > > hcd->uses_new_polling = 1 at probing and call > > usb_hcd_poll_rh_status(hcd) when Status Change or Remote > > Detected interrupts arrive. > > > > Now, usb_hcd_poll_rh_status() calls immediately > > hcd->driver->hub_status_data(). However, it turns out that > > if waking isp116x up by, say moving a mouse, it takes about > > 10ms before the status bits are stabilized in the port > > status register and anything reasonable can be read out. > > Reading ealier leads to bogus info resulting in warnings > > like "port 2 disabled by hub (EMI?), re-enabling..." and > > re-enumeration of the devices behind the port will follow. > > mdelay(10) right before calling usb_hcd_poll_rh_status() in > > the interrupt handler solves the problem, but is not an > > attractive solution. > > > > It may be that other HCs will need a delay as well. It would > > be nice, if usb_hcd_poll_rh_status() would handle a delay > > (requested via struct usb_hcd or by other means) so that > > calling of hcd->driver->hub_status_data() would be scheduled > > to be called later. Or are there better solutions? > > Hmmm... So far I haven't heard of other controllers requiring a delay, > but there certainly could be some -- especially among the low-power > platform-specific ones. > > This delay would only apply when the HC is waking up from a sleep state, > right? So a lot of the time it won't be necessary... No. I haven't tested other configurations, but my corrent device tree is: rh-port -> external hub -> mouse. If I suspend just the corresponding rh-port, leaving the root hub running, and then move the mouse, it still takes 10ms for a port status register to stabilize. > I think the easiest solution will be for your HCD to test whether a delay > is needed. If not, go ahead and call usb_hcd_poll_rh_status as usual. If > a delay is needed, then do Relying on Resume Detected interrupt won't suffice, because when suspending just a root hub port like above, the chip won't generate Resume Detected but just Status Change. So, the only sources of information to decide about the necessity of delay I can think of would be those not jet stabilized status registers :( But I think it is OK to always use the delay. > > mod_timer(&hcd->rh_timer, jiffies + msecs_to_jiffies(10)); > > This is the timer used by the root-hub polling code, so when it expires > your root hub will be polled like you want. So long as you keep > hcd->poll_rh equal to 0, the timer will not be re-enabled after it > expires. > > You will also have to modify your hub_status_data routine. If the HC is > suspended, it should return 0 rather than an error. It just might end up > getting called, if a suspend occurs during that 10-ms delay period. Will do some more testing, but with your proposed scheme it now works here nicely. Thanks. Olav ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
