[Ksummit-discuss] [TECH TOPIC] Semantics of MMIO mapping attributes accross archs

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

Allright, it's that time of year ... So here's my attempt at getting
myself invited :-)

We've been talking about some of that on-list recently, and it might
well be that this will trigger a resolution before we even reach KS, but
I though it might be worthwhile to gather enough people from various
arch together to hash things out:

We have a pile of mapping attributes (more showing up recently),
typically used for MMIO mappings (but not necessarily exclusively).
ioremap_cache and ioremap_nocache are the old/common ones, but we have
_wc (write combine), _wt (write through) and possibly more around the
corner.

What are their precise semantics accross all architecture ? This is not
clear (not documented). For example, we define writel(), readl() and
friends as being fully ordered vs each other but also vs DMA etc... but
on what mapping types do they have this property ?

Will _wc() provide the write-combine ability for writel() on all archs ?
Or does it require writel_relaxed() on some ? Will _wc() bring other
side effects such as loss of read vs. write ordering ? (on some archs at
least...). Etc....

There is a growing matrix of MMIO accessors and mapping types whose
semantics are poorly (if at all) defined. We cannot define them all
exactly for all architectures as there are too many differences that
will impact them. But we should be able to guarantee at least *some*,
ie, whether a given type of ordering is guaranteed or not by a given
accessor on a given mapping type, whether write combine (if supported at
all) will happen with a given accessor or not etc...

As for who should participate, well, at least one rep from each major
arch who is familiar with the intricacies of the architecture memory
model I would say, possibly others who dabbled in that stuff recently
such as Luis R. Rodriguez <mcgrof@suse.com> who was proposing patch
series lately to consolidate the use of _wc.

Cheers,
Ben.