linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Oliva <lxoliva@fsfla.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>, Tom Li <tomli@tomli.me>,
	James Hogan <jhogan@kernel.org>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Huacai Chen <chenhc@lemote.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
Date: Thu, 07 Mar 2019 03:41:01 -0300	[thread overview]
Message-ID: <orlg1ryyo2.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <alpine.LFD.2.21.1902180227090.15915@eddie.linux-mips.org> (Maciej W. Rozycki's message of "Mon, 18 Feb 2019 02:41:11 +0000 (GMT)")

On Feb 17, 2019, "Maciej W. Rozycki" <macro@linux-mips.org> wrote:

>  Is there an MMIO completion barrier missing there somewhere by any chance 
> causing an IRQ that has been handled already to be redelivered because an 
> MMIO write meant to clear the IRQ at its origin at handler's completion 
> has not reached its destination before interrupts have been reenabled in 
> the issuing CPU?  Just a thought.

I've finally got a chance to bisect the IRQ14 (nobody cared) regression
on my yeeloong.  It took me to MIPS: Enforce strong ordering for MMIO
accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f).

I've only just started trying to figure out what exactly in the change
leads to problems.  So far, I've determined that changing both uses of
__BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1
removes the undesirable effects, both on top of that patch, and on top
of v5.0:

 #define __BUILD_IOPORT_PFX(bus, bwlq, type)				\
- 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)			\
- 	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
+	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,)			\
+	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p)
 

Since the barriers didn't seem to be a problem for __BUILD_MEMORY_PFX, I
figured I'd try to enable barriers in the __mem_ variants, but leave
them alone for io, and that worked (without hitting the IRQ14 issue) at
least on the yeeloong:

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 845fbbc7a2e34..0a3a327d4e764 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -467,13 +467,13 @@ BUILDIO_MEM(w, u16)
 BUILDIO_MEM(l, u32)
 BUILDIO_MEM(q, u64)
 
-#define __BUILD_IOPORT_PFX(bus, bwlq, type)				\
-	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)			\
-	__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
+#define __BUILD_IOPORT_PFX(bus, bwlq, type, barrier)			\
+	__BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0,)		\
+	__BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0, _p)
 
 #define BUILDIO_IOPORT(bwlq, type)					\
-	__BUILD_IOPORT_PFX(, bwlq, type)				\
-	__BUILD_IOPORT_PFX(__mem_, bwlq, type)
+	__BUILD_IOPORT_PFX(, bwlq, type, 0)				\
+	__BUILD_IOPORT_PFX(__mem_, bwlq, type, 1)
 
 BUILDIO_IOPORT(b, u8)
 BUILDIO_IOPORT(w, u16)

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

  reply	other threads:[~2019-03-07  6:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  8:30 [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers Tom Li
2019-02-08 20:08 ` Paul Burton
2019-02-09 10:11   ` Tom Li
2019-02-09 19:38     ` Paul Burton
2019-02-11 12:13 ` Alexandre Oliva
2019-02-11 12:55   ` Tom Li
2019-02-11 22:38     ` Alexandre Oliva
2019-02-11 23:06       ` Aaro Koskinen
2019-02-12  4:39         ` tomli
2019-02-16 23:39         ` Alexandre Oliva
2019-02-17  4:59         ` Alexandre Oliva
2019-02-17 23:59           ` Aaro Koskinen
2019-02-18  1:37             ` Alexandre Oliva
2019-02-18  2:41               ` Maciej W. Rozycki
2019-03-07  6:41                 ` Alexandre Oliva [this message]
2019-03-07 17:59                   ` Maciej W. Rozycki
2019-03-08  0:46                     ` Alexandre Oliva
2019-03-08 23:56                       ` Maciej W. Rozycki
2019-05-26  9:19                         ` Alexandre Oliva
2019-06-10 21:49                           ` Aaro Koskinen
2019-06-12  5:55                             ` Maciej W. Rozycki
2019-06-12 19:24                               ` Aaro Koskinen
2020-01-23  0:20                                 ` Matt Turner
2020-01-24 18:58                                   ` Aaro Koskinen
2019-03-07 20:21                   ` Aaro Koskinen
2019-03-07 21:22                     ` Alexandre Oliva
2019-02-17  4:41     ` Alexandre Oliva

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=orlg1ryyo2.fsf@lxoliva.fsfla.org \
    --to=lxoliva@fsfla.org \
    --cc=aaro.koskinen@iki.fi \
    --cc=chenhc@lemote.com \
    --cc=jhogan@kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=tomli@tomli.me \
    /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;
as well as URLs for NNTP newsgroup(s).