On 6/30/2013 8:32 PM, Alan Stern wrote:
There are several possible things the HCD could do when an underrun
occurs:
I do not have much experience in working with ISOC host.But by the
experience of device side I can say that, There could be problem
irrespective of tasklet or irq context, only that tasklet would be more
prone to it. Should not we have same approach in handling isoc packet in
either of the cases?
It could schedule the URB for the first time slot known to be
available, even if that means skipping some time slots which
the hardware might (or might not) be able to use.
IMO, this approach is better. But, what should we call as "first time
slot known to be available". Current code calculates it as now (current
time slot) + delta microframe, and delta is kept as fixed. However,
different system works with different values of delta. IMO, This delta
should be dynamic and software should update it on the basis of initial
value and feedback (past failure/missed isoc experience).
It could try to schedule the URB for the next time slot after
the last one used by the preceding URB, even if that time slot
has already expired.
There is no meaning of submitting an URB for expired time slot. In
anyway, it is not going to be transferred and will further result in
under-run/missed packet.
Something in between...
Making this offset dynamic will cause software to be further complex,
but that would be the best way to handle such situation.
Regards
Pratyush
What would be best for your purposes? Or do you have any different
suggestions?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
