On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > >>>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. > > > > > > Umm, I just described it. > > > > How about this: > > I added a label for what I think is your third column. > > > > hub driver other driver [ PER-ENDPOINT ACTION ] > > submit_urb bandwidth allocated > > callback bandwidth deallocated > > NYET ^^^^^^^^^^^^^^^^^^^^^ > > > submit_urb bandwidth allocated > > NOT! ^^^^^^^^^^^^^^^^^^^^^ > > > submit_urb failed, insufficient bandwidth > > No, the bandwidth wouldn't have been de-allocated until after the > callback returned ... and since the callback submitted an urb, > it was never de-allocated. (That's the "NYET".) No failure.
You can't do that. The HCD is done with the URB before it makes the callback. However, the example I gave has the submit significantly later, after the callback is done. Remember, this is RESERVATION, not current usage. > The second driver is clearly broken, it has no business using > the hub interface's endpoint! But I'll assume it's some other > thread in the hub driver that decided to do that, so it was > a legit attempt to queue a second transfer. Umm, it doesn't use the hub interface's endpoint. It's just another driver that wants to use the bus. The bus bandwidth is a shared resource. > That "NOT!" is something I didn't add because it wouldn't > come up unless queue lengths got greater than 1, which wasn't > what I was describing. In fact the only time submit_urb > allocates bandwidth is if it's the first urb queued to that > endpoint. (I said that some other places in this thread. The > bandwidth doesn't get allocated twice.) Correction, when it's the *only* URB to that endpoint. You're making the assumption that an URB will always be submitted. > So your picture, updated, should resemble: > > Activity #1 Activity #2 Endpoint Action > ----------- ----------- --------------- > submit schedule, reserving bandwidth > complete () (still scheduled, qlen = 0) > submit (still scheduled, qlen = 1) > (re)submit (still scheduled, qlen = 2) > hcd queuecheck qlen != 0, don't de-schedule > > Is that clearer? If you change what I meant, sure, but it's significantly different. 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
