On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>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 > > %s/queued/submitted/ > > That logic works in both interesting cases: > > - "one urb no queueing", as it said at the top; or > - "N urbs queued", as it said (more generally) later > > Sorry to have confused you.
Same thing. Take the hub driver for instance. It doesn't queue URB's and it only has 1 submitted at anytime. It needs to resubmit it after it completes. With the way it is right now, with enforcing bandwidth reservation, there's the possibility that resubmit will fail for lack of bandwidth. That is unacceptable. Period. 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
