At Fri, 15 Aug 2003 01:25:12 +0000 (UTC), "Allen Briggs" wrote:
> I suppose the clearest idea I had (other than debugging coherency
> questions), was in working with some device that isn't coherent, but
> is still making direct accesses to shared memory.  Still murky.  Sorry.

well, what do you mean "some device that isn't coherent?"

"doesn't write memory it doesn't own, reads last-written values" works
usually, and in this case works if you assume a model in which the CPU
and device logically transfer of ownership of particular bytes.

one thing that's important to note is that the CPU can't write more
than it intends to (i.e., writing a word can't accidentally rewrite a
whole line with an old value, as might be the case if caching on some
HW), and neither can the device (i.e., if it's writing a word, it does
a cycle that writes a word, rather than a cycle that writes ... more,
possibly with out-of-date data.



> I guess what I was really thinking was that if I mapped a region as
> BUS_DMA_COHERENT (and if that flag were known to be implemented on
> a given port), it wouldn't require bus_dmamap_sync() in order to
> enforce the coherency.  The current interface says that I shouldn't
> assume that, but is that just because it's defined to be a hint?

I don't know.  Jason might have useful input, since he created it.
8-)

However, I suspect that no matter what you do, you'll need
*something*.  e.g. you want to do a 'sync' on MIPS, or mb/wmb on
alpha, i believe.


> > Re: Making COHERENT required: yes.  I think this has to be done; I
> > think the existing specification is defective.
> 
> I'm thinking that I agree with you, but I'm not quite clear on how
> BUS_DMA_COHERENT should be defined in this case.

I think the above is fairly good, but i'd probably polish it a bunch.  8-)

(it precludes caching unless there's truly hardware memory coherency,
it allows write buffering and write merging assuming they're not
implemented wrong...)



chris