On 10/6/06, David Brownell <[EMAIL PROTECTED]> wrote: > On Thursday 05 October 2006 12:21 pm, Christopher "Monty" Montgomery wrote: > > endpoint_disable is where the budget is released, which has > > little/nothing to do with the hardware schedule itself. Once a USB > > periodic endpoint is open()ed, it must be guaranteed to be schedulable > > until it is close()d. > > This needs to be done in the same way for all HCDs, and as Alan pointed > out, that does NOT rely on endpoint_disable(). The endpoint may be valid > but not in use ... only endpoints in use will have bandwidth allocated.
Agreed. I'm waiting for a suggestion as to how... > Linux, as a whole, has chosen to couple periodic (iso and interrupt) > bandwidth allocation to the submission of periodic URBs to the relevant > endpoints. That is, the stream is enabled by submitting the first URB, > and disabled by letting its queue empty. Yes, and that is not causing me any theoretical or practical trouble. > 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. > As well as being simpler than scheduling when SET_INTERFACE is called, > this is also less wasteful of the limited bandwidth available. ...except for the problem that the whole point of an ISOCH stream is guaranteed bandwidth. ISOCH is not fair; it is explicity unfair, by design and by intent, to all other competing demands on bandwidth. The User (through the proxy of His application) is using it for a reason. An isoch stream *is* more important than anythign else the USB subsystem is doing. Once successfully started, it is handled preferentially at every step. It appears first in the schedule and is free to waste as much of its requested allocation as it sees fit. (I appreciate you're explaining this from the beginning as it seems entirely possible there is still some fundamental disconnect here. I'm trying to do the same) > > The intent is that endpoint_disable is called upon close(); in my > > testing (and from the code I read), close would in fact always result > > in an endpoint_disable. > > You're mixing up levels and application policy here. No, although I'm skipping through the layers freely in my explanation because the point could easily get lost in the technical details. I'll try again. 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. 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 close() system > call is several levels above the HCD, and there are several different > drivers that could be involved ... which may use different policies about > when and why to issue USB calls. Yes, but doesn't it always shut down the endpoint? :-) > 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... > Whereas bandwidth allocation is only associated with submitting URBs, > normally associated with read() or write(). ...and that guarantees nothing. Putting together a working full-speed schedule in EHCI is a little like playing Jenga. Once you pull a block out of the middle.... 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. Monty ------------------------------------------------------------------------- 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
