Re: How should we handle isochronous underruns?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 23 Jul 2013, Ming Lei wrote:

> On Mon, Jul 22, 2013 at 11:09 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 22 Jul 2013, Ming Lei wrote:
> >
> >> > Not exactly.  The HCD has to keep track of the next available time slot
> >> > for the endpoint.  Some special value, like -1, will indicate that no
> >> > stream is running yet.  So the new function will merely have to set the
> >> > slot value to -1.
> >>
> >> I am wondering if -1 is special enough, since in theory -1 might
> >> be a valid time slot when HCD uses time slot ANDed with (mod - 1).
> >
> > On EHCI, valid time slots run from 0 to 8191 (or less).  On OHCI they
> > run from 0 to 65535.  On UHCI they run from 0 to 1023.
> 
> There are also lots of non-standard HCs, and going to be many in future.
> When one new API is introduced, maybe we can't ignore these HCs, also
> need consider coming HCs.

The authors of those HCDs can implement the new API however they want.

> >> If the API is defined as usb_iso_stream(udev, ep, start), drivers are required
> >> to call usb_iso_stream(udev, ep, 1) before starting stream, and call
> >> usb_iso_stream(udev, ep, 0) after stopping stream.
> >
> > This just adds complexity with no benefit.
> 
> The symmetrical(start, stop) APIs may be easy to understand
> and use, and looks no extra complexity introduced.

I disagree.  (Start) is just as easy to understand as (start,stop).  
Adding "stop" calls that do nothing is indeed extra complexity with no
benefit.

Think about it: What is an HCD going to do when it gets a "stop" call?

> One benefit is that we may remove the assumption of  -1 being
> invalid frame/uframe on all HCs, another one is that HCD can know
> clearly if stream is on or off currently, which might be helpful in the
> future.

This is not an assumption for all HCDs; it is just the way that _my_
HCDs will work.  Other HCDs can implement the new API in a different 
way if the author likes.

> The approach is only helpful if most of isoc drivers need to use
> the new API. Considered most of drivers resubmit isoc URBs inside
> completion handler, we can use this automatic way to decide new
> stream for these drivers and avoid lots of changes.

Have you tried to find the places where an isochronous URB is submitted 
without URB_ISO_ASAP?  Those are the only places that will need to be 
changed.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux