Johannes Erdfelt wrote: > 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.
I suspect you've stayed confused then. > 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. In the pseudocode above, where is that possibility? I don't see it. - Dave ------------------------------------------------------- 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
