On Mon, Feb 26, 2001 at 10:00:22AM -0800, Matthew Jacob wrote:
> 
> [ moved to tech-kern ]
> 
> It also turns out that there's no way in the current sparc64 implementation to
> do BUS_DMA_COHERENT without this- I was wrong when I thought I had things
> working (I'd missed a BUS_DMA_COHERENT in a load call). The current SBus
> Qlogic card driver is now actually broken.
> 
> The summary of the issues now is now:
> 
> a) bus_dmamem_alloc implies that all memory allocated with this mechanism must
> be mapped BUS_DMA_COHERENT. To make sparc64 work requires a 4 line patch to
> sys/sparc64/dev/iommu.c.
> 
> b) bus_dmamem_alloc (and/or bus_dmamap_load*) should be allowed to take a
> BUS_DMA_COHERENT flag such that the memory will be mapped for I/O device
> access (on those particular platforms) in fashion that works.
> 
> 
> Note that this is completely orthogonal to the requirement of bus_dmamap_sync-
> the semantics of bus_dmamap_sync (flushing post mapping but prior to data
> movement) may not be possible on some platforms. This is the opposite case to
> what has been mentioned before (that bus_dmamap_sync is required because there
> may be platforms you *cannot* map BUS_DMA_COHERENT).
> 
> Note also that this is and should be orthogonal to bus_dmamem_map. You may
> need to map memory that is BUS_DMA_COHERENT for two separate devices- but not
> including a CPU with virtual address mapping to the memory involved.

Ok, in theory this could happen. But can't you work with BUS_DMA_COHERENT
passed to bus_dmamem_map() for now ? You should map() the map before loading
it, isn't it ?

--
Manuel Bouyer <bouyer@antioche.eu.org>
--