From owner-cvs-all Thu Feb 13 21:30:46 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 A0C6337B401; Thu, 13 Feb 2003 21:30:43 -0800 (PST) Received: from haystack.lclark.edu (haystack.lclark.edu [149.175.1.2]) by mx1.FreeBSD.org (Postfix) with SMTP id 0102843F85; Thu, 13 Feb 2003 21:30:39 -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 M2003021321301820380 ; Thu, 13 Feb 2003 21:30:18 -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: <20030214043028.GA1797@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> Content-Type: text/plain Organization: Message-Id: <1045200753.84507.54.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Feb 2003 21:32:33 -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 20:30, Marcel Moolenaar wrote: > On Thu, Feb 13, 2003 at 07:42:14PM -0800, Eric Anholt wrote: > > On Thu, 2003-02-13 at 18:32, Marcel Moolenaar wrote: > > > On Thu, Feb 13, 2003 at 06:06:15PM -0800, Eric Anholt wrote: > > > > > > > > Here's a patch to remove the arch-specific drivers from conf/files and > > > > only enable them for the appropriate architectures. As far as > > > > flush_cache on alpha, everyone else (NetBSD, linux) just does a memory > > > > barrier there, and linux has a note that it's probably wrong but they're > > > > not sure. > > > > > > > > http://people.freebsd.org/~anholt/files/agp-alphadiff > > > > > > > > Does this look appropriate? > > > > > > I think so. There's just one nit: agp_flush_cache(). Can we not > > > rename it to cpu_flush_cache() and have some MD header define it > > > appropriately (or if the implementation is non-trivial have it > > > defined in some MD source file)? > > > > Well, the problem is that it only actually flushes the cache on one > > architecture (i386) so far. I don't know if the alpha_mb() helps at > > all, I was just following the herd on this one. I've been digging > > through the AMD docs trying to figure out if it snoops the cpu cache > > when getting tlb entries (if so we don't need the cache flush), but > > can't find anything. > > 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. Of the two I've looked at so far (AMD 760, i815 gmch), neither do snoops when fetching tlb entries. I'm guessing that others will be the same. So I don't think there'll probably be a need for chipset-specific cache flushing. -- 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