Thread (35 messages) 35 messages, 6 authors, 2012-11-29
STALE4938d

[PATCH v4] Introduce irqchip infrastructure

From: Rob Herring <hidden>
Date: 2012-11-21 04:00:13

On 11/20/2012 05:12 PM, Thomas Petazzoni wrote:
Rob,

On Tue, 20 Nov 2012 16:38:20 -0600, Rob Herring wrote:
quoted
quoted
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.
Which register definitions are you talking about? The one from vic.h ?
quoted
quoted
 * 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.
Well, most of the VIC macro users are strange. Most of them probably
need their own macro definition instead of shamelessly borrowing the
VIC definitions.
quoted
quoted
 * 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.
What is your approach to remove vic/gic_handle_irq? I'll see in your
patches I guess.

That said, I think that having <linux/irqchip/gic.h> and
<linux/irqchip/vic.h> for now is not a big problem. What we want to
avoid is to have gazillions of headers here, but as new platforms are
DT-capable, those platforms shouldn't need to add a header in
<linux/irqchip/>, so I think we could live with
<linux/irqchip/{gic,vic}.h> for a while, and progressively clean
up/improve what needs to be done. Doing the perfect migration as an
unique step is going to be difficult.
quoted
quoted
 * 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.
I've pushed out patches that moves gic.h and converts all GIC DT
platforms over to irqchip_init:

git://sources.calxeda.com/kernel/linux.git gic-irqchip

I haven't gotten to rebasing the VIC ones yet.

One issue I found is it would be easier to move things if
IRQCHIP_DECLARE was accessible in arch/arm. Then I can convert all the
init over to irqchip_init first and then move gic.c and gic.h together
in one patch.

Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help