lkml.org 
[lkml]   [2019]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
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

\
 
 \ /
  Last update: 2019-02-19 11:28    [W:0.040 / U:0.908 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site