From owner-cvs-src Mon Feb 17 8:32:55 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D4837B401; Mon, 17 Feb 2003 08:32:53 -0800 (PST) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F78B43F85; Mon, 17 Feb 2003 08:32:50 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.6/8.12.6) with ESMTP id h1HGWhBs043973; Mon, 17 Feb 2003 16:32:43 GMT (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) by bluebottle.qubesoft.com (8.12.6/8.12.6) with ESMTP id h1HGWfLo080944; Mon, 17 Feb 2003 16:32:41 GMT (envelope-from dfr@nlsystems.com) Subject: Re: cvs commit: src/sys/modules Makefile From: Doug Rabson To: Marcel Moolenaar Cc: Eric Anholt , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org In-Reply-To: <20030214061708.GA2109@athlon.pn.xcllnt.net> References: <20030213223058.769DA2A8C1@canning.wemm.org> <1045185451.11981.17.camel@leguin> <20030214023218.GA1573@athlon.pn.xcllnt.net> <1045194133.11981.87.camel@leguin> <20030214043028.GA1797@athlon.pn.xcllnt.net> <1045200753.84507.54.camel@leguin> <20030214061708.GA2109@athlon.pn.xcllnt.net> Content-Type: text/plain Organization: Message-Id: <1045499561.1554.7.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 17 Feb 2003 16:32:41 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-8.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2003-02-14 at 06:17, Marcel Moolenaar wrote: > On Thu, Feb 13, 2003 at 09:32:33PM -0800, Eric Anholt wrote: > > > > > > In that case, we'd better make sure there's cache coherency. Do we > > > actually have the code structured in a way that allows having the > > > flushing chipset dependent (not to mention dependent on the address)? > > > > No, currently all the cache flushes (four in agp.c, three in i810 and > > amd code) are unconditional agp_flush_cache calls after modifying the > > gatt entries. They aren't tied to a specific memory range, but could be > > pretty easily, if not the most efficiently, by pushing some of them into > > the (un)bind_pages. There's probably a better way. > > I wonder: do we actually need to flush at all? GART updates are PCI/AGP > writes and should be coherent, right? > Isn't updating the SGM (system graphics memory) itself that needs > cache flushes to make sure the AGP device gets the right data? When I did the original intel agp driver, it was clear from testing that the chipset didn't see changes to the GATT unless the cache was explicitly flushed. I don't know about other chipsets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message