From owner-cvs-all@FreeBSD.ORG Wed May 24 06:40:27 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C873C16A421 for ; Wed, 24 May 2006 06:40:27 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id CD00743D60 for ; Wed, 24 May 2006 06:40:25 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 12638 invoked from network); 24 May 2006 06:40:24 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 24 May 2006 06:40:24 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 24 May 2006 01:40:29 -0500 (CDT) From: Mike Silbersack To: Ian Dowse In-Reply-To: <200605240304.k4O34BKO038584@repoman.freebsd.org> Message-ID: <20060524013323.O56879@odysseus.silby.com> References: <200605240304.k4O34BKO038584@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 06:40:27 -0000 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 >