On Thu, 18 Jul 2013, Ming Lei wrote: > On Thu, Jul 18, 2013 at 3:24 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 4 Jul 2013, Alan Stern wrote: > > > >> On Thu, 4 Jul 2013, Ming Lei wrote: > >> > >> > >> If so, your coming change may break ABI because as you described > >> > >> that "the flag should be set in the first URB of a new stream", but > >> > >> some user-space drivers may not set it before. Even USB audio driver > >> > >> doesn't set it in current -next tree. > > > > I had some more ideas about this. Instead of requiring drivers to set > > URB_ISO_ASAP on just the first URB of an isochronous stream, we could > > ask drivers to call usb_reset_endpoint() between streams. This would > > tell the HCD that the next URB marks the start of a new stream, with no > > need for a special flag. > > This idea still requires changes from old drivers. > > Also it might be not appropriate to call usb_reset_endpoint() in this case > because other host controller's implementation may do other unnecessary > thing for this situation. Perhaps. I doubt that HCDs need to do anything when they reset an isochronous endpoint, but you're right. It's safer to avoid the issue. > > Another possibility, which would be even simpler, is for HCDs to assume > > that if the endpoint's queue has been empty for more than 100 ms then a > > new stream is starting. Then drivers wouldn't have to do anything > > special at all. (Unless they are stopping and restarting streams very > > rapidly, in which case something like usb_reset_endpoint() would be > > In this case, we may use changing altsetting to decide start of streaming. Yes indeed. But that could still require changes to old drivers. To be even more safe, unlinking an URB should mark the end of a stream. That's what snd-usb-audio does when it closes a stream; it kills all the outstanding URBs. > > necessary.) > > IMO, this one should be OK, and looks it is a bit similar with unlinking > empty interrupt qh. In fact, it's necessary: ehci-hcd doesn't keep track of the state of a stream beyond 512 ms or so. 100 ms might even be overkill. No stream should ever have a gap that large unless something has gone drastically wrong, in which case it doesn't much matter what we do. (Except perhaps for isochronous endpoints with a period of 128 ms or more. I have never heard of such things; have you?) 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
