2013/12/2 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > 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). how about situation like below: HW Frame index is located at microframe 90. And there was an isochronous URB that was scheduled to transmit packets during microframes 100, 180, 260, and 340. Interrupt happen for Bulk when HW increase Frame index to 98. After driver scan asynchronous schedule, driver finds ehci->isoc_count != 0 and start scan_isoc. Isn't it possible that Driver may drop those previous scheduled isochronous packets? Appreciate your kind help, -- 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
