On Friday 06 October 2006 7:47 pm, Christopher "Monty" Montgomery wrote: > 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...
I know I've described how to do this already in this mistitled thread ... > > 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. Playback starving is the issue of that high level driver. It could for example just emit silence, to keep the stream active ... or take more care not to let that buffer drain. (Even simple strategies can help a lot, like using bigger buffers and ensuring that threads which fill them are realtime and use deadline block I/O scheduling.) > > 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. Bandwidth is guaranteed so long as the endpoint's queue is non-empty. What problem??? > 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. And the way it says "free that allocation" is to let the queue empty. > > > 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. I still think you're mixing them up. :) > When you enable an ISOCH endpoint, a successful open madates that the > bandwidth is guaranteed from that point on, until explicitly released. See, you mix up two of them right there. Enabling an endpoint is automatic after SET_INTERFACE or SET_CONFIGURATION ... a USB level operation. While open() is a filesystem operation issued from a user application, mediated by a driver sitting on top of that USB subsytem. And that driver can interpret open() however it likes, although performing data I/O would be wrong (control I/O is fine). > I will accept that the guarantee doesn't happen until first URB > submission because it is practically not that different. No? I'd say it _is_ very different. A write() or read() is allowed to do data I/O. Sometimes ioctl() is too. But open() is very different from read(), write(), or ioctl(). > But to have > the guarantee revoked any time the stream suffers temporary starvation > misses the entire point of an isochronous stream. The guarantee described above is NEVER revoked. A bandwidth allocation can be released, however; and easily reclaimed. Keep in mind there's no point in allocating bandwidth that's not going to be used, especially when it's easily re-allocated. > 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. If an application wants such a trigger, it should talk to a driver which chooses to SET_INTERFACE to altsetting zero on close(). Otherwise there ** IS NO SUCH TRIGGER ** because nothing has done an explicit shutdown. > > 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? :-) Nope; driver policy. It's probably a good idea to set altsetting zero, to give the device firmware a hint, but it's not required. > > 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... Both Alan and I have pointed you in the right direction, with varying degrees of specificity ... I don't want to be repeating that. > > 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.... Not a good analogy. More accurate would be a jigsaw puzzle ... because you can pull a piece out of the middle, and then safely put it back in the same place. > 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. You're deeply mis-understanding something if you think the reservation is associated with an URB. It's not. It's associated with the endpoint, in the USB spec and in at least the EHCI and OHCI drivers. Associating it with anything else _would_ be incorrect; that's how the budgeting was (wrongly) done on 2.4 kernels. (I don't know if UHCI ripped out that old code yet. Alan's been busy on other stuff.) - Dave ------------------------------------------------------------------------- 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
