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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
