> Well, actually I wanted to know how exactly URB flows through the Linux USB Stack,
>e.g.
> driver allocates URB, submitted to USB Core, goes to HCD, something done there,
> returned to to driver by callback function, etc.
> And how does it apply for all the different transfer modes.
That's the way it works: driver to HCD, then back to driver on completion
or unlink. The USB core is just an intermediary between those two drivers.
Bulk and ISO can be queued in all cases, Control too (except with UHCI).
Periodic urbs get some special treatment, "automagic resubmission" where urbs
don't get handed back to drivers in most completion callbacks. Ownership
of the URB there is in a strange "shared between drivers" state that's a
bit error-prone (among other things).
- Before 2.5, there's an urb->next field used by ISO. If that's non-null
and sets up an urb ring, it arranges a kind of multibuffering. That's
always been superfluous though, since completion callbacks can just do
the resubmission themselves ... thereby detecting an error case that the
automagic mechanism hides. Avoid urb->next in 2.4, it's not needed.
- Interrupt urbs are automagically resubmitted until they're unlinked.
That model is problematic in many cases (like INTR-OUT) and will likely
get simplified later in 2.5 as well.
As for unlinking, driver callbacks detect it by getting one of two different
urb->status codes in the completion callback. Again that's subject to some
simplification in 2.5; it doesn't add value, but has caused some confusion.
> There was once a nice picture about URB around? But I just couldn't find it anymore.
Likely you mean this one. I think it's still pretty up-to-date except
that 2.5 deprecates the notion that drivers be able to allocate URB memory
directly (say, in a structure they free on device disconnect).
- Dave
