mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>, Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] MIPS: Ordering enforcement fixes for MMIO accessors
Date: Mon, 8 Oct 2018 01:36:55 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.21.1810070229190.7757@eddie.linux-mips.org> (raw)

Hi,

 This patch series is a follow-up to my earlier consideration about MMIO 
access ordering recorded here: <https://lkml.org/lkml/2014/4/28/201>.

 As I have learnt in a recent Alpha/Linux discussion starting here: 
<https://marc.info/?i=alpine.LRH.2.02.1808161556450.13597%20()%20file01%20!%20intranet%20!%20prod%20!%20int%20!%20rdu2%20!%20redhat%20!%20com> 
related to MMIO accessor ordering barriers ports are actually required to 
follow the x86 strongly ordered semantics.  As the ordering is not 
specified in the MIPS architecture except for the SYNC instruction we do 
have to put explicit barriers in MMIO accessors as otherwise ordering may 
not be guaranteed.

 Fortunately on strongly ordered systems SYNC is expected to be as cheap 
as a NOP, and on weakly ordered ones it is needed anyway.  As from 
revision 2.60 of the MIPS architecture specification however we have a 
number of SYNC operations defined, and SYNC 0 has been upgraded from an 
ordering to a completion barrier.  We currently don't make use of these 
extra operations and always use SYNC 0 instead, which this means that we 
may be doing too much synchronisation with the barriers we have already 
defined.

 This patch series does not make an attempt to optimise for SYNC operation 
use, which belongs to a separate improvement.  Instead it focuses on 
fixing MMIO accesses so that drivers can rely on our own API definition.

 Following the original consideration specific MMIO barrier operations are 
added.  As they have turned out to be required to be implied by MMIO 
accessors there is no immediate need to make them form a generic 
cross-architecture internal Linux API.  Therefore I defined them for the 
MIPS architecture only, using the names originally coined by mostly taking 
them from the PowerPC port.

 Then I have used them to fix `mmiowb', and then `readX' and `writeX' 
accessors.  Finally I have updated the `_relaxed' accessors to avoid 
unnecessary synchronisation WRT DMA.

 See individual commit descriptions for further details.

 As a follow-up clean-up places across the architecture tree could be 
reviewed for barrier use that is actually related to MMIO rather than 
memory and updated to use the new names of the MMIO barrier operations.  I 
plan to do this for the DECstation and possibly the SiByte platform, 
however I am leaving it for someone else to do it elsewhere.

 Similarly I think the DMA barrier in `readX' and `inX' should be using 
`dma_rmb' rather than `rmb', but I'm leaving it for someone else to 
handle.

 These changes have been verified at run time with an R3000 (MIPS I) 
DECstation machine (32-bit kernel, little endianness), an R4400 (MIPS III) 
DECstation machine (64-bit kernel, little endianness) and an SB-1 (MIPS64) 
SWARM machine (64-bit kernel, big endianness), by booting them into the 
multiuser mode and running them for a couple of hours.

 Please apply.

  Maciej

             reply	other threads:[~2018-10-08  0:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08  0:36 Maciej W. Rozycki [this message]
2018-10-08  0:37 ` [PATCH 1/4] MIPS: Define MMIO ordering barriers Maciej W. Rozycki
2018-10-08  0:37 ` [PATCH 2/4] MIPS: Correct `mmiowb' barrier for `wbflush' platforms Maciej W. Rozycki
2018-10-08  0:37 ` [PATCH 3/4] MIPS: Enforce strong ordering for MMIO accessors Maciej W. Rozycki
2018-10-08  0:37 ` [PATCH 4/4] MIPS: Provide actually relaxed " Maciej W. Rozycki
2018-10-11 16:40 ` [PATCH 0/4] MIPS: Ordering enforcement fixes for " Paul Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.1810070229190.7757@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®