On Wed, 4 Oct 2006, Christopher "Monty" Montgomery wrote: > > Is it possible to tell the scheduler that the iso stream has stopped/ > > restarted, without calling usb_set_interface()? In theory, setting > > start_frame (instead of using ISO_ASAP) should be able to do this ... > > Closing and reopening the device would be the only way currently to do > it. The driver assumes all submissions set ISO_ASAP, which isn't > correct, but there you have it. That should be easier to fix with the > new code. > > OTOH, an 'underrun' is nothing more and nothing less than the > scheduler informing the upper layers that the stream had a gap. It is > not a true error condition, and there is no heavyweight cleanup or > re-setup. The next URB submission will start transfers right back up > with no more complexity than an uninterrupted streaming submission. > > In short, it's unfortunate that the only feedback is through an > 'error' return status, but I don't believe that design is > fundamentally flawed or misguided. Everything at each layer is > working as it's supposed to, and drivers making use of isochronous > endpoints should realize that an underrun status can happen, just like > EAGAIN can happen. At least when it happens in prepare, we can be > sure it is entirely ignorable. > > The only thing I didn't like is the overload of EL2NSYNC.
I don't fully understand this, but my impression is that it is wrong. Bandwidth is allocated in the USB budget as soon as the first URB of a stream is submitted. That bandwidth remains allocated until the stream is interrupted, which happens whenever there are no URBs queued for the endpoint and the last completion handler has returned. This means that a driver doesn't need to do anything special to stop a stream and release its bandwidth reservation. All it has to do is stop submitting new URBs and wait for the old ones to complete (it can unlink them if it wants to hurry things along). The only way a "gap" could arise is if something prevents the host controller driver from giving back a completed URB or the device driver from submitting a new URB in a timely manner. When the new URB finally does get submitted too late, some of its transactions will get errors because they were not scheduled until after their time had already passed. In such situations uhci-hcd returns -EXDEV in urb->iso_frame_desc[n].status. That can be changed, of course, to remain consistent with other HCDs. But at least EXDEV is already documented. 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
