On 2/24/2012 3:14 PM, Rob Herring wrote:
On 02/23/2012 04:46 PM, Cousson, Benoit wrote:
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index bc2bd69..afef0f7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -93,6 +93,11 @@ struct gpio_bank {
#define GPIO_BIT(bank, gpio) (1<< GPIO_INDEX(bank, gpio))
#define GPIO_MOD_CTRL_BIT BIT(0)
+static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq)
+{
+ return gpio_irq - bank->irq_base + bank->chip.base;
Ideally, you could do something like this when you have a domain setup:
irq_get_irq_data(gpio_irq)->hw_irq + bank->chip.base
OK, good to know. I still plan to move the current irq_domain basic
support to the irqchip stuff you have done. I'll do that after 3.4.
Also, with sparse irq you need to have a call to irq_alloc_desc.
irq_alloc_desc was already added as part of the DT migration patch.
It was not explicit in the changelog, but that patch is based on GPIO
cleanup + DT migration series.
You can avoid that by setting NR_IRQS or machine .nr_irqs, but that needs to go
away.
Based on a recommendation you did in the commit to fix GIC I did that in
the SPARSE_IRQ series I've just sent before that RFC patch:
+#ifdef CONFIG_SPARSE_IRQ
+#define NR_IRQS NR_IRQS_LEGACY
+#else
#define NR_IRQS OMAP_GPMC_IRQ_END
+#endif
Otherwise, it certainly is a step in the right direction.
Yeah, there is still a long way to clean all the old nasty IRQ stuff in
OMAP :-)
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
