Ming Lei wrote: > On Fri, Jul 19, 2013 at 5:20 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Thu, 18 Jul 2013, Clemens Ladisch wrote: >>> In any case, there must be _some_ mechanism to explicitly restart >>> a stream. I do not really care if this is some URB flag or some >>> function call. >> >> I prefer a function call over the flag. The function call can easily >> be issued just once, but the completion routine would have to clear the >> flag every time the URB gets used. > > IMO, one good candidate is to do it in usb_set_interface() This will result in a control request to be sent to the device, which might confuse its firmware. > also it is reasonable, see blow: > > From "5.6.3 Isochronous Transfer Packet Size Constraints" of USB spec 2.0: > > All device default interface settings must not include any isochronous > endpoints with non-zero data payload sizes. That's what the spec says. In reality, there are devices that have non- zero data payload sizes in the default interface setting, and have no other alternate setting. > that said all drivers which are using isoc endpoints have to call > usb_set_interface(altsetting) explicitly before starting isoc schedule. But a set_interface request does not necessarily affect a single stream; there are devices that have multiple isochronous and bulk endpoints in a single interface, and where restarting one stream must not affect the others. >> Maybe we can use usb_reset_endpoint() for this purpose after all. It >> is a perfect fit, because we want to tell the HCD to reset the >> isochronous endpoint back to the "start of stream" state. > > I suggest not to introduce extra starting stream function to usb_reset_endpoint(), > and if we have to do this, I suggest to add a new API for the purpose cleanly. I agree. Regards, Clemens -- 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
