From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Thierry Reding <thierry.reding@avionic-design.de>,
Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
Jason Cooper <jason@lakedaemon.net>,
Maen Suleiman <maen@marvell.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/8] irqchip: armada-370-xp: implement MSI support
Date: Tue, 18 Jun 2013 10:42:18 +0200 [thread overview]
Message-ID: <20130618104218.7917f927@skate> (raw)
In-Reply-To: <20130611133745.514CA3E0A90@localhost>
Dear Grant Likely,
On Tue, 11 Jun 2013 14:37:45 +0100, Grant Likely wrote:
> > +static int armada_370_xp_setup_msi_irq(struct msi_chip *chip,
> > + struct pci_dev *pdev,
> > + struct msi_desc *desc)
> > +{
> > + struct msi_msg msg;
> > + int hwirq, irq;
> > +
> > + hwirq = armada_370_xp_alloc_msi();
> > + if (hwirq < 0)
> > + return hwirq;
> > +
> > + irq = irq_create_mapping(armada_370_xp_msi_domain, hwirq);
> > + if (!irq) {
> > + armada_370_xp_free_msi(hwirq);
> > + return -EINVAL;
> > + }
>
> This looks like something that the irq_domain should handle for you.
> It would be good to have a variant of irq_create_mapping() that keeps
> track of available hwirqs, allocates a free one, and maps it all with
> one function call. I can see that being useful by other MSI interrupt
> controllers and would eliminate needing to open-code it above.
>
> take a look at the irqdomain/test branch on git://git.secretlab.ca/git/linux
>
> I'm hoping to push that series into v3.11 and it simplifies the
> irq_domain code quite a bit. It would be easy to build an
> irq_create_mapping() variant on top of that. Take a look at
> irq_create_direct_mapping() for inspiration (although that function does
> it the other way around. It allocates a virq and uses that number for
> the hwirq number)
Ok, I've implemented something according to your idea. Will be part of
the v3 of this series. For reference, the piece of code I've added in
irqdomain.c looks like:
/**
+ * irq_alloc_mapping() - Allocate an irq for mapping
+ * @domain: domain to allocate the irq for or NULL for default domain
+ * @hwirq: reference to the returned hwirq
+ *
+ * This routine are used for irq controllers which can choose the
+ * hardware interrupt number from a range [ 0 ; domain size ], such as
+ * is often the case with PCI MSI controllers. The function will
+ * returned the allocated hwirq number in the hwirq pointer, and the
+ * corresponding virq number as the return value.
+ */
+unsigned int irq_alloc_mapping(struct irq_domain *domain,
+ irq_hw_number_t *out_hwirq)
+{
+ unsigned int virq;
+ irq_hw_number_t hwirq;
+
+ pr_debug("irq_alloc_mapping(0x%p)\n", domain);
+
+ if (domain == NULL)
+ domain = irq_default_domain;
+
+ for (hwirq = 0; hwirq < domain->hwirq_max; hwirq++)
+ if (!irq_find_mapping(domain, hwirq))
+ break;
+
+ if (hwirq == domain->hwirq_max) {
+ pr_debug("-> no available hwirq found\n");
+ return 0;
+ }
+
+ virq = irq_alloc_desc_from(1, of_node_to_nid(domain->of_node));
+ if (virq <= 0) {
+ pr_debug("-> virq allocation failed\n");
+ return 0;
+ }
+
+ if (irq_domain_associate(domain, virq, hwirq)) {
+ irq_free_desc(virq);
+ return 0;
+ }
+
+ pr_debug("irq %lu on domain %s mapped to virtual irq %u\n",
+ hwirq, of_node_full_name(domain->of_node), virq);
+
+ *out_hwirq = hwirq;
+
+ return virq;
+}
+EXPORT_SYMBOL_GPL(irq_alloc_mapping);
+
+/**
> > +static int armada_370_xp_msi_init(struct device_node *node)
> > +{
> > + struct msi_chip *msi_chip;
> > + u32 reg;
> > +
> > + msi_chip = kzalloc(sizeof(*msi_chip), GFP_KERNEL);
>
> devm_kzalloc() so it gets freed on failure or unbind; although for this
> device you may not care.
Unfortunately, we don't have access to a platform_device by the time
the IRQ controller driver is initialized. Thierry Redding suggested to
use of_find_device_by_node(), but it returns NULL. I guess it's because
this IRQ controller driver is initialized much before the
platform_device structures are created.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-06-18 8:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 16:41 [PATCH v2 0/8] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 1/8] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
2013-06-18 22:46 ` Bjorn Helgaas
2013-06-19 11:42 ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 2/8] PCI: Add registry of MSI chips Thomas Petazzoni
2013-06-12 10:33 ` Thierry Reding
2013-06-18 22:48 ` Bjorn Helgaas
2013-06-19 11:42 ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 3/8] irqchip: armada-370-xp: properly request resources Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 4/8] irqchip: armada-370-xp: implement MSI support Thomas Petazzoni
2013-06-11 13:37 ` Grant Likely
2013-06-18 8:42 ` Thomas Petazzoni [this message]
2013-06-18 10:15 ` Grant Likely
2013-06-18 10:36 ` Thomas Petazzoni
2013-06-12 10:42 ` Thierry Reding
2013-06-18 8:43 ` Thomas Petazzoni
2013-06-18 11:26 ` Thierry Reding
2013-06-18 12:11 ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 5/8] arm: mvebu: the MPIC now provides MSI controller features Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 6/8] pci: mvebu: add support for MSI Thomas Petazzoni
2013-06-18 22:57 ` Bjorn Helgaas
2013-06-06 16:41 ` [PATCH v2 7/8] arm: mvebu: indicate that this platform supports MSI Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 8/8] arm: mvebu: link PCIe controllers to the MSI controller Thomas Petazzoni
2013-06-06 17:17 ` [PATCH v2 0/8] MSI support for Marvell EBU PCIe driver Jason Cooper
2013-06-07 8:14 ` Thomas Petazzoni
2013-06-07 14:47 ` Jason Cooper
2013-06-06 18:51 ` Jason Cooper
2013-06-07 8:23 ` Thomas Petazzoni
2013-06-07 15:08 ` Jason Cooper
2013-06-07 17:00 ` Thomas Petazzoni
2013-06-18 8:56 ` 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=20130618104218.7917f927@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=grant.likely@secretlab.ca \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=maen@marvell.com \
--cc=thierry.reding@avionic-design.de \
/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).