On Fri, Jul 19, 2013 at 6:36 PM, Ming Lei <tom.leiming@xxxxxxxxx> wrote:
> On Fri, Jul 19, 2013 at 6:30 PM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
>> Ming Lei wrote:
>>> On Fri, Jul 19, 2013 at 5:06 PM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
>>>> Ming Lei wrote:
>>>>> if (list_empty (&stream->td_list)) {
>>>>> if (running from hcd interrupt or tasklet context)
>>>>> underrun
>>>>> else
>>>>> new stream
>>>>> }
>>>>
>>>> Why shouldn't a driver start a stream in an interrupt/tasklet,
>>>
>>> It should, but actually one driver won't do this because generally
>>> usb_set_interface() is required before starting stream.
>>
>> Not always, and the usb_set_interface() call can be done in a different
>> context.
>>
>>> If stream is started in another non-isoc URB complete(), this approach
>>> can cover this situation easily.
>>>
>>> But do you have examples in which one isoc stream is started in another
>>> isoc URB's complete()?
>>
>> There are quite a few audio devices using implicit rate feedback, where
>> playback URBs are submitted from the capture completions handler.
>
> That still can be covered easily by the approach since isoc direction is
> different, :-)
Even we can introduce one flag of 'completing' in 'struct urb' to check if
the USB's submit is called inside its own complete(), by which we can
check if resubmission is in underrun easily.
Consider that isoc URB's resubmission in completion handler should
cover 99% cases, I think this approach is doable.
For other resubmission from tasklet or workque cases, either let them alone
or move the resubmission inside completion() handler, or introduce simple
helper to mark start of frame only for them. Anyway, there are very few isoc
resubmissions from non-completion handler (only two drivers found in my
urb complet() cleanup work), so it shouldn't be a big deal.
What do you think about this approach?
Thanks,
--
Ming Lei
--
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
