On Sun, 1 Dec 2013, yoma sophian wrote: > >> Suppose itds are submitted then ehci_work is triggered by bulk > >> interrupt and ehci->isoc_count >0. > >> > >> The race condition may happen if hardware hasn't handled those itds, right? > > > > I don't know what race condition you are talking about. Please explain > > in more detail. > > 1. submit iso urbs ehci->periodic_count ++ > 2. interrupt for bulk happen > 3. scan async > 4. scan iso schedule, since ehci->periodic_count != 0 > 5. clear urb if host hasn't enough time to handle it This isn't a race condition, because the driver does not terminate isochronous URBs before they are scheduled to end. For example, suppose there was an isochronous URB that was scheduled to transmit packets during microframes 100, 180, 260, and 340. If an interrupt for a bulk URB happens during microframe 212, the driver will not terminate the isochronous URB, because it is not scheduled to end yet. But if an interrupt for a bulk URB happens during microframe 347, then the driver will terminate the isochronous URB, because that is after the scheduled end (which is microframe 340). > > If the periodic count has just dropped to 0, it's quite likely that the > > periodic count will increase again in the near future. Therefore the > > driver leaves the periodic schedule running for a little while. That's > > better than stopping the schedule and starting it again a few > > milliseconds later. > > why in the previous kernel version, take v3.1-rc1 for example, turn > off period schedule directly? I don't know why; I didn't write that code in the earlier kernels. > is there any bug then we change the turn > off policy? No, it was not a bug. The new code is an improvement, that's all. 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
