On Tue, 23 Jul 2013, Ming Lei wrote: > On Mon, Jul 22, 2013 at 11:09 PM, Alan Stern <st...@rowland.harvard.edu> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
