Re: How should we handle isochronous underruns?

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

 



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




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

  Powered by Linux