All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Alexandre Oliva <lxoliva@fsfla.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, 7 Mar 2019 17:59:42 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.21.1903071744560.7728@eddie.linux-mips.org> (raw)
In-Reply-To: <orlg1ryyo2.fsf@lxoliva.fsfla.org>

Hi Alexandre,

 I'm away on holiday and also connectivity is so-so here, so just a quick 
reply.

> >  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).

 Thanks for looking into it.

> 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)

 So this seems backwards to me, port I/O is supposed to be strongly 
ordered, so if removing the ordering guarantee "fixes" your problem, then 
there must be a second bottom here.  Offhand either there is a race 
condition somewhere which the lack of ordering here covers somehow, or 
there is a silicon erratum of some sort somewhere that the SYNC 
instruction triggers.

 A further investigation is required I'm afraid.  Does your platform use 
`war_io_reorder_wmb'?

  Maciej

  reply	other threads:[~2019-03-07 17:59 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 [this message]
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=alpine.LFD.2.21.1903071744560.7728@eddie.linux-mips.org \
    --to=macro@linux-mips.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=lxoliva@fsfla.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.