API change for bus_dma

[Scott Long]

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