From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver
Date: Tue, 26 Mar 2013 18:38:22 +0000 [thread overview]
Message-ID: <201303261838.23246.arnd@arndb.de> (raw)
In-Reply-To: <20130326181754.33b89559@skate>
On Tuesday 26 March 2013, Thomas Petazzoni wrote:
>
> I've tried to explain that in the commit log of PATCH 6, which says:
>
> However, we need the driver to expose two different IRQ domains: one
> for the main interrupt controller itself, and one for the MSI
> interrupt controller. In order to achieve this, we will create two
> subnodes in the interrupt-controller at d0020000 node: one subnode for
> the main interrupt controller, and one subnode for the MSI interrupt
> controller. The two irq domains can't be registered on the same DT
> node, otherwise when irq_find_host() gets used by of_irq_map_one()
> to resolve IRQs of devices, they may find the MSI interrupt
> controller instead of the main interrupt controller.
Right, I should have read the commit log better ...
> Note that both the parent and the child node need to have the
> 'interrupt-controller' empty property:
>
> * The interrupt-controller property is needed in the main
> interrupt controller node (interrupt-controller at d0020000) because
> the of_irq_init() function skips nodes that are matching the given
> compatible string, but that don't have the interrupt-controller
> property.
>
> * The interrupt-controller property is needed in the child
> interrupt controller node (main-intc at d0020000) otherwise the
> resolution done by of_irq_map_one() doesn't work.
If you add compatible properties to the children, that would work
I suppose.
> So really, the thing is that irq_domain_add_linear() registers an IRQ
> domain on a specific DT node, and then irq_find_host() finds back an
> IRQ domain from a given DT node. So if you have two IRQ domains
> registered on the same DT node, then you don't know which one will be
> used.
>
> So if I do the two irq_domain_add_linear() (one for MPIC, one for MSI)
> on one single DT node, when the timer driver will request its
> interrupt, it turns out that the MSI IRQ domain is used and not the
> MPIC IRQ domain, even though the timer has <&mpic> as its interrupt
> parent.
I still wonder if the real solution shouldn't instead be to make the
irq domain code MSI aware. For instance, you don't really need a
cell to describe an interrupt because the interrupt number is
not a hardware property. So an MSI using device doesn't really
needs an "msis" or "interrupts" property, just an "msi-parent",
and we can add code to handle as a separate domain even if you
have a single device node that can do both level and message
interrupts.
Arnd
next prev parent reply other threads:[~2013-03-26 18:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 16:52 [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
[not found] ` <1364316746-8702-3-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 16:54 ` [RFCv1 02/11] irqchip: move IRQ driver for Armada 370/XP Arnd Bergmann
2013-03-26 17:05 ` [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-03-26 17:18 ` Arnd Bergmann
2013-03-26 17:21 ` Thomas Petazzoni
[not found] ` <1364316746-8702-8-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 17:07 ` [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver Arnd Bergmann
2013-03-26 17:17 ` Thomas Petazzoni
2013-03-26 18:38 ` Arnd Bergmann [this message]
2013-03-26 20:46 ` Thomas Petazzoni
2013-03-26 21:10 ` Arnd Bergmann
2013-03-26 21:37 ` Thomas Petazzoni
2013-03-26 21:53 ` Arnd Bergmann
2013-03-26 21:14 ` Jason Gunthorpe
2013-03-26 21:41 ` Thomas Petazzoni
2013-03-26 18:02 ` Jason Gunthorpe
2013-03-26 21:16 ` Thomas Petazzoni
2013-03-26 21:31 ` Arnd Bergmann
2013-03-26 21:47 ` Thomas Petazzoni
2013-03-26 21:55 ` Jason Gunthorpe
2013-03-26 22:04 ` Arnd Bergmann
2013-03-26 22:06 ` Thomas Petazzoni
2013-03-26 22:26 ` Jason Gunthorpe
2013-03-26 21:15 ` Arnd Bergmann
2013-03-26 21:42 ` Thomas Petazzoni
[not found] ` <1364316746-8702-2-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 16:53 ` [RFCv1 01/11] arm: mvebu: move L2 cache initialization in init_early() Arnd Bergmann
2013-03-26 17:02 ` Thomas Petazzoni
2013-03-27 1:53 ` Rob Herring
2013-04-04 9:16 ` [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Ezequiel Garcia
2013-04-04 9:29 ` Thomas Petazzoni
[not found] ` <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
2013-04-08 22:28 ` [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure Bjorn Helgaas
2013-04-09 8:11 ` Andrew Murray
2013-04-09 8:22 ` Thierry Reding
2013-04-09 8:25 ` Andrew Murray
2013-04-09 8:18 ` Thierry Reding
[not found] ` <1364316746-8702-10-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-27 10:07 ` [RFCv1 09/11] pci: mvebu: add MSI support Andrew Murray
2013-04-08 22:29 ` Bjorn Helgaas
2013-05-30 12:15 ` Thierry Reding
2013-05-30 18:13 ` Bjorn Helgaas
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=201303261838.23246.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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).