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...
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
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.
Alan Stern
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
