> > 
> > 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 ?

I still would have to change the sparc64 implementation to grok this I
believe. Note that BUS_DMA_COHERENT for bus_dmamem_map means make the
CPU's view coherent (i.e., set PG_NVC (no vcache)) of memory. There's no tying
this to setting iommu TTE bits.

And lacking any architectural *requirement* for requiring such ordering, in
fact, I'd rather have a big fat rule breakage with a comment than things just
working because the order of function calls makes things work.

-matt