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

[Benjamin Herrenschmidt]

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/