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