From: Casey Leedom <leedom@chelsio.com> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, "Luis R. Rodriguez" <mcgrof@suse.com> Cc: "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>, "Arnd Bergmann" <arnd@arndb.de>, "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 Syrjälä" <syrjala@sci.fi>, "Mel Gorman" <mgorman@suse.de>, "Vlastimil Babka" <vbabka@suse.cz>, "Borislav Petkov" <bp@suse.de>, "Davidlohr Bueso" <dbueso@suse.de>, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "Ville Syrjälä" <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: Thu, 25 Jun 2015 15:01:56 +0000 [thread overview] Message-ID: <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com> (raw) In-Reply-To: <1435189081.3790.24.camel@kernel.crashing.org> / From: Benjamin Herrenschmidt [benh@kernel.crashing.org] | Sent: Wednesday, June 24, 2015 4:38 PM | | It is to be noted that on powerpc at least, writel() and co will never | combine due to the memory barriers in them. Only "normal" stores (or \ __raw_writel) will. / From: Benjamin Herrenschmidt [benh@kernel.crashing.org] | Sent: Wednesday, June 24, 2015 5:52 PM | | Right, and as I mentioned, on some archs like powerpc (and possibly \ more), writel() and co contains an implicit mb() Hhmmm, interesting. I definitely hadn't known that. In our network drivers we explicitly manage all of our own memory barrier semantics. (wmb() between writes to DMA Queues and writes to Device Registers informing hardware of new data available to be DMA'ed, etc.) And we do have code to take advantage of Write Combining Mappings using writeq(). It looks like this is implemented eventually as out_be64() in arch/powerpc/include/asm/io.h for PPC-BE: #define DEF_MMIO_OUT_D(name, size, insn) \ static inline void name(volatile u##size __iomem *addr, u##size val) \ { \ __asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \ : "=m" (*addr) : "r" (val) : "memory"); \ IO_SET_SYNC_FLAG(); \ } DEF_MMIO_OUT_D(out_be64, 64, std); So, if understand your notes and the source correctly, all of our code to do register reads/writes are getting SYNC instructions, as are the 64-bit writeq()s we're attempting to use for our Write Combining code on PowerPC. Hhmmm indeed ... Is there a reference I can read on this so I can understand when and where we can use the __raw_*() APIs? Can these Raw Read/Write operations be reordered with respect to each other or are the use of the various flavors of SYNC instructions just to maintain order between Cached Memory Accesses and I/O Instructions? Casey
WARNING: multiple messages have this Message-ID (diff)
From: Casey Leedom <leedom@chelsio.com> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, "Luis R. Rodriguez" <mcgrof@suse.com> Cc: "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>, Arnd Bergmann <arnd@arndb.de>, "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 <s> Subject: RE: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants Date: Thu, 25 Jun 2015 15:01:56 +0000 [thread overview] Message-ID: <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com> (raw) In-Reply-To: <1435189081.3790.24.camel@kernel.crashing.org> / From: Benjamin Herrenschmidt [benh@kernel.crashing.org] | Sent: Wednesday, June 24, 2015 4:38 PM | | It is to be noted that on powerpc at least, writel() and co will never | combine due to the memory barriers in them. Only "normal" stores (or \ __raw_writel) will. / From: Benjamin Herrenschmidt [benh@kernel.crashing.org] | Sent: Wednesday, June 24, 2015 5:52 PM | | Right, and as I mentioned, on some archs like powerpc (and possibly \ more), writel() and co contains an implicit mb() Hhmmm, interesting. I definitely hadn't known that. In our network drivers we explicitly manage all of our own memory barrier semantics. (wmb() between writes to DMA Queues and writes to Device Registers informing hardware of new data available to be DMA'ed, etc.) And we do have code to take advantage of Write Combining Mappings using writeq(). It looks like this is implemented eventually as out_be64() in arch/powerpc/include/asm/io.h for PPC-BE: #define DEF_MMIO_OUT_D(name, size, insn) \ static inline void name(volatile u##size __iomem *addr, u##size val) \ { \ __asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0" \ : "=m" (*addr) : "r" (val) : "memory"); \ IO_SET_SYNC_FLAG(); \ } DEF_MMIO_OUT_D(out_be64, 64, std); So, if understand your notes and the source correctly, all of our code to do register reads/writes are getting SYNC instructions, as are the 64-bit writeq()s we're attempting to use for our Write Combining code on PowerPC. Hhmmm indeed ... Is there a reference I can read on this so I can understand when and where we can use the __raw_*() APIs? Can these Raw Read/Write operations be reordered with respect to each other or are the use of the various flavors of SYNC instructions just to maintain order between Cached Memory Accesses and I/O Instructions? Casey
next prev parent reply other threads:[~2015-06-25 15:03 UTC|newest] Thread overview: 104+ 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` [PATCH v7 3/9] video: fbdev: kyrofb: " Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-23 22:42 ` Benjamin Herrenschmidt 2015-06-23 22:42 ` Benjamin Herrenschmidt 2015-06-23 22:42 ` Benjamin Herrenschmidt 2015-06-24 16:38 ` Luis R. Rodriguez 2015-06-24 16:38 ` Luis R. Rodriguez 2015-06-24 16:38 ` Luis R. Rodriguez 2015-06-24 22:05 ` Benjamin Herrenschmidt 2015-06-24 22:05 ` Benjamin Herrenschmidt 2015-06-24 22:05 ` Benjamin Herrenschmidt 2015-06-24 22:29 ` Luis R. Rodriguez 2015-06-24 22:29 ` Luis R. Rodriguez 2015-06-24 22:29 ` Luis R. Rodriguez 2015-06-24 23:38 ` Benjamin Herrenschmidt 2015-06-24 23:38 ` Benjamin Herrenschmidt 2015-06-24 23:38 ` Benjamin Herrenschmidt 2015-06-25 0:08 ` Luis R. Rodriguez 2015-06-25 0:08 ` Luis R. Rodriguez 2015-06-25 0:08 ` Luis R. Rodriguez 2015-06-25 0:52 ` Benjamin Herrenschmidt 2015-06-25 0:52 ` Benjamin Herrenschmidt 2015-06-25 0:52 ` Benjamin Herrenschmidt 2015-06-25 0:58 ` [Xen-devel] " Luis R. Rodriguez 2015-06-25 0:58 ` Luis R. Rodriguez 2015-06-25 0:58 ` Luis R. Rodriguez 2015-06-25 1:12 ` Benjamin Herrenschmidt 2015-06-25 1:12 ` Benjamin Herrenschmidt 2015-06-25 1:12 ` Benjamin Herrenschmidt 2015-06-25 15:01 ` Casey Leedom [this message] 2015-06-25 15:01 ` Casey Leedom 2015-06-25 20:44 ` Arnd Bergmann 2015-06-25 20:44 ` Arnd Bergmann 2015-06-25 20:44 ` Arnd Bergmann 2015-06-25 21:40 ` Casey Leedom 2015-06-25 21:40 ` Casey Leedom 2015-06-25 22:51 ` Benjamin Herrenschmidt 2015-06-25 22:51 ` Benjamin Herrenschmidt 2015-06-25 22:51 ` Benjamin Herrenschmidt 2015-06-26 19:31 ` Luis R. Rodriguez 2015-06-26 19:31 ` Luis R. Rodriguez 2015-06-26 19:31 ` Luis R. Rodriguez 2015-06-26 22:04 ` Benjamin Herrenschmidt 2015-06-26 22:04 ` Benjamin Herrenschmidt 2015-06-26 22:04 ` Benjamin Herrenschmidt 2015-06-26 22:41 ` Luis R. Rodriguez 2015-06-26 23:54 ` [Xen-devel] " Benjamin Herrenschmidt 2015-06-26 23:54 ` Benjamin Herrenschmidt 2015-06-26 23:54 ` [Xen-devel] " Benjamin Herrenschmidt 2015-06-27 1:16 ` Luis R. Rodriguez 2015-06-27 1:16 ` Luis R. Rodriguez 2015-06-27 1:16 ` [Xen-devel] " Luis R. Rodriguez 2015-06-26 2:02 ` Benjamin Herrenschmidt 2015-06-26 2:02 ` Benjamin Herrenschmidt 2015-06-26 2:02 ` Benjamin Herrenschmidt 2015-06-26 16:24 ` Casey Leedom 2015-06-26 16:24 ` Casey Leedom 2015-06-26 22:00 ` Benjamin Herrenschmidt 2015-06-26 22:00 ` Benjamin Herrenschmidt 2015-06-26 22:00 ` Benjamin Herrenschmidt 2015-07-02 18:49 ` Luis R. Rodriguez 2015-07-02 18:49 ` Luis R. Rodriguez 2015-07-02 18:49 ` Luis R. Rodriguez 2015-07-02 22:26 ` Benjamin Herrenschmidt 2015-07-02 22:26 ` Benjamin Herrenschmidt 2015-07-02 22:26 ` Benjamin Herrenschmidt 2015-07-03 0:14 ` Casey Leedom 2015-07-03 0:14 ` Casey Leedom 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` 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 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` [PATCH v7 8/9] video: fbdev: s3fb: " Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` [PATCH v7 9/9] video: fbdev: vt8623fb: " Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-19 22:08 ` Luis R. Rodriguez 2015-06-23 10:53 ` [PATCH v7 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Arnd Bergmann 2015-06-23 10:53 ` 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=4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com \ --to=leedom@chelsio.com \ --cc=adaplas@gmail.com \ --cc=airlied@redhat.com \ --cc=arnd@arndb.de \ --cc=benh@kernel.crashing.org \ --cc=bhelgaas@google.com \ --cc=bp@suse.de \ --cc=daniel.vetter@ffwll.ch \ --cc=dave.hansen@linux.intel.com \ --cc=david.vrabel@citrix.com \ --cc=dbueso@suse.de \ --cc=jbeulich@suse.com \ --cc=jgross@suse.com \ --cc=konrad.wilk@oracle.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=mgorman@suse.de \ --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=syrjala@sci.fi \ --cc=tglx@linutronix.de \ --cc=tomi.valkeinen@ti.com \ --cc=toshi.kani@hp.com \ --cc=vbabka@suse.cz \ --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: linkBe 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.