Subject: Re: BUS_DMA_CONTROLDATA flag for bus_dma(9)
To: None <briggs@wasabisystems.com>
From: None <cgd@broadcom.com>
List: tech-kern
Date: 08/14/2003 14:45:47
"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