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

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

On Mon, 2015-07-06 at 10:33 +0100, Will Deacon wrote:
> 
> 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.

Correct, which is why I would like to start documenting what is
mandated/guaranteed and separately what is the expected behaviour for
non-guaranteed bits on each arch.

> On arm64, ioremap == ioremap_nocache, which gives strong ordering
> guarantees but forbids things like unaligned access.

Ok, same for us. Except ordering guarantees aren't even that strong ...

>  ioremap_wc gives a
> more relaxed mapping, which is non-cached but allows re-ordering and
> unaligned access.

Ok, our other mapping (G=0) weakens ordering even more but won't allow
unaligned either. We don't have a non-cachable mapping that allows
unaligned accesses at all in fact :-( I've been fighting with our HW
guys on that one, but they keep thinking it's not useful.
 
> 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.

Ok, powerpc architecturally supports WT but no recent implementation
does. I'm not sure what is the practical purpose.

> 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.

This is the same for us, but that also means in our case that writeX
will not combine on ioremap_wc(), only relaxed_writeX() might after we
change it to be something else than writeX(). What is the situation for
you ?

Ben.