From owner-cvs-all@FreeBSD.ORG Wed May 24 15:35:24 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 93FA616A8E7; Wed, 24 May 2006 15:35:24 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 8141443D6E; Wed, 24 May 2006 15:35:23 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 24 May 2006 16:35:22 +0100 (IST) To: Mike Silbersack In-Reply-To: Your message of "Wed, 24 May 2006 01:40:29 CDT." <20060524013323.O56879@odysseus.silby.com> Date: Wed, 24 May 2006 16:35:21 +0100 From: Ian Dowse Message-ID: <200605241635.aa64582@nowhere.iedowse.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 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 15:35:29 -0000 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 >>