>:::
>                                                          ... The assumption
>  > that a post-mapping 'sync' operation exists is a flawed assumption.

  -- either everything needs to be coherent or sync needs to work, obviously
  one or the other must work. Both need to be in the interface.  It's really
  hard to find fault with *that* assumption. If you still think there is a
  problem here please specify it more precisely.

>:::
>  > 2. But real memory is allocated (in the order above) prior to the call to
>  > bus_dmamem_map.

Well, actually, it doesn't have to be allocated here, it just has to be
_specified_ there because that's the bus_dma(9) interface. And obviously,
it has to ultimately be coherent or sync-capable, so what's the problem?

>  > 
>  > 3. Therefore, bus_dmamem_alloc'd memory must be assumed to be for
>  > BUS_DMA_COHERENT purposes because there may be no way to 'change'
>  > the identity of the memory alloc'd in bus_dmamem_alloc (it might be
>  > from a pool that *can't* be made byte-coherent).
>
> bus_dmamem_alloc() for a particular bus_dma_tag_t *should never* allocate
> from memory which can not be made to DTRT for a particular bus.  All this
> does it point to a bug in the sparc64 bus_dmamem_alloc() routines.
>
> Case in point -- bus_dmamem_alloc() on the i386, when presented with
> the ISA bus_dma_tag_t, *never* allocates pages over 24M in the physical
> address space.
>
> ...and in the case of the Dreamcast, bus_dmamem_alloc() merely allocates
> physical pages, but the sync operations always ensure coherency (because
> they copy to the PCI SRAM buffer).

For that matter, if the platform is totally wacky it can just make a thunk
and postpone the allocation, or it can later free it and reallocate things
if it gets a more difficult and unusual coherent case. The sync calls are
still needed for the proper interface, even if they need not do anything
for a specific mapping.

I've seen more unusual things than sparc64 fit into the bus_dma(9) framework
as it stands right now, and I bet sparc64 could too if properly implemented.

Do I have to bet money on this? :-)

	--Ross