On Mon, 29 Nov 2004, David Brownell wrote:
> > And don't say this should never happen! Intel UHCI controllers send IRQs
> > for port-change events when the controller is suspended, but not when it
> > is running.
>
> But clearly, UHCI can't use such a solution!
If you mean UHCI can't use a static flag, yes, I agree. But it can use a
scheme in which it explicitly calls mod_timer and del_timer.
> > Come to think of it, since the timer itself is directly accessible in the
> > hcd structure, we don't need these API calls at all. The driver can
> > simply call mod_timer, del_timer, and del_timer_sync.
>
> That might be a better solution all around; though I'm not
> currently clear on when they'd be called.
The biggest question in my mind is whether the core should start the timer
by default when the root hub is registered. I suppose that could be
controlled by a simple flag. Otherwise, for UHCI at least, things aren't
too difficult:
Stop the timer when entering any of the root-hub-suspended
states, if IRQs work (they don't with the Genesys GL880S!);
Synchronously stop the timer when entering the HC suspended state;
Start the timer on other state transitions.
> > It's a problem of synchronization. root_hub->state doesn't get changed to
> > USB_STATE_SUSPENDED at the right time (i.e., while holding the spinlock I
> > described above). I'm concerned about races occurring during the actual
> > transitions, because there are at least three independent pathways for
> > changing the state:
> >
> > HCD root-hub autosuspend triggered by an HCD-private timer,
>
> ... or maybe the one provided by usbcore ...
That would work too, if the HCD used polling.
> > HCD root-hub autoresume because of non-zero status during
> > rh status check (triggered by poll timer or IRQ), and
> >
> > usbcore suspend/resume running in process context with the
> > root hub locked.
>
> If all the hcd->state changes are spinlocked by the HCD, then usbcore
> can ignore the issues.
Yes. Usbcore should pretty much ignore the issues anyway.
> > You are correct that RH_SUSPENDED should be invisible to usbcore. Since
> > drivers will need to know about it,
>
> Why is that?
The driver has to act differently depending on whether it's in the
root-hub-suspended state (i.e., HCD autosuspend) or usbcore-suspended
state. When hub_status_data() indicates an event has occurred, in the
first case the HCD has to resume the root hub transparently, and in the
second it has to ask khubd to call usb_resume_device for the root hub.
The second case can be handled automatically by usbcore, but the HCD
still has to distinguish the two cases.
> > be a good common place to store it. But never mind, I'll make all this
> > stuff private to uhci-hcd.
>
> OHCI has a formal state model (reused by, of all things,
> the isp1x6x chips) that's likewise not known to usbcore.
So there's a good precedent.
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
