On Sat, Oct 12, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > >>>a) It depends on queuing > >>>b) It doesn't reserve the bandwidth > >>> > >>>Each in itself make it unacceptable. > >> > >>On the other hand, neither of those is true either. Which is > >>part of why I don't see any problem ... :) > > > > With a move to non automagic resubmit, the HCD *MUST* release any > > bandwidth when it's done, because that's the last URB it knows about for > > that endpoint. > > > > As a result, there will always be a race with resubmitting the URB and > > acquiring the bandwidth again. > > What race? What re-acquiring? With one urb and no queueing: > > - driver submits urb. hcd: > * allocates bandwidth > * queues that transfer to the hc > - millions of picoseconds pass > - transfer completes. hcd: > * cleans up urb-specific state > * gives back the urb (issuing completion) > - NOW it's done, so either: > * the endpoint has some urb queued (same one resubmitted?) > * there's no urb queued > - if there's no urb queued, deallocate the bandwidth > > The bandwidth is unavailable so long as that driver keeps an urb > active on that endpoint -- ONE urb, queuing not required. And > that bandwidth is sure reserved: nobody else can use it.
Exactly. See point A above: a) It depends on queuing There is absolutely no good reason to require drivers use queuing to ensure that entire USB stack works correctly. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
