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.
- 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
