Date: Fri, 27 Jun 2003 15:04:56 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma Message-ID: <3EFCB178.9030207@btc.adaptec.com> In-Reply-To: <16124.45051.919899.414795@grasshopper.cs.duke.edu> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com> <16124.45051.919899.414795@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > Scott Long writes: > > > > I'm not familiar with Solaris DDI. bus_dmamem_alloc() is guaranteed to > > give you contiguous memory that doesn't require bouncing (or ENOMEM if > > that's not possible). I can't imagine what DDI_DMA_STREAMING is. > > Most sparc's have 2 different sorts of DMA modes. One is cache > coherent (aka DDI_DMA_CONSISTENT) -- this is what we all know and love > from PC, alphas, macs, etc. > > The other mode (DDI_DMA_STREAMING) allows non cache coherent DMA. > This requires you to call ddi_dma_sync() between your last touch of > the data and you starting a DMA read from a device. And vice-versa > for a DMA write. > > The reason people use DDI_DMA_STREAMING is because coherent DMA > bandwith tends to be abysmal on most sparcs. Using DDI_DMA_STREAMING > upgrades the bandwith from abysmal to just bad. Here are some > examples: > > For u80, UltraSPARC II, using chip "Psycho", > 98 MBytes/s consistent vs. 150 MBytes/s streaming. > For sunfire, UltraSPARC III, using chip "Schizo", > 70 MBytes/s consistent vs. 173 MBytes/s streaming. > > (compare to 450MB/sec for most intel 64-bit/66MHz PCI slots).. > > Drew > The approach taken with busdma is that you don't assume coherency. The idea is to call bus_dmamap_sync() with the appropriate opcode to signal pre|post read|write, and have that take care of the platform-specific magic. On i386 when bouncing does not occur, these are NOOP, otherwise the actual bouncing bcopy() takes place. On sparc64 it looks like it does the appropriate IOMMU and memory barrier magic. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EFCB178.9030207>