> 
> Okay.
> 
> So, as I understand this, then, STREAMING is the opposite of "coherent".
> I.e. in Solaris, "coherent" is the default, unless STREAMING is specified,

Only in the context of ddi_dma_mem_alloc.

> i.e. STREAMING enables the use of the I/O cache, etc. and causes additional
> constraints to be placed on the memory.  (Note: I put "coherent" in quotes
> because in this case it means memory->device, not cpu->memory -- we currently
> assume memory->device coherency in our API).

Exactly.


> So, what I'd like to do here, then, is propose that we clarify that COHERENT
> means "coherency from the CPU to memory",

Yes. That'd be great!

> and that we add a new flag,
> BUS_DMA_STREAMING, to enable the use of the I/O cache, etc., (i.e. "undo
> assumed memory->device coherency") as it seems to do in Solaris.
> 
> So, we would add the BUS_DMA_STREAMING flag to the following operations:
> 
> 	- bus_dmamem_alloc: causes the alignment and sizes to be
> 	  rounded up, as necessary for the I/O cache.
> 
> 	- bus_dmamap_load*: causes the I/O cache to be enabled for
> 	  that DMA mapping if the alignment and sizes are okay for
> 	  that.
> 
> 	- We keep the current assumption that, in the absense of
> 	  BUS_DMA_STREAMING, memory->device is "coherent".
> 
> 	- bus_dmamap_sync() is *still* required to ensure coherency
> 	  (or, at least, up-to-date'ness) in the cpu->memory sense.
> 
> This would mean that e.g. chip control blocks would *not* be allocated
> with BUS_DMA_STREAMING, and thus would be coherent from the memory->device
> angle, but DMA maps for e.g. transfers to the SCSI bus would be loaded
> with BUS_DMA_STREAMING, to get the benefit of the I/O cache.
> 
> By doing it this way, then we can ensure safe-but-maybe-not-as-fast
> operation when the BUS_DMA_STREAMING flag is omitted.
> 
> How does this sound?

This sounds like a very positive step. I'd like to hear what Eduardo thinks.

-matt