On Sat, 24 Feb 2001, Jason R Thorpe wrote:

> On Sun, Feb 25, 2001 at 01:30:01AM +0200, Matthew Jacob wrote:
> 
>  > Log Message:
>  > Now that the underlying code for bus_dmamap_sync appears to do the
>  > right thing, don't use the illegal and "just worked by chance" addition
>  > of BUS_DMA_COHERENT to bus_dmamap_load_raw. There still is a necessity
>  > to add to the architecture to allow one to hint that this should be
>  > a cache coherent mapping.
> 
> There is -- when you call bus_dmamem_map().  But, it's only a hint
> (because on some systems, you *can't* make things cache coherent).

Yes. I know.


> When you bus_dmamap_load() memory that's mapped with COHERENT, the
> machdep code could notice that it's loading coherently-mapped memory,
> which could store a flag in the machdep part of the dmamap, which could
> then be tested in bus_dmamap_sync().

I think the problem here is that there's no ordering requirement stated that
says that bus_dmamap_load[_raw] has to occur after bus_dmamem_map. I can see
that this would work okay if this was required.

There's also nothing that can be use to give a hint to bus_dmamem_alloc that
it should make an allocation such that a subsequent bus_dmamem_map with
BUS_DMA_COHERENT would succeed sensibly

That is, unless you count the page-size allocation rule for bus_dmamem_alloc
to be a sufficient guard. I don't- you assume that all you need to do is to
rip a cpu mapping away from a page to guarantee you can make a piece of memory
sync-able. This may not be a reasonable efficient mechanism. It'd be better to
be able to tell bus_dmamem_alloc what you want the memory for to begin with.

-matt