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

[Mike Silbersack]

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.

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
>