Re: [PATCH v2 00/18] Cross-architecture definitions of relaxed MMIO accessors

From: Benjamin Herrenschmidt
Date: Sun May 25 2014 - 19:28:47 EST


On Thu, 2014-05-22 at 17:47 +0100, Will Deacon wrote:
> Hi all,
>
> This is version 2 of the series I originally posted here:
>
> https://lkml.org/lkml/2014/4/17/269
>
> Changes since v1 include:
>
> - Added relevant acks from arch maintainers
> - Fixed potential compiler re-ordering issue for x86 definitions
>
> I'd *really* appreciate some feedback on the proposed semantics here, but
> acks are still good :)
>
> The original cover letter is duplicated below.

Question (sorry if I missed an existing explanation...), do we have an
equivalent bunch for iomap ?

Cheers,
Ben.

> Cheers,
>
> Will
>
> --->8
>
> This RFC series attempts to define a portable (i.e. cross-architecture)
> definition of the {readX,writeX}_relaxed MMIO accessor functions. These
> functions are already in widespread use amongst drivers (mainly those supporting
> devices embedded in ARM SoCs), but lack any well-defined semantics and,
> subsequently, any portable definitions to allow these drivers to be compiled for
> other architectures.
>
> The two main motivations for this series are:
>
> (1) To promote use of the _relaxed MMIO accessors on weakly-ordered
> architectures, where they can bring significant performance improvements
> over their non-relaxed counterparts.
>
> (2) To allow COMPILE_TEST to build drivers using the relaxed accessors across
> all architectures.
>
> The proposed semantics largely match exactly those provided by the ARM
> implementation (i.e. no weaker), with one exception (see below).
>
> Informally:
>
> - Relaxed accesses to the same device are ordered with respect to each other.
>
> - Relaxed accesses are *not* guaranteed to be ordered with respect to normal
> memory accesses (e.g. DMA buffers -- this is what gives us the performance
> boost over the non-relaxed versions).
>
> - Relaxed accesses are not guaranteed to be ordered with respect to
> LOCK/UNLOCK operations.
>
> In actual fact, the relaxed accessors *are* ordered with respect to LOCK/UNLOCK
> operations on ARM[64], but I have added this constraint for the benefit of
> PowerPC, which has expensive I/O barriers in the spin_unlock path for the
> non-relaxed accessors.
>
> A corollary to this is that mmiowb() probably needs rethinking. As it currently
> stands, an mmiowb() is required to order MMIO writes to a device from multiple
> CPUs, even if that device is protected by a lock. However, this isn't often used
> in practice, leading to PowerPC implementing both mmiowb() *and* synchronising
> I/O in spin_unlock.
>
> I would propose making the non-relaxed I/O accessors ordered with respect to
> LOCK/UNLOCK, leaving mmiowb() to be used with the relaxed accessors, if
> required, but would welcome thoughts/suggestions on this topic.
>
>
> Will Deacon (18):
> asm-generic: io: implement relaxed accessor macros as conditional
> wrappers
> microblaze: io: remove dummy relaxed accessor macros
> s390: io: remove dummy relaxed accessor macros for reads
> xtensa: io: remove dummy relaxed accessor macros for reads
> alpha: io: implement relaxed accessor macros for writes
> frv: io: implement dummy relaxed accessor macros for writes
> cris: io: implement dummy relaxed accessor macros for writes
> ia64: io: implement dummy relaxed accessor macros for writes
> m32r: io: implement dummy relaxed accessor macros for writes
> m68k: io: implement dummy relaxed accessor macros for writes
> mn10300: io: implement dummy relaxed accessor macros for writes
> parisc: io: implement dummy relaxed accessor macros for writes
> powerpc: io: implement dummy relaxed accessor macros for writes
> sparc: io: implement dummy relaxed accessor macros for writes
> tile: io: implement dummy relaxed accessor macros for writes
> x86: io: implement dummy relaxed accessor macros for writes
> documentation: memory-barriers: clarify relaxed io accessor semantics
> asm-generic: io: define relaxed accessor macros unconditionally
>
> Documentation/memory-barriers.txt | 13 +++++++++----
> arch/alpha/include/asm/io.h | 12 ++++++++----
> arch/cris/include/asm/io.h | 3 +++
> arch/frv/include/asm/io.h | 3 +++
> arch/ia64/include/asm/io.h | 4 ++++
> arch/m32r/include/asm/io.h | 3 +++
> arch/m68k/include/asm/io.h | 8 ++++++++
> arch/m68k/include/asm/io_no.h | 4 ----
> arch/microblaze/include/asm/io.h | 8 --------
> arch/mn10300/include/asm/io.h | 4 ++++
> arch/parisc/include/asm/io.h | 12 ++++++++----
> arch/powerpc/include/asm/io.h | 12 ++++++++----
> arch/s390/include/asm/io.h | 5 -----
> arch/sparc/include/asm/io.h | 9 +++++++++
> arch/sparc/include/asm/io_32.h | 3 ---
> arch/sparc/include/asm/io_64.h | 22 ++++++++++------------
> arch/tile/include/asm/io.h | 4 ++++
> arch/x86/include/asm/io.h | 10 +++++++---
> arch/xtensa/include/asm/io.h | 7 -------
> include/asm-generic/io.h | 10 ++++++++++
> 20 files changed, 98 insertions(+), 58 deletions(-)
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/