cvs commit: src/sys/dev/usb ehci.c ehcivar.h

[Ian Dowse]

In message <20060524013323.O56879 at odysseus.silby.com>, Mike Silbersack writes:
>
>I'm worried that this may result in a small pessimization in cases where a 
>transfer that requires a large number of qTLs is followed by a transfer 
>with a small number of qTLs, but a large number of qTDs.  Could you 
>comment on whether this is the case?  If so, we may have to consider a 
>hysteresis to balance out the situation when the low watermark is 
>insufficient to prevent an overrun of the memory barrier.

Indeed ;-) Sorry for the undecipherable message!

Ian

>Thanks,
>
>Mike "Silby" Silbersack
>
>On Wed, 24 May 2006, Ian Dowse wrote:
>
>> iedowse     2006-05-24 03:04:11 UTC
>>
>>  FreeBSD src repository
>>
>>  Modified files:
>>    sys/dev/usb          ehci.c ehcivar.h
>>  Log:
>>  Attempt to follow the procedure described in section 4.10 of the
>>  EHCI spec for linking in new qTDs into an asynchronous QH. This
>>  requires that there is a qTD marked as not active and not halted
>>  at the start of the QH's list, and the hardware will know to re-fetch
>>  the qTD on each pass rather than just looking at the overlay qTD:
>>
>>    "The host controller must be able to advance the queue from the
>>    Fetch QH state in order to avoid all hardware/software race
>>    conditions. This simple mechanism allows software to simply link
>>    qTDs to the queue head and activate them, then the host controller
>>    will always find them if/when they are reachable."
>>
>>  This is achieved by keeping an "inactivesqtd" entry on the QH list,
>>  and re-using it each time as the start of the next transfer, and
>>  allocating a new qTD to become the next inactivesqtd. Then a new
>>  transfer can be activated by just setting its "active" flag, which
>>  avoids all the previous messing with overlay qTD state in
>>  ehci_set_qh_qtd().
>>
>>  Revision  Changes    Path
>>  1.45      +223 -94   src/sys/dev/usb/ehci.c
>>  1.14      +1 -0      src/sys/dev/usb/ehcivar.h
>>