arm: mvebu: move irq controller driver in drivers/irqchip/

The new support for the ARM BCM2835 SoC has introduced the drivers/irqchip/ directory for IRQ controller drivers. So let's conform to this good new approach, and move the IRQ controller driver for Marvell Armada 370/XP in this directory.

Signed-off-by Thomas Petazzoni <[email protected]>

---

include/linux/irqchip/armada-370-xp.h new file +9 -0

new file mode 100644
index 0000000..78876c2
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2012 Marvell
+ *
+ * Thomas Petazzoni <[email protected]>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */

I don't mean to pick on this specific patch, but this is a common problem of moving various low-level pieces like irqchips, cpuidle, timers, etc. to drivers/*. If we, just moving the code as is over, we still need some hooks between arch/arm and drivers. I think if we keep adding ARM SOC specific headers to include/linux, that will be the next thing we get yelled at for and will have to clean-up.

For irqchips, the way I see this working is we would have a single call to of_irq_init with a match list of all irqchips in drivers/irqchips. This contains the init function within drivers/irqchips. Then all the machines can just call a generic irqchip_init.

The handle_irq ptr would also need to be plugged in at runtime.

Quoted 7 lines · Rob Herring

I don't mean to pick on this specific patch, but this is a common problem of moving various low-level pieces like irqchips, cpuidle, timers, etc. to drivers/*. If we, just moving the code as is over, we still need some hooks between arch/arm and drivers. I think if we keep adding ARM SOC specific headers to include/linux, that will be the next thing we get yelled at for and will have to clean-up.

Quoted 5 lines

For irqchips, the way I see this working is we would have a single call to of_irq_init with a match list of all irqchips in drivers/irqchips. This contains the init function within drivers/irqchips. Then all the machines can just call a generic irqchip_init.

Sounds doable indeed.

Quoted 1 line

The handle_irq ptr would also need to be plugged in at runtime.

However, do you have a more specific idea here? In setup_arch(), the value of mdesc->handle_irq gets picked up way before the ->init_irq machine hook is being called.

Rob,

Quoted 7 lines · Rob Herring

I don't mean to pick on this specific patch, but this is a common problem of moving various low-level pieces like irqchips, cpuidle, timers, etc. to drivers/*. If we, just moving the code as is over, we still need some hooks between arch/arm and drivers. I think if we keep adding ARM SOC specific headers to include/linux, that will be the next thing we get yelled at for and will have to clean-up.

Quoted 5 lines

For irqchips, the way I see this working is we would have a single call to of_irq_init with a match list of all irqchips in drivers/irqchips. This contains the init function within drivers/irqchips. Then all the machines can just call a generic irqchip_init.

Sounds doable indeed.

Quoted 1 line

The handle_irq ptr would also need to be plugged in at runtime.

However, do you have a more specific idea here? In setup_arch(), the value of mdesc->handle_irq gets picked up way before the ->init_irq machine hook is being called.

An option would be to fill this mdesc->handle_irq() field during the mdesc->init_early() callback (would require moving things around a bit in setup_arch(), but sounds reasonable). However, at the time of mdesc->init_early(), I guess we can't call of_irq_init(). So we would have a two step process: fill in mdesc->handle_irq during mdesc->init_early(), and call irqchip_init() (which will do the of_irq_init()) in mdesc->init_irq().

If that's fine with you, I can cook a patch for BCM2835 and MVEBU that implements this idea.