David:
I've got a few questions about the API; these issues don't seem to be mentioned in any detail in the kernel sources. They are about how endpoint I/O queues are supposed to be handled. My current understanding is summarized below; please indicate where any mistakes are.
Seems to match my understanding.
There's one point you didn't mention, which can sometimes matter. After completing an urb with any kind of fault -- including unlink -- it's very possible that urb->actual_length be nonzero. Maybe even common. The HCD should avoid discarding that part of the request status.
Basically, all URBs destined for an endpoint go into a single queue, which advances as the HC sees fit. When something abnormal happens:
If an URB terminates with an error, its queue is stopped until
the URB's completion handler returns. Note that an IN transfer
ending early because a short packet was received counts as an error if and only if the URB_SHORT_NOT_OK flag is set.
Right. Stopping is important because otherwise one data block could be written where another one belongs, and only the device driver (not HCD!) can tell if continuing risks thay or not ... it will often unlink all urbs later in the queue, and the hardware must not start them in that case.
If an URB is unlinked, its queue is stopped until the URB's
completion handler returns. Is this true even if the URB wasn't
at the head of its queue?
Right. Think of unlink/cancel as a special driver-initiated error; it's covered by the general rule above. Anyway, how could you know that the URB didn't get to the front of the hardware's queue unless you first stopped that queue from advancing? :)
Queues for isochronous endpoints are handled differently, since
they advance at fixed times. Iso URBs don't terminate if they
get an error. What happens to the remaining members of a queue
when one is deleted? Does the queue stop? Do the following members move forward in time to fill the gap, is the queue simply left with a hole, or are there no guarantees at all?
Right, isochrony is prioritized (at the protocol level!) over any kind of fault handling. Stopping is an anti-goal.
As for unlinking ... I'm thinking "no guarantees" unless (maybe) the driver unlinks all the URBs at once. I'd expect it's a lot simpler to implement holes than anything else, and it's clearly rather messy given the "no stopping" goal.
The UHCI driver currently does not follow these rules exactly.
I'd be most concerned with the bulk queues stopping.
FYI: EHCI currently implements ISO's "completes soon" requirement of unlinking by just letting those requests complete normally ... "soon" for ISO thus being just a few msec longer than if it did tried something complex (and error-prone).
- Dave
Alan Stern
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
