"packed control data" is defined to be "multiple elements in a piece
of memory created using a single bus_dmamem_alloc call, which may be
independently updated by the CPU or DMA-capable peripherals, and which
might not be aligned to any cache-line size" right?

or, perhaps, "... mapped using a single bus_dmamem_map call ..."?



What's the purpose of COHERENT *other* than to allow use of that type
of data?


Given those points, I see three problems in the current interface and
implementations:

(1) COHERENT is really really slow, because on some platforms it uses
    uncached accesses.

    This can be mitigated in some cases (e.g. by adding write
    buffering), but on systems w/o coherency support in hardware, I
    don't know that there's any any complete solution.

    I don't see anything in the current definition of COHERENT that
    precludes write buffering, do you?

(2) non-COHERENT is faster, but is simply incorrect for packed control
    data.

    The solution to this is "don't *DO* that!"  And probably update
    the documentation to reflect that you cannot safely do that.

(3) Since COHERENT is a *hint*, it too may behave wrongly for packed
    control data.

    The solution to this is make COHERENT a requirement, i.e., it
    cannot be treated optionally by back-ends.

    When doing this, bus_dmamem_map() would have to reject
    improperly-aligned mappings (i.e., not-cache-line-aligned).


So, I agree there's a problem here, but IMO it's fundamentally a
problem which should be solved by fixing the definition of COHERENT,
since this is *exactly* the usage that COHERENT is intended to address.

Am I missing some intended use of COHERENT?  I looked back at the
bus_dma paper, and it didn't detail the expected behaviour of
COHERENT.  (It also mixed multiple mappings in the same allocation
AFAICT.)


chris