Date: 13 Feb 2003 21:32:33 -0800 From: Eric Anholt <eta@lclark.edu> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/modules Makefile Message-ID: <1045200753.84507.54.camel@leguin> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1045200753.84507.54.camel>