Date: Wed, 24 May 2006 01:40:29 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Ian Dowse <iedowse@FreeBSD.org> 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: <20060524013323.O56879@odysseus.silby.com> In-Reply-To: <200605240304.k4O34BKO038584@repoman.freebsd.org> References: <200605240304.k4O34BKO038584@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060524013323.O56879>