Date: Wed, 24 May 2006 16:35:21 +0100 From: Ian Dowse <iedowse@iedowse.com> To: Mike Silbersack <silby@silby.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/usb ehci.c ehcivar.h Message-ID: <200605241635.aa64582@nowhere.iedowse.com> In-Reply-To: Your message of "Wed, 24 May 2006 01:40:29 CDT." <20060524013323.O56879@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060524013323.O56879@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 >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605241635.aa64582>