devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Lior Amsalem <alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	Tawfik Bayouk <tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	Maen Suleiman <maen-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Andrew Murray <andrew.murray-5wv7dgnIgG8@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Subject: Re: [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver
Date: Tue, 26 Mar 2013 21:10:15 +0000	[thread overview]
Message-ID: <201303262110.15582.arnd@arndb.de> (raw)
In-Reply-To: <20130326214613.30fbdddf@skate>

On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
> 
> On Tue, 26 Mar 2013 18:38:22 +0000, Arnd Bergmann wrote:
> 
> > >     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@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@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.
> 
> To which children? Only to the main-intc children? If so,
> armada_370_xp_mpic_of_init() would be called with a 'device_node *'
> that points to the main-intc, correct? Then it would have to go back up
> in the Device Tree to find the msi node? It's doable of course, but
> sounds strange, no?

I was thinking of registering two init functions as well.

> To me, the topology of the hardware is really that a single device
> provides two features: the main interrupt controller and the MSI
> interrupt controller. But I will adapt to whatever DT binding you
> propose.

My preference would be to have no sub-nodes but rather make the
code deal with an interrupt controller that has an interrupt domain
for regular IRQs but can also handle MSI.

> > 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.
> 
> So the msi-parent property should point to the single mpic node? But
> then the IRQ domain for MSI cannot be registered on this single MPIC
> node. Then, what would be the first argument of:
> 
>         armada_370_xp_msi_domain =
>                 irq_domain_add_linear(msi_node, PCI_MSI_DOORBELL_NR,
>                                       &armada_370_xp_msi_irq_ops, NULL);
> 
> and how would the PCIe driver get a pointer to this IRQ domain? (In the
> currently proposed code, it just does a irq_find_host(), which sounded
> very simple and straightforward).

I guess one way would be to have a single domain that is responsible
for the controller and handles both MSI and legacy interrupts. That
could probably be done without changes to the interrupt domain code.

Another option would be to add an irq_domain_add_msi() function that
creates a domain which is also tied to the same device node but does
not interact with it when going through the legacy interrupts.
You could then add a matching msi_find_host() or irq_find_msi_host()
function to return the domain.

> To clarify: I really don't mind reworking the code, but unfortunately
> "make the IRQ domain code MSI aware" is too vague for me to understand
> the direction you're thinking of.

I don't have specific code in mind yet, mainly playing around with the
possibilities for now.

	Arnd

  reply	other threads:[~2013-03-26 21:10 UTC|newest]

Thread overview: 49+ 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
2013-03-26 16:52 ` [RFCv1 01/11] arm: mvebu: move L2 cache initialization in init_early() Thomas Petazzoni
2013-03-26 16:53   ` Arnd Bergmann
     [not found]     ` <201303261653.48998.arnd-r2nGTMty4D4@public.gmane.org>
2013-03-26 17:02       ` Thomas Petazzoni
2013-03-27  1:53   ` Rob Herring
     [not found] ` <1364316746-8702-1-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2013-03-26 16:52   ` [RFCv1 02/11] irqchip: move IRQ driver for Armada 370/XP Thomas Petazzoni
2013-03-26 16:54     ` Arnd Bergmann
2013-03-26 16:52   ` [RFCv1 03/11] irqchip: armada-370-xp: move IRQ handler to avoid forward declaration Thomas Petazzoni
2013-03-26 16:52   ` [RFCv1 04/11] irqchip: armada-370-xp: slightly cleanup irq controller driver Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 05/11] arm: mvebu: do not duplicate the mpic alias Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 06/11] irqchip: armada-370-xp: use a separate mpic node Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver Thomas Petazzoni
2013-03-26 17:07   ` Arnd Bergmann
2013-03-26 17:17     ` Thomas Petazzoni
2013-03-26 18:38       ` Arnd Bergmann
2013-03-26 20:46         ` Thomas Petazzoni
2013-03-26 21:10           ` Arnd Bergmann [this message]
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
2013-03-26 16:52 ` [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
2013-04-08 22:28   ` Bjorn Helgaas
     [not found]     ` <CAErSpo42AFdKH2RKTxOaeJgCPrYD5KYkOs3UEBez8x8Bjmun5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-09  8:11       ` Andrew Murray
     [not found]         ` <20130409081119.GA30736-5wv7dgnIgG8@public.gmane.org>
2013-04-09  8:22           ` Thierry Reding
2013-04-09  8:25             ` Andrew Murray
2013-04-09  8:18     ` Thierry Reding
2013-03-26 16:52 ` [RFCv1 09/11] pci: mvebu: add MSI support Thomas Petazzoni
     [not found]   ` <1364316746-8702-10-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2013-03-27 10:07     ` Andrew Murray
2013-04-08 22:29   ` Bjorn Helgaas
2013-05-30 12:15     ` Thierry Reding
2013-05-30 18:13       ` Bjorn Helgaas
2013-03-26 16:52 ` [RFCv1 10/11] arm: mvebu: enable MSI support in DT Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 11/11] arm: mvebu: enable PCI MSI support in defconfig Thomas Petazzoni
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
2013-04-04  9:16 ` Ezequiel Garcia
2013-04-04  9:29   ` Thomas Petazzoni

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=201303262110.15582.arnd@arndb.de \
    --to=arnd-r2ngtmty4d4@public.gmane.org \
    --cc=alior-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=andrew-g2DYL2Zd6BY@public.gmane.org \
    --cc=andrew.murray-5wv7dgnIgG8@public.gmane.org \
    --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=maen-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=tawfik-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org \
    --cc=thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.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).