From: Marc Zyngier <firstname.lastname@example.org> To: Ard Biesheuvel <email@example.com> Cc: Alan Mikhak <firstname.lastname@example.org>, Joao Pinto <Joao.Pinto@synopsys.com>, Bjorn Helgaas <email@example.com>, Graeme Gregory <firstname.lastname@example.org>, Jingoo Han <email@example.com>, linux-arm-kernel <firstname.lastname@example.org>, linux-pci <email@example.com>, Leif Lindholm <firstname.lastname@example.org> Subject: Re: [PATCH 2/3] pci: designware: add separate driver for the MSI part of the RC Date: Sat, 15 Feb 2020 10:36:36 +0000 Message-ID: <email@example.com> (raw) In-Reply-To: <CAKv+Gu9W0v9owp85hkAatwCvu-y9z4BZxvbKf92N-s_nnD910Q@mail.gmail.com> On Sat, 15 Feb 2020 09:35:56 +0000, Ard Biesheuvel <firstname.lastname@example.org> wrote: > > (updated some email addresses in cc, including my own) > > On Sat, 15 Feb 2020 at 01:54, Alan Mikhak <email@example.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://firstname.lastname@example.org/ > > > > [PATCH v2 2/3] pci: designware: add separate driver for the MSI part of the RC > > https://email@example.com/ > > > > [PATCH v3 0/2] pci: add support for firmware initialized designware RCs > > https://firstname.lastname@example.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 can only second this. It is much better to have a generic block implementing MSI *in a non multiplexed way*, for multiple reasons: - the interrupt vs DMA race that Ard mentions above, - MSIs are very often used to describe the state of per-CPU queues. If you multiplex MSIs behind a single multiplexing interrupt, it is always the same CPU that gets interrupted, and you don't benefit from having multiple queues at all. Even if you have to implement the support as a bunch of wired interrupts, there is still a lot of value in keeping a 1:1 mapping between MSIs and wires. Thanks, M. -- Jazz is not dead, it just smells funny.
next prev parent reply index Thread overview: 20+ 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 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 2020-02-15 10:36 ` Marc Zyngier [this message] 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 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
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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Joao.Pinto@synopsys.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-PCI Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \ email@example.com public-inbox-index linux-pci Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci AGPL code for this site: git clone https://public-inbox.org/public-inbox.git