[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FA3CCAF.3020902@ti.com>
Date: Fri, 04 May 2012 15:33:51 +0300
From: Peter Ujfalusi <peter.ujfalusi@...com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC: Samuel Ortiz <sameo@...ux.intel.com>, linux-kernel@...r.kernel.org,
Misael Lopez Cruz <misael.lopez@...com>,
Benoit Cousson <b-cousson@...com>,
devicetree-discuss@...ts.ozlabs.org, Liam Girdwood <lrg@...com>
Subject: Re: [PATCH 2/3] MFD: twl6040: Allocate IRQ numbers dynamically
On 05/04/2012 03:17 PM, Mark Brown wrote:
>> You mean on devices like twl6040, twl6030, twl4030 (I2C MFD devices)?
>> Or "irq expander" type of devices?
>
> The latter, and also just any driver that delivers an interrupt via a
> GPIO on OMAP - if the GPIO IRQ numbers are all dynamically allocated
> then it gets hard to register an off-chip device and tell it which
> interrupt to request.
For GPIO IRQ there's the gpio_to_irq() call which returns the mapped IRQ
number for the given GPIO.
If there is "irq expander" type of chip I assume it would have similar
way to get the IRQ number based on either GPIO number or some other
enumeration value.
The twl6040 does not have such a feature. The interrupts are generated
internally and it has one IRQ line towards the host. We have nested
interrupts for the childs (plug detect is handled by ASoC codec, Vibra
overcurrent is handled by the vibra driver, etc).
Client drivers got their interrupts via platform_get_irq(); they does
not need to know anything about irq_base, or where the IRQ number has
been mapped.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists