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

[Will Deacon <will.deacon@arm.com>]

On Sun, Jul 05, 2015 at 08:56:24PM +0100, Benjamin Herrenschmidt wrote:
> On Sun, 2015-07-05 at 11:55 -0700, Andy Lutomirski wrote:
> > 
> > At some point, it would also be nice if the various macros has
> > well-defined semantics.  For example, x86 has:
> > 
> > #define pgprot_noncached(prot)                                          \
> >         ((boot_cpu_data.x86 > 3)                                        \
> >          ? (__pgprot(pgprot_val(prot) |                                 \
> >                      cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS)))     \
> >          : (prot))
> > 
> > Putting aside the pointless boot_cpu_data check (surely the recent PAT
> > rework completely obsoletes it), what is
> > pgprot_noncached(pgprot_writecombine(x)) supposed to do?  Currently it
> > results in garbage.  Should it have well-defined behavior instead?
> 
> Can it ? On powerpc it will just mean pgprot_noncached for example,
> those macros manipulate the same bits and it's not a bitmask, it's
> either unached or uncached with write combining.
> 
> > I suspect the other arches all have their own unique glitches here.
> 
> Correct. I'm still trying to get feedback on ARM for example.

We've ended up doing whatever drivers start to rely on from running on
x86, which gives rise to some sort of de-facto semantics, but it's not
necessarily efficient or portable.

On arm64, ioremap == ioremap_nocache, which gives strong ordering
guarantees but forbids things like unaligned access. ioremap_wc gives a
more relaxed mapping, which is non-cached but allows re-ordering and
unaligned access.

ioremap_wt is new and strange, but rmk and I were going down the same
route as ioremap_wc for that, because people expect to be able to do
blind memcpy with those pointers.

As for ordering of writeX/readX wrt DMA, our IO accessors are so insanely
heavyweight that I don't think the ioremap flavour matters atm.

Will