From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: bp@suse.de, mingo@kernel.org, arnd@arndb.de, bhelgaas@google.com,
luto@amacapital.net, akpm@linux-foundation.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
tomi.valkeinen@ti.com, mst@redhat.com, toshi.kani@hp.com,
linux-fbdev@vger.kernel.org, xen-devel@lists.xensource.com,
"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Fri, 26 Jun 2015 12:12:06 +1000 [thread overview]
Message-ID: <1435284726.3822.28.camel@kernel.crashing.org> (raw)
In-Reply-To: <1435195342-26879-1-git-send-email-mcgrof@do-not-panic.com>
On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote:
> Although I had test compiled this before just to be safe I went ahead and
> successfully test-compiled this set with allmodconfig, specially since I've now
> removed the exports for the devres routines. Please let me know if these might
> be able to go through you or if there are any questions. I will note the recent
> discussion with Benjamin over the v7 series concluded that the ideas we both
> were alluding to, on automating instead the WC effects for devices seems a bit
> too idealistic for PCI / PCIE for now, but perhaps we should at least consider
> this in the future for userspace mmap() calls [4].
So I've been trying to figure out how to make this practically work for us (powerpc).
writel() will never write combine for us, it uses too heavy barriers.
writel_relaxed() today is identical to writel() but we can change it.
The problem is that switching to G=0 mappings (which is what provides us with write
combining) also architecturally enables prefetch and speculative loads... and again
architecturally (the implementations may differ), kills the effect of the lightweight
io barrier eieio which we would have to use in readl_relaxed() and writel_relaxed()
to provide their normal semantics.
So it boils down to: Can we modify the documentation of readl_relaxed() and writel_relaxed()
to define them as being even further relaxed when using a "wc" mapping ?
Otherwise, the only way out I see for us on powerpc is to bias massively writel_relaxed()
against real_relaxed() by putting heavy barriers around the load in the latter so we can
keep them completely out of the former and still enable wc.
Ben.
next prev parent reply other threads:[~2015-06-26 2:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 1:22 [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 1/9] pci: add pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 2/9] video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 3/9] video: fbdev: kyrofb: " Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 4/9] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 5/9] PCI: Add pci_iomap_wc() variants Luis R. Rodriguez
2015-06-25 15:09 ` Borislav Petkov
2015-06-25 15:53 ` Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 6/9] lib: devres: add pcim_iomap_wc() variants Luis R. Rodriguez
2015-06-25 15:40 ` Borislav Petkov
2015-06-25 15:51 ` Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 7/9] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc() Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 8/9] video: fbdev: s3fb: " Luis R. Rodriguez
2015-06-25 1:22 ` [PATCH v8 9/9] video: fbdev: vt8623fb: " Luis R. Rodriguez
2015-06-25 20:47 ` [PATCH v8 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Borislav Petkov
2015-06-26 2:12 ` Benjamin Herrenschmidt [this message]
2015-07-07 16:15 ` Luis R. Rodriguez
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=1435284726.3822.28.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=mingo@kernel.org \
--cc=mst@redhat.com \
--cc=tomi.valkeinen@ti.com \
--cc=toshi.kani@hp.com \
--cc=xen-devel@lists.xensource.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).