Subject: Re: BUS_DMA_CONTROLDATA flag for bus_dma(9)
To: Allen Briggs <briggs@wasabisystems.com>
From: None <cgd@broadcom.com>
List: tech-kern
Date: 08/14/2003 15:28:21
At Thu, 14 Aug 2003 18:01:40 -0400, Allen Briggs wrote:
> After some offline discussion with Nathan, I think I'm agreeing
> with you. I would still want to have something that does mean
> totally "raw" (uncached, coherent, not bufferred) as well--for
> debugging uses and for other situations where you may just really
> want totally uncached access.
Like? 8-)
Note, this isn't _device_ access. This is access to system memory
which also has additional constraints w.r.t. DMA-ability.
"uncached" and "coherent" are *not* synonymous, but you keep using
them as if they are.
Uncached accesses to DRAM may not be reasonably possible on some ports
(e.g. I don't recall if one can actually *do* uncached / unbuffered
accesses to DRAM on all Alpha models -- i'm fairly sure that you
can't). They are very unwise on others.
> For this to work, though, we would (as you note) have to define
> COHERENT as a required part of the interface, and I'd add a
> BUS_DMA_NOCACHE (or BUS_DMA_RAW or whatever makes sense).
Re: Making COHERENT required: yes. I think this has to be done; I
think the existing specification is defective.
I'd strongly disagree about adding something which *forces* uncached
access. If you want to *encourage* cached, uncached accesses, or
buffering (for performance reasons), see my previous mail. Add hints
that recommend it. But other than performance the semantics (coherent
or non-coherent) should remain the same.
In other words, e.g. on xscale, it sounds like if you ask for
"coherent, cacheable-if-possible" you'll never get it. similarly, on
SiByte parts, no matter what you ask for, you'll get cacheable.
> Does that make more sense?
Well, half of it. 8-)
chris