All of lore.kernel.org
 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: Sun, 26 May 2019 06:19:00 -0300	[thread overview]
Message-ID: <or7ead4lq3.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <alpine.LFD.2.21.1903082347330.31648@eddie.linux-mips.org> (Maciej W. Rozycki's message of "Fri, 8 Mar 2019 23:56:03 +0000 (GMT)")

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

>  Anyway I meant: does `war_io_reorder_wmb' expand to `wmb' on your system?

No, it expands to `barrier' on the yeeloong:

CONFIG_CPU_LOONGSON2F=y
CONFIG_CPU_LOONGSON2F_WORKAROUNDS=y
CONFIG_CPU_LOONGSON2=y
CONFIG_SYS_HAS_CPU_LOONGSON2F=y


I've finally managed to do the bisection on object files I mentioned I'd
do to try to pinpoint where __BUILT_IOPORT_PFX with barrier rather than
!barrier regressed.

I found that forcing barrier off for drivers/irqchip/irq-i8259 was
enough to avoid the problem.

(I further narrowed it down to byte I/O, which is no surprise
considering irq-i8259 doesn't seem to use any non-byte I/O.)

Then I narrowed it down to output only.

A Loongson2F kernel built with the patch below works at normal speed.
I've also keyed the -1 barrier selector to compiling the irq-i8259
driver only, and that got me a functional kernel, but I'm not confident
that the same issues that affect the interrupt controller, preventing it
from initializing correctly, is not also affecting other drivers, just
in less visible ways, so the patch conservatively reverts to the older
barriers for all I/O (i.e., non-mem) out primitives.

I've tested this on a yeeloong on top of v5.1.5.

I'm tempted to start using this patch in my Freeloong builds of GNU
Linux-libre for gnewsense/yeeloong of 5.0 and 5.1 stable releases, to
try to make them usable.  Can anyone suggest any reason why it might be
risky to do so, moving on as much as I could to the new barriers,
sticking to the 4.19-one only for non-mem out?  As in, could mixing the
barriers be riskier than reverting to the 4.19 barriers everywhere?

Thanks in advance for any insights and recommendations,


diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 845fbbc7a2e3..04be4758d4ff 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -416,7 +416,7 @@ static inline void pfx##out##bwlq##p(type val, unsigned long port)	\
 	volatile type *__addr;						\
 	type __val;							\
 									\
-	if (barrier)							\
+	if (barrier > 0)						\
 		iobarrier_rw();						\
 	else								\
 		war_io_reorder_wmb();					\
@@ -467,13 +467,22 @@ 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)
+
+/* Choose the kind of barrier used for out in __BUILD_IOPORT_SINGLE in
+   non-__mem_ variants.  On Loongson2F, irq-i8259 fails to initialize
+   when this is defined to 1.  */
+#if defined(CONFIG_CPU_LOONGSON2)
+#define USE_IO_BARRIER_FOR_NON_MEM_OUT -1
+#else
+#define USE_IO_BARRIER_FOR_NON_MEM_OUT 1
+#endif
 
 #define BUILDIO_IOPORT(bwlq, type)					\
-	__BUILD_IOPORT_PFX(, bwlq, type)				\
-	__BUILD_IOPORT_PFX(__mem_, bwlq, type)
+	__BUILD_IOPORT_PFX(, bwlq, type, USE_IO_BARRIER_FOR_NON_MEM_OUT) \
+	__BUILD_IOPORT_PFX(__mem_, bwlq, type, 2)
 
 BUILDIO_IOPORT(b, u8)
 BUILDIO_IOPORT(w, u16)


-- 
Alexandre Oliva, freedom fighter  he/him   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 - Che GNUevara

  reply	other threads:[~2019-05-26  9:28 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
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 [this message]
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=or7ead4lq3.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.