Re: EHCI periodic processing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/8/25 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
>> On Mon, 23 Aug 2010, David Brownell wrote:
>>
>> > t it seems
>> > wasteful (and
>> > possibly flat-out wrong in the presence of frame-list
>> > wraparound)
>>
>> ISTR comments about the dubiousness of wraparound behaviors...
>
> Here's a scenario to consider.  Suppose there are no isochronous
> transfers going on, but there is a long-period interrupt transfer and
> the completion handler always resubmits.
>
> Suppose two successive URBs complete exactly one second apart (since
> the period is large this is not unlikely), and let N be the frame list
> entry in which the two transactions occurred.  Finally, suppose that
> IRQ latency causes the interrupt handler for the second completion to
> be delayed by 1 ms.
>
> Then during the first IRQ the CPU will read N from the frame counter
> and during the second it will read N+1.  As a result, while processing
> the second IRQ, the big loop in scan_periodic() will look only for
> events occurring during frame N+1, so it won't see the URB that
> completed during frame N.

Yes, it is really a corner case.

>
> It seems we should insure that scan_periodic() checks at least the
> last SCHEDULE_SLOP frames if the frame list has wrapped since the last
> scan.

Another way, we may enable 'Frame List Rollover' irq to fix the
case above if interrupt or iso transfers are to be scheduled. In
the irq handler for 'Frame List Rollover' , scan_periodic can be
called to scan periodic list and ehci->next_uframe will be updated.

>
> Even worse things can happen with isochronous transfers if too many of
> them are scheduled with the URB_NO_INTERRUPT flag.  We could end up in
> a situation where new transfers can't be added because the frame list
> is full, and the frame list doesn't empty out because we never get a
> completion IRQ.  We need to have at least one such IRQ before the frame
> list wraps.  I'm not sure what the best solution is, other than simply
> to ignore URB_NO_INTERRUPT for isochronous URBs.
>
> 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
>



-- 
Lei Ming
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux