From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] Introduce irqchip infrastructure
Date: Tue, 20 Nov 2012 16:38:20 -0600 [thread overview]
Message-ID: <50AC065C.7000305@gmail.com> (raw)
In-Reply-To: <1353448867-15008-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 11/20/2012 04:00 PM, Thomas Petazzoni wrote:
> Hello,
>
> Here is a set of patches that introduces a small irqchip
> infrastructure that allows the registration of irqchip drivers without
> having each of those drivers to expose a public API and header in
> include/linux/irqchip/, and moves a number of existing irqchip
> controller to this infrastructure.
>
> This new version (detailed changelog below) provides a number of
> improvements: usage of a special link section to avoid the central
> registration in irqchip.{c,h} of all irqchip drivers, and addition of
> the GIC, VIC and Versatile FPGA IRQ drivers move, thanks to Rob
> Herring and Linus Walleij.
>
> Remaining issues to solve:
>
> * Russell would like arch/arm/include/asm/hardware/vic.h and
> arch/arm/include/asm/hardware/gic.h to move elsewhere, since the
> corresponding code is no longer in arch/arm/. I can move them in
> <linux/irqchip>, but that will cause a fairly large change as there
> are a big number of users of those headers in arch/arm.
We need to do this. KVM will need the header as well, so we can't move
the register definitions out either.
> * The arch/arm/include/asm/hardware/vic.h has a few offset macros
> that should move into the .c file of the irqchip driver, but some
> of those offsets are bizarrely used in some other pieces of code in
> arch/arm/.
Not really a good solution that I can see there. We could punt on doing
the VIC for now.
>
> * How to get rid entirely of the headers in <linux/irqchip/>. The
> remaining problematic functions are <foo>_handle_irq() and
> <foo>_irq_init() that are used by non-DT platforms. And the special
> case of gic_cascade_irq().
I have patches for removing vic/gic_handle_irq. It is going to take a
while for the others, so I don't think we should wait for that. KVM
needs the GIC header anyway.
> * Move all the users of gic_of_init() to the irqchip mechanism
> (Exynos, i.MX 6, MSM, OMAP, SH Mobile, socfpga, spear13xx, tegra,
> ux500, vexpress) so that gic_of_init() no longer has to be
> exported.
I have a patch doing this. I will try to get this sent out today. I've
split this into clean-up and then the move, so the clean-up could go in
for 3.8. It is only dependent on patch 2.
> Of course, I don't expect any of this to go in 3.8, it is 3.9 material
> if we manage to reach a consensus on the remaining issues to solve
> (and the other issues that will certainly show up or be raised by
> other people).
I still would like to try to get this in for 3.8. If not the move, some
of the clean-up.
Rob
>
> This series has been built and boot tested for BCM2835 and Armada
> XP. It has been built tested on Versatile with OF and without OF,
> spear3xx, spear6xx and a multi_v6_v7 configuration with all possible
> architectures enabled (therefore including picoxcell).
>
> Changes since v3:
>
> * Switch to a link-trick based registration of the irqchip drivers,
> using the IRQCHIP_DECLARE() macro.
>
> * Integrate Rob Herring's patches to move the GIC and VIC irq
> controller drivers in drivers/irqchip/.
>
> * Migrate picoxcell, spear3xx and spear6xx to using the irqchip
> platform, so that no direct user of vic_of_init() remains.
>
> * Don't export vic_of_init() anymore: all users go through
> irqchip_init() now.
>
> * Integrate Linus Walleij patch that moves the Versatile FPGA irq
> controller driver to drivers/irqchip.
>
> * A set_handle_irq() ARM function was added to properly set the
> handle_arch_irq pointer to the right handler of the parent IRQ
> controller.
>
> Changes since v2:
>
> * Fixed the entry in the MAINTAINERS file. Noticed by Rob Herring.
>
> * Simplified the Kconfig logic by making the IRQCHIP option enabled
> by default as soon as OF_IRQ is enabled. The individual ARCH_<foo>
> Kconfig options no longer have to select IRQCHIP. Also, the option
> was renamed from USE_IRQCHIP to just IRQCHIP. Suggested by Rob
> Herring.
>
> * Added Reviewed-by tags given by Rob Herring.
>
> Changes since v1:
>
> * Add a new patch mentionning the drivers/irqchip in the list of
> directories part of the IRQ subsystem maintained by Thomas Gleixner
> in the MAINTAINERS file. Requested by Arnd Bergmann.
>
> * Reduce the amount of code movement in the irq-bcm2835.c and
> irq-armada-370-xp.c files by using one forward declaration for the
> IRQ handling entry point. Requested by Stephen Warren.
>
> * Rename the armctrl_of_init() function to bcm2835_irqchip_init() as
> requested by Stephen Warren.
>
> * Added the formal Acked-by and Reviewed-by received from Stephen
> Warren.
>
> Thanks,
>
> Thomas
>
next prev parent reply other threads:[~2012-11-20 22:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-20 22:00 [PATCH v4] Introduce irqchip infrastructure Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 01/16] irqchip: add basic infrastructure Thomas Petazzoni
2012-11-20 22:40 ` Stephen Warren
2012-11-20 22:54 ` Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 02/16] arm: add set_handle_irq() to register the parent IRQ controller handler function Thomas Petazzoni
2012-11-20 23:42 ` Rob Herring
2012-11-20 22:00 ` [PATCH 03/16] arm: bcm2835: convert to the irqchip infrastructure Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 04/16] arm: mvebu: move irq controller driver to drivers/irqchip Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 05/16] irqchip: add to the directories part of the IRQ subsystem in MAINTAINERS Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 06/16] ARM: gic: move register definitions into .c file Thomas Petazzoni
2012-11-20 23:35 ` Rob Herring
2012-11-20 22:00 ` [PATCH 07/16] ARM: gic: remove direct use of gic_raise_softirq Thomas Petazzoni
2012-11-20 22:00 ` [PATCH 08/16] irqchip: Move ARM GIC to drivers/irqchip Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 09/16] irqchip: Move ARM VIC " Thomas Petazzoni
2012-11-23 12:01 ` Jamie Iles
2012-11-20 22:01 ` [PATCH 10/16] ARM: highbank: use common irqchip_init Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 11/16] ARM: picoxcell: " Thomas Petazzoni
2012-11-23 12:04 ` Jamie Iles
2012-11-20 22:01 ` [PATCH 12/16] ARM: spear3xx: " Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 13/16] ARM: spear6xx: " Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 14/16] arm: vic: don't expose vic_of_init() anymore Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 15/16] irqchip: vic: mark vic_of_init() as static Thomas Petazzoni
2012-11-21 12:40 ` Linus Walleij
2012-11-21 12:53 ` Thomas Petazzoni
2012-11-21 14:40 ` Linus Walleij
2012-11-21 14:46 ` Thomas Petazzoni
2012-11-21 15:07 ` Rob Herring
2012-11-21 15:20 ` Thomas Petazzoni
2012-11-20 22:01 ` [PATCH 16/16] ARM: plat-versatile: move FPGA irq driver to drivers/irqchip Thomas Petazzoni
2012-11-21 12:22 ` Linus Walleij
2012-11-21 12:47 ` Thomas Petazzoni
2012-11-20 22:38 ` Rob Herring [this message]
2012-11-20 23:12 ` [PATCH v4] Introduce irqchip infrastructure Thomas Petazzoni
2012-11-21 4:00 ` Rob Herring
2012-11-29 20:27 ` Grant Likely
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=50AC065C.7000305@gmail.com \
--to=robherring2@gmail.com \
--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).