On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > Clement and Laurent: > > The two of you seem to be the people who make the most use of > isochronous USB transfers. Since the ehci-hcd driver is being changed > to use a tasklet for URB completion callbacks, it looks like I will > need to reconsider how isochronous underruns get handled.
Without using tasklet, the hard interrupt handler still can be delayed for some time, and switching to tasklet doesn't change the fact of the probable delay of URB handling. > > The basic prolem is simple enough: What should the HCD do when an > URB is submitted after an isochronous pipeline has emptied out? I think some time-related data should be helpful for the discussion, for example, how long the isochronous pipeline may become empty in current audio/video driver(application) without any URB resubmit during the period? > > The problem will be more acute than in the past, because URB > resubmissions will no longer be synchronous with URB completions, > thanks to the tasklet. That is, in the current code, if the completion > handler resubmits the URB, the resubmission occurs before the HCD > finishes the completion callback. But in the new code, the HCD will > simply hand the URB over to the tasklet, and the resubmission won't > occur until some time later (when the tasklet wakes up and invokes the > completion handler). As far as the HCD is concerned, the completion The delay should be very small(generally several microseconds) since isochronous URBs are completed in high priority tasklet. I don't think the introduced tasklet delay is a problem for EHCI since per EHCI spec the maximum rate at which the host controller will issue interrupts is one microframe(125us), which means isochronous transfer completion can be reported to CPU with about 125us delay in hardware level. > will already be finished. > > Thus, for example, even if the pipeline contains only a single URB, > with the current code it will not become empty. But with the new code > it will. If the load on the system is too high, the pipeline could > empty out even if it normally contains two or more URBs. Single URB may not work well too when running complete() in hard irq context. In UVC driver, looks it may submit at most 5 URBs which can include max 32 packets, so it will take about 5*32*125us(20ms) to make isoc pipeline empty suppose the interval is 1uF. But I don't know how USB audio driver uses URBs, and could it submit only one isoc URB to playback/record audio data? > > This means that the HCD will have trouble telling the difference > between an underrun and a normal restart of a stopped I/O stream. In > both cases it will see an URB being submitted to an empty queue. IMO, we should try to avoid the situation, and in UVC cases looks it is impossible to see an URB being submitted to an empty queue except for at the moment of starting streaming or interrupt disabled for extremely long. > Here's where the URB_ISO_ASAP flag will be useful; if that flag is set > then the URB is restarting a stopped stream, but if it isn't set then > the pipeline experienced an underrun. > > Naturally, under normal circumstances this won't matter, because > underruns shouldn't occur. But I know from experience that people try > to push the latency as far down as they can, which increases the > likelihood of underruns. > > There are several possible things the HCD could do when an underrun > occurs: > > 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. > > 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. > > Something in between... > > What would be best for your purposes? Or do you have any different > suggestions? > > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
