Date: Sat, 2 Aug 1997 00:42:56 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: gallatin@cs.duke.edu, freebsd-current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: code talks: announcing EIDE bus master patches Message-ID: <19970802004256.56037@mi.uni-koeln.de> In-Reply-To: <199707310317.MAA25355@genesis.atrad.adelaide.edu.au>; from Michael Smith on Thu, Jul 31, 1997 at 12:47:07PM %2B0930 References: <19970730220038.02422@mi.uni-koeln.de> <199707310317.MAA25355@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 31, Michael Smith <msmith@atrad.adelaide.edu.au> wrote: > If I read the AMCC PCI matchmaker databook correctly, PIO to a > memory-mapped buffer is likely to be severely affected by whether the > PCI bridge in question supports cache line read/write operations. CPU writes to a PCI device are (at least in the case of x86 CPUs) always issued independently, and only the host to PCI bridge chip will see requests to sequentially increasing memory addresses and in that case just keep on sending data with no intervening PCI address cycles. This feature can be enabled in all host to PCI bridges since at least the Intel Saturn (introduced some 4 years ago), though it did not yet work reliably in all isituations, then. Today it is generally enabled and working. > Is this a potential issue here? No. No chipset (that I know of) performs read-ahead on CPU reads, even to PCI bus address ranges that have been marked prefetchable. But you can use a bus-master PCI chip (e.g. an NCR PCI SCSI chips) as a DMA controller, and will then be able issue burst transfers in any direction. A 53c810A does make for a cheap and fast DMA controller, too bad that it occupies another one of those scarce PCI slots :) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970802004256.56037>