Subject: Re: On the subject of bus_dma(9)
To: Jason R Thorpe <email@example.com>
From: Matthew Jacob <firstname.lastname@example.org>
Date: 03/07/2001 12:48:38
> 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).
> 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
> - 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.