On Fri, 6 Oct 2006, Christopher "Monty" Montgomery wrote: > > Processing completion of a > > given periodic URB will normally involve resubmitting it, so the queue > > won't drain unless the driver explicitly stops its resumbit logic. > > What if the high-level driver's buffer drains? It is possible I have > the mechanism incorrect-- but in the old driver, I'd see playback > starve and the stream would be released. Printing out the stream > depth indicated that the URBs completed and not resubmitted. > stream->depth hit zero and the stream was free()d.
Repeating what I've said several times already... The high-level driver doesn't need to stop resubmitting URBs merely because its buffer has drained. So long as it doesn't stop resubmitting, it won't lose its reserved bandwidth. > When you enable an ISOCH endpoint, a successful open madates that the > bandwidth is guaranteed from that point on, until explicitly released. > I will accept that the guarantee doesn't happen until first URB > submission because it is practically not that different. But to have > the guarantee revoked any time the stream suffers temporary starvation > misses the entire point of an isochronous stream. No it doesn't. It's merely an implementation detail. To satisfy the requirements, a driver only needs to make sure that the stream never starves. It can easily do so, regardless of whether it has any data available to send. It can even submit 0-length ISO URBs, if need be, just to keep the stream alive. > By 'close()' I meant only some trigger that reliably happens when an > endpoint is finally, explicitly, shut down. From an application's > perspective, close() is one obvious candidate, and probably the one > the app developer would expect unless the docs said otherwise. The point you're missing is that the application communicates with the higher-level driver, not with ehci-hcd. The driver is free to take close() as an indication that the endpoint queue should be drained. Or it can use some different trigger; it's entirely up to the driver. And ehci-hcd doesn't have to know or care. > > Calls to endpoint_disable() are side effects of USB calls which change > > configuration (SET_CONFIGURATION, SET_INTERFACE), or disconnection. > > So for example one driver might include a SET_INTERFACE in its open() > > and/or close() calls, another might trigger that with ioctl() or write(). > > I see that now, and yes, tying to that is an error. You can see what > I was trying to do, please suggest an alternative... The "alternative" is what we've been using all along! Streams get shut down when their queue drains completely. Period. > > Whereas bandwidth allocation is only associated with submitting URBs, > > normally associated with read() or write(). > > ...and that guarantees nothing. That's ridiculous. It guarantees exactly what it says: As long as URBs continue to be submitted the bandwidth will remain allocated. > Isoch is not intended to be efficient or fair. It places guaranteed > bandwidth above all other considerations. Associating the bandwidth > reservation piecemeal with individual URBs is incorrect. It's not associated piecemeal with individual URBs; it's associated with continuity of the stream. Drivers _can_ guarantee that continuity whenever they want to. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
