From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will.deacon@arm.com>,
linux-arch <linux-arch@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Peter Zijlstra <peterz@infradead.org>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Daniel Lustig <dlustig@nvidia.com>,
David Howells <dhowells@redhat.com>,
Alan Stern <stern@rowland.harvard.edu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Gregory CLEMENT <gregory.clement@free-electrons.com>,
Russell King - ARM Linux <linux@armlinux.org.uk>
Subject: Re: [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
Date: Tue, 19 Feb 2019 11:27:47 +0100 [thread overview]
Message-ID: <20190219112747.7db95e58@windsurf.home> (raw)
In-Reply-To: <CAK8P3a2mjjr94hwj_eXxfyKDKDuA=MogXW7xJygh-X0Hqgf6rg@mail.gmail.com>
Hello,
On Mon, 18 Feb 2019 21:37:25 +0100
Arnd Bergmann <arnd@arndb.de> wrote:
> > > I would say we should strengthen the behavior of outX() where possible.
> > > I don't know if arm64 actually has a way of doing that, my understanding
> > > earlier was that the AXI bus was already posted, so there is not much
> > > you can do here to define __io_paw() in a way that will prevent posted
> > > writes.
> >
> > If we could map I/O space using different page table attributes (probably by
> > hacking pci_remap_iospace() ?) then we could disable the
> > early-write-acknowledge hint and implement __io_paw() as a completion
> > barrier, although it would be at the mercy of the system as to whether or
> > not that requires a response from the RC.
>
> Ah, it seems we actually do that on 32-bit ARM, at least on one platform,
> see 6a02734d420f ("ARM: mvebu: map PCI I/O regions strongly ordered")
> and prior commits.
Yes, some Marvell Armada 32-bit platforms have an errata that require
the PCI MEM and PCI I/O regions to be mapped strongly ordered.
BTW, this requirement prevents us from using the pci_remap_iospace()
API from drivers/pci, because it assumes page attributes of
pgprot_device(PAGE_KERNEL). That's why we're still using the
ARM-specific pci_ioremap_io() function.
> > I would still prefer to document the weaker semantics as the portable
> > interface, unless there are portable drivers relying on this today (which
> > would imply that it's widely supported by other architectures).
>
> I don't know of any portable driver that actually relies on it, but
> that's mainly because there are very few portable drivers that
> use inb()/outb() in the first place. How many of those require
> the non-posted behavior I don't know
>
> Adding Thomas, Gregory and Russell to Cc, as they were involved
> in the discussion that led to the 32-bit change, maybe they are
> aware of a specific example.
I'm just arriving in the middle of this thread, and I'm not sure to
understand what is the question. If the question is whether PCI I/O is
really used in practice, then I've never seen it be used with Marvell
platforms (but I'm also not aware of all PCIe devices people are
using). I personally have a hacked-up version of the e1000e driver
that intentionally does some PCI I/O accesses, that I use as a way to
validate that PCI I/O support is minimally working, but that's it.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-02-19 10:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 17:29 [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section Will Deacon
2019-02-11 20:22 ` Paul E. McKenney
2019-02-12 18:43 ` Will Deacon
2019-02-12 19:24 ` Paul E. McKenney
2019-02-11 22:34 ` Linus Torvalds
2019-02-12 4:01 ` Benjamin Herrenschmidt
2019-02-13 17:20 ` Will Deacon
2019-02-13 18:27 ` Linus Torvalds
2019-02-13 18:33 ` Peter Zijlstra
2019-02-13 18:43 ` Luck, Tony
2019-02-13 19:31 ` Paul E. McKenney
2019-02-18 16:50 ` Will Deacon
2019-02-19 16:13 ` Will Deacon
2019-02-21 6:22 ` Michael Ellerman
2019-02-22 17:38 ` Will Deacon
2019-02-12 13:03 ` Arnd Bergmann
2019-02-18 16:29 ` Will Deacon
2019-02-18 16:59 ` Arnd Bergmann
2019-02-18 17:56 ` Will Deacon
2019-02-18 20:37 ` Arnd Bergmann
2019-02-19 10:27 ` Thomas Petazzoni [this message]
2019-02-19 11:31 ` Arnd Bergmann
2019-02-19 11:36 ` Will Deacon
2019-02-19 13:01 ` Arnd Bergmann
2019-02-19 13:20 ` Will Deacon
2019-02-19 13:45 ` Arnd Bergmann
2019-02-19 11:34 ` Will Deacon
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=20190219112747.7db95e58@windsurf.home \
--to=thomas.petazzoni@bootlin.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=gregory.clement@free-electrons.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=paulmck@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=thomas.petazzoni@free-electrons.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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).