At Thu, 14 Aug 2003 19:01:50 +0000 (UTC), "Allen Briggs" wrote:
> The descriptors we may want something between cachable and non-cachable
> (BUS_DMA_COHERENT).

Note that those are choices for a particular implementation.  There
are many implementations for which BUS_DMA_COHERENT should be
cacheable, as well.

As noted, I think one can safely turn on write combining for COHERENT
requests.

If there's a strong desire to express cacheable/uncacheable mapping
preference, I'd recommend adding *hints* BUS_DMA_COH_UNC and
BUS_DMA_COH_C which say "attempt to make this mapping
cacheable/uncacheable for performance reasons" in addition to being
coherent (or non-coherent).


> Why something in between?  In the XScale case, the
> part has a fairly small cache that we want to use efficiently.  We can
> configure a page in memory to use a write buffer to combine writes into
> memory rows without allocating a cacheline for it.  This is similar to
> a cache, though, in that the write buffer has to be explicitly drained
> to ensure synchronization at specific times.

Right, and the COHERENT API requires use of syncs, so why shouldn't
you enable write buffering for COHERENT, and just make the syncs sync
the write buffer?


> We'd like to be able to use this write combining for device descriptors
> so we can bypass the cache and still get decent write performance.
> Overall, the idea is that it would be used for write-mostly shared
> memory, I suppose.
> 
> Does that help?

On such a platform, when *should* "COHERENT" ever behave differently
than what you've expressed?



cgd