On Mon, 1 Jul 2013, Pratyush Anand wrote: > 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? Of course we should. > > 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). Clemens disagrees, and I accept his recommendation. > > 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. That is not true. For example, suppose 2 time slots have already expired, but the submitted URB contains 5 packets. Even though it's too late for the first two packets, the last three can still be transferred. Alan Stern -- 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
