All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Ray Jui <rjui@broadcom.com>, Bjorn Helgaas <bhelgaas@google.com>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com, linux-pci@vger.kernel.org
Subject: Re: [PATCH 4/5] PCI: iproc: Add iProc PCIe MSI support
Date: Wed, 18 Nov 2015 10:50:18 +0100	[thread overview]
Message-ID: <6698299.zIsv0CNpOi@wuerfel> (raw)
In-Reply-To: <20151118084845.49ba6304@arm.com>

On Wednesday 18 November 2015 08:48:45 Marc Zyngier wrote:
> > +static inline u32 iproc_msi_read_reg(struct iproc_msi *msi,
> > +				     enum iproc_msi_reg reg,
> > +				     unsigned int eq)
> > +{
> > +	struct iproc_pcie *pcie = msi->pcie;
> > +
> > +	return readl(pcie->base + msi->reg_offsets[eq][reg]);
> 
> Do you need the extra barrier implied by readl? readl_relaxed should be
> enough.

I suspect this is the one place where it's needed for a lot of
drivers: when the PCI device sends DMA data followed by the MSI
message, the device driver can safely assume that the DMA data
has arrived in memory even without doing another readl() from
the device itself.

It really depends on how the MSI implementation here interacts
with the memory controller, and we should probably have a comment
to explain this either way.

> > +static inline void iproc_msi_write_reg(struct iproc_msi *msi,
> > +				       enum iproc_msi_reg reg,
> > +				       int eq, u32 val)
> > +{
> > +	struct iproc_pcie *pcie = msi->pcie;
> > +
> > +	writel(val, pcie->base + msi->reg_offsets[eq][reg]);
> 
> Same here for writel vs writel_relaxed.

We probably want writel_relaxed() when calling this from
iproc_msi_handler(), but not when calling from
iproc_msi_enable(), which should default to a normal
writel(), so we can be sure it's actually configured right
at the time we return from iproc_msi_init(). You could
try to prove that using writel_relaxed is correct here, but
using writel makes it so much easier.

	Arnd

  reply	other threads:[~2015-11-18  9:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18  0:31 [PATCH 0/5] Add iProc PCIe PAXC and MSI support Ray Jui
2015-11-18  0:31 ` [PATCH 1/5] PCI: iproc: Update iProc PCIe device tree binding Ray Jui
2015-11-18  0:31 ` [PATCH 2/5] PCI: iproc: Add PAXC interface support Ray Jui
2015-11-18  0:34   ` Florian Fainelli
2015-11-18  0:46     ` Ray Jui
2015-11-18  0:45       ` Florian Fainelli
2015-11-18  0:47         ` Ray Jui
2015-11-18  0:31 ` [PATCH 3/5] PCI: iproc: Add iProc PCIe MSI device tree binding Ray Jui
2015-11-18  0:31 ` [PATCH 4/5] PCI: iproc: Add iProc PCIe MSI support Ray Jui
2015-11-18  8:48   ` Marc Zyngier
2015-11-18  9:50     ` Arnd Bergmann [this message]
2015-11-19 19:22       ` Ray Jui
2015-11-19  1:37     ` Ray Jui
2015-11-19  2:56       ` Ray Jui
2015-11-19  7:23       ` Ray Jui
2015-11-19  8:31       ` Arnd Bergmann
2015-11-19 23:05         ` Ray Jui
2015-11-20  8:56       ` Marc Zyngier
2015-11-20 17:07         ` Ray Jui
2015-11-18  0:31 ` [PATCH 5/5] ARM: dts: Enable MSI support for Broadcom Cygnus Ray Jui

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=6698299.zIsv0CNpOi@wuerfel \
    --to=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=hauke@hauke-m.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rjui@broadcom.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 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.