[RFC PATCH] gpio/omap: Fix IRQ handling for SPARSE_IRQ

[Cousson, Benoit]

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