linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Casey Leedom <leedom@chelsio.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	"Luis R. Rodriguez" <mcgrof@suse.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Toshi Kani" <toshi.kani@hp.com>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Juergen Gross" <jgross@suse.com>,
	"Tomi Valkeinen" <tomi.valkeinen@ti.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-fbdev <linux-fbdev@vger.kernel.org>,
	"Suresh Siddha" <sbsiddha@gmail.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Dave Airlie" <airlied@redhat.com>,
	"Antonino Daplas" <adaplas@gmail.com>,
	"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"venkatesh.pallipadi@intel.com" <venkatesh.pallipadi@intel.com>,
	"Stefan Bader" <stefan.bader@canonical.com>,
	ville.syrjala@linux.intel.com,
	"David Vrabel" <david.vrabel@citrix.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
Date: Fri, 26 Jun 2015 12:02:03 +1000	[thread overview]
Message-ID: <1435284123.3822.24.camel@kernel.crashing.org> (raw)
In-Reply-To: <4985EFDD773FCB459EF7915D2A3621ADC031F8@nice.asicdesigners.com>

On Thu, 2015-06-25 at 21:40 +0000, Casey Leedom wrote:
> 
> Ah, thanks.  I see now that the __raw_*() APIs don't do any of the
> Endian Swizzling.  Unfortunately the *_relaxed() APIs on PowerPC
> are just defined as the normal *() routines.  From
> arch/powerpc/include/asm/io.h:
> 
>     /*
>      * We don't do relaxed operations yet, at least not with this
> semantic
>      */

Yes so I was looking at this but there are some difficulties.
Architecturally, even with I=1 G=1 mappings (normal ioremap), we have no
guarantee of ordering of load vs. store unless I misunderstood
something. I think all current implementations provide some of that but
without barriers in the accessors, we aren't architecturally correct.

However, having those barriers will cause issues with G=0 (write
combine). It's unclear whether eieio() will provide the required
ordering for I=1 G=0 mappings and it will probably break write combine.

I'm looking into it with our HW guys and will try to come up with a
solution for power, but it doesn't help that our memory model conflates
write combining with other relaxations and that all our barriers also
prevent write combine.

Maybe we can bias the relaxed accessors toward write, by having no
barriers in it, and putting extra ones in reads.

Cheers,
Ben.


  parent reply	other threads:[~2015-06-26  2:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 22:08 [PATCH v7 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 1/9] pci: add pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 2/9] video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 3/9] video: fbdev: kyrofb: " Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 4/9] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants Luis R. Rodriguez
2015-06-23 22:42   ` Benjamin Herrenschmidt
2015-06-24 16:38     ` Luis R. Rodriguez
2015-06-24 22:05       ` Benjamin Herrenschmidt
2015-06-24 22:29         ` Luis R. Rodriguez
2015-06-24 23:38           ` Benjamin Herrenschmidt
2015-06-25  0:08             ` Luis R. Rodriguez
2015-06-25  0:52               ` Benjamin Herrenschmidt
2015-06-25  0:58                 ` [Xen-devel] " Luis R. Rodriguez
2015-06-25  1:12                   ` Benjamin Herrenschmidt
2015-06-25 15:01             ` Casey Leedom
2015-06-25 20:44               ` Arnd Bergmann
2015-06-25 21:40                 ` Casey Leedom
2015-06-25 22:51                   ` Benjamin Herrenschmidt
2015-06-26 19:31                     ` Luis R. Rodriguez
2015-06-26 22:04                       ` Benjamin Herrenschmidt
     [not found]                         ` <CAB=NE6XwczF6FYXV=RHyK=7ikVk_tGp+h9ouWPyORNENq4+=Kw@mail.gmail.com>
2015-06-26 23:54                           ` [Xen-devel] " Benjamin Herrenschmidt
2015-06-27  1:16                             ` Luis R. Rodriguez
2015-06-26  2:02                   ` Benjamin Herrenschmidt [this message]
2015-06-26 16:24                     ` Casey Leedom
2015-06-26 22:00                       ` Benjamin Herrenschmidt
2015-07-02 18:49                         ` Luis R. Rodriguez
2015-07-02 22:26                           ` Benjamin Herrenschmidt
2015-07-03  0:14                           ` Casey Leedom
2015-06-19 22:08 ` [PATCH v7 6/9] lib: devres: add pcim_iomap_wc() variants Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 7/9] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc() Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 8/9] video: fbdev: s3fb: " Luis R. Rodriguez
2015-06-19 22:08 ` [PATCH v7 9/9] video: fbdev: vt8623fb: " Luis R. Rodriguez
2015-06-23 10:53 ` [PATCH v7 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Arnd Bergmann

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=1435284123.3822.24.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=adaplas@gmail.com \
    --cc=airlied@redhat.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.vrabel@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=leedom@chelsio.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@suse.com \
    --cc=mingo@elte.hu \
    --cc=mst@redhat.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=roger.pau@citrix.com \
    --cc=sbsiddha@gmail.com \
    --cc=stefan.bader@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.com \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=ville.syrjala@linux.intel.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).