On Thursday 05 October 2006 12:21 pm, Christopher "Monty" Montgomery wrote:
> > I don't know the details of how ehci-hcd used to implement this. But > > waiting until endpoint_disable is wrong. > > 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. 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. 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. As well as being simpler than scheduling when SET_INTERFACE is called, this is also less wasteful of the limited bandwidth available. > > Then so long as the completion handler submits a new URB, the bandwidth > > will remain reserved -- even if things run slow and a few slots are > > missed. And when the driver stops submitting URBs and the queue drains, > > then the bandwidth can be released right away. No need to wait for > > endpoint_disable; that might not happen until the device is unplugged. > > 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. 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. 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(). Whereas bandwidth allocation is only associated with submitting URBs, normally associated with read() or write(). - 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
