linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Alan Mikhak <alan.mikhak@sifive.com>
Cc: Joao Pinto <Joao.Pinto@synopsys.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Graeme Gregory <graeme.gregory@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Leif Lindholm <leif@nuviainc.com>, Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH 2/3] pci: designware: add separate driver for the MSI part of the RC
Date: Sat, 15 Feb 2020 10:35:56 +0100	[thread overview]
Message-ID: <CAKv+Gu9W0v9owp85hkAatwCvu-y9z4BZxvbKf92N-s_nnD910Q@mail.gmail.com> (raw)
In-Reply-To: <1581728065-5862-1-git-send-email-alan.mikhak@sifive.com>

(updated some email addresses in cc, including my own)

On Sat, 15 Feb 2020 at 01:54, Alan Mikhak <alan.mikhak@sifive.com> wrote:
>
> Hi..
>
> What is the right approach for adding MSI support for the generic
> Linux PCI host driver?
>
> I came across this patch which seems to address a similar
> situation. It seems to have been dropped in v3 of the patchset
> with the explanation "drop MSI patch [for now], since it
> turns out we may not need it".
>
> [PATCH 2/3] pci: designware: add separate driver for the MSI part of the RC
> https://lore.kernel.org/linux-pci/20170821192907.8695-3-ard.biesheuvel@linaro.org/
>
> [PATCH v2 2/3] pci: designware: add separate driver for the MSI part of the RC
> https://lore.kernel.org/linux-pci/20170824184321.19432-3-ard.biesheuvel@linaro.org/
>
> [PATCH v3 0/2] pci: add support for firmware initialized designware RCs
> https://lore.kernel.org/linux-pci/20170828180437.2646-1-ard.biesheuvel@linaro.org/
>

For the platform in question, it turned out that we could use the MSI
block of the core's GIC interrupt controller directly, which is a much
better solution.

In general, turning MSIs into wired interrupts is not a great idea,
since the whole point of MSIs is that they are sufficiently similar to
other DMA transactions to ensure that the interrupt won't arrive
before the related memory transactions have completed.

If your interrupt controller does not have this capability, then yes,
you are stuck with this little widget that decodes an inbound write to
a magic address and turns it into a wired interrupt.

I'll leave it up to the Synopsys folks to comment on whether this
feature is generic enough to describe it like this, but if so, I think
it still makes sense to model it this way rather than fold it into the
RC driver and description.

  reply	other threads:[~2020-02-15  9:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 19:29 [PATCH 0/3] pci: add support for firmware initialized designware RCs Ard Biesheuvel
2017-08-21 19:29 ` [PATCH 1/3] pci: designware: add driver for DWC controller in ECAM shift mode Ard Biesheuvel
2017-08-24 16:24   ` kbuild test robot
2017-08-24 16:25   ` kbuild test robot
2017-08-21 19:29 ` [PATCH 2/3] pci: designware: add separate driver for the MSI part of the RC Ard Biesheuvel
2017-08-24 16:42   ` Bjorn Helgaas
2017-08-24 16:43     ` Ard Biesheuvel
2017-08-24 16:48   ` Robin Murphy
2017-08-24 16:50     ` Ard Biesheuvel
2020-02-15  0:54   ` Alan Mikhak
2020-02-15  9:35     ` Ard Biesheuvel [this message]
2020-02-15 10:36       ` Marc Zyngier
2020-02-18 19:09         ` Alan Mikhak
2020-02-19  8:11           ` Marc Zyngier
2020-02-19  8:17             ` Ard Biesheuvel
2020-02-19 20:24               ` Alan Mikhak
2020-02-19 21:06                 ` Ard Biesheuvel
2020-02-19 21:35                   ` Alan Mikhak
2017-08-21 19:29 ` [PATCH 3/3] dt-bindings: designware: add binding for Designware PCIe in ECAM mode Ard Biesheuvel
2017-08-24 16:46 ` [PATCH 0/3] pci: add support for firmware initialized designware RCs Bjorn Helgaas
2017-08-31 19:21   ` Ard Biesheuvel

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=CAKv+Gu9W0v9owp85hkAatwCvu-y9z4BZxvbKf92N-s_nnD910Q@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=Joao.Pinto@synopsys.com \
    --cc=alan.mikhak@sifive.com \
    --cc=bhelgaas@google.com \
    --cc=graeme.gregory@linaro.org \
    --cc=jingoohan1@gmail.com \
    --cc=leif@nuviainc.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=maz@kernel.org \
    /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).