On Mon, 23 Feb 2004, David Brownell wrote:
The UHCI notion of a suspended controller seems to be more like the notion of an "empty schedule", where only the root hub status polling is active.
Or a little more accurately, the schedule is allowed to be nonempty but the controller doesn't execute it. Also, root hub status polling isn't a
Or, the set of "live" transactions is empty. :)
Main point being: UHCI manages it schedule differently. Doesn't mean much except that terminology doesn't match as closely as it might, and could be misleading.
You could add a STARTING state, sort of the obverse of the QUIESCING state. It would behave just like RUNNING except that URB submissions would not be accepted.
... except that one of the first things that happens when you register the root hub is submitting the hub status interrupt transfer. Still seems simpler to me to have the HCD flag when the hardware is really up. Of course that could be a usb_hc_running() call too.
Well, the glue layer already treats root hub URBs differently from others.
That's at a few levels below where the URB would be rejected though.
There's no reason they couldn't be allowed during the STARTING state. The real problem seems to be that the start() method does two things: turn on the controller hardware and register the root hub. It becomes tricky to change the state in between those two events.
I can't see them as two separate events. The hardware and its root hub are synonymous ... if one's running, so's the other. Starting the controller is an atomic operation, from all perspectives outside of the HCD.
- Dave
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
