From owner-cvs-all Thu Feb 13 23: 2:20 2003 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 D5DBE37B401; Thu, 13 Feb 2003 23:02:17 -0800 (PST) Received: from haystack.lclark.edu (lclark.edu [149.175.1.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 6041143F85; Thu, 13 Feb 2003 23:02:12 -0800 (PST) (envelope-from eta@lclark.edu) Received: from [149.175.30.191] ([149.175.30.191]) by haystack.lclark.edu (SAVSMTP 3.0.0.44) with SMTP id M2003021323020112901 ; Thu, 13 Feb 2003 23:02:01 -0800 Subject: Re: cvs commit: src/sys/modules Makefile From: Eric Anholt To: Marcel Moolenaar Cc: 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: <1045206256.84507.99.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Feb 2003 23:04:17 -0800 Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 2003-02-13 at 22: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? > > Also, on ia64 bus I/O is done with a virtual address that has the > non-cacheable property. Flushing would not be required irrespective. Ack! For the i810 case, that's true. For some reason I had been thinking that they were all acting like agp_amd.c, which just writes to the vaddr of the malloced/busdma'ed gatt. Maybe chipset-specific flushing would be a good idea. Not sure quite what you mean by SGM. Are you referring to what the i810 does? If so, that ought to be referenced through the (coherent) aperture, I would think. Also a little confused by the ia64 thing. How is that going to behave differently than an i386 then? Not reorder writes to the bus? > Anyway: the nit was about having conditional compilation based on the > architecture, not whether the code was actually required. When in doubt, > commit the code :-) Committed the update, anyway. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message