On Fri, 5 Mar 2004, David Brownell wrote: > 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.
Yes, right. > > 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. Another thing I forgot to mention: If a control transfer terminates with an error, the final status stage acknowledgment will most likely not take place. If it stops early because of a short packet but URB_SHORT_NOT_OK _isn't_ set, then it's not an error and the status stage does occur. > > 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? :) You couldn't know that. But if the queue is stopped, you could restart it _before_ invoking the completion handler. That's what I was really checking. > > 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. "No guarantees" sounds best. > > 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). Doesn't that depend on how much data has been queued? Incidentally, the changes in store for the UHCI driver will make it possible to queue iso transfers way into the future (just as a side effect, but the capability will be there). I don't know if anyone cares about this. 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
