Re: [RFC] MMIO accessors & barriers documentation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> I'd rather memcpy_to/from_io only made guarantees about the start/end of
> the transfer and not order of read/writes or size of read/writes. The
> reason being that a more restrictive sequence can be efficiently
> expressed using read/writefoo but the reverse is not true.

Ok, so we would define ordering on the first and last accesses (being
the first and last in ascending addresses order) and leave it free to
the implementation to do what it wants in between. Is that ok ?

> > > "Except where the underlying device is marked as cachable or
> > > prefetchable"
> > 
> > You aren't supposed to use MMIO accessors on cacheable memory, are you ?
> 
> Why not. Providing it is in MMIO space, consider ROMs for example or
> write path consider frame buffers.

If we consider cacheable accesses, we need to also provide cache
flushing primitives as MMIO devices are generally not coherent. Take for
example the case of the frame buffer: you may want to upload a texture,
and later use it with the engine. You need a way in between to make sure
all the cached dirty lines have been pushed to the device before you
start the engine. Since we provide no generically useable functions for
doing such cache coherency on MMIO space, I'd rather keep usage of MMIO
accessors on cacheable storage non-defined. That is add a simple note at
the top of the file that the rules defined here only apply to
non-cacheable mappings. Is that ok ?

> > with cacheable mappings of anything behind HT... I'd keep use of
> > cacheable mapping as an arch specific special case for now, and that
> > definitely doesn't allow for MMIO accessors ...
> 
> I'm describing existing semantics 8)

Well, there is no clear existing semantics, at least not global to all
archs for cacheable access to MMIO so yeah, let's say that ordering on
cacheable storage is left undefined :)

Ben.