Re: How to create IRQ mappings in a GPIO driver that doesn't control its IRQ domain ?
From: Grant Likely
Date: Thu Jul 25 2013 - 00:17:00 EST
On Wed, 24 Jul 2013 01:21:44 +0200, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
> I'm running into an issue on several Renesas SoC with IRQ domains and GPIOs.
> On sh73a0, r8a73a4 and r8a7740, GPIOs and external interrupts are handled by
> two separate IP cores, namely the PFC (Pin Function Controller) and INTC
> (Interrupt Controller). The former is handled by the sh-pfc driver
> (drivers/pinctrl/sh-pfc) and the later by the irq-renesas-intc-irqpin driver
> (drivers/irqchip), referred to below as the irqpin driver.
> The sh73a0, for instance, has 32 external interrupt lines that are multiplexed
> on pins usable as GPIOs. Both the GPIO and external interrupt functions are
> usable at the same time, which allows reading the state of the interrupt
> These external interrupts are for MMC/SD support, among other devices. In this
> specific case the MMC/SD Card Detect signal is wired to one of the external
> interrupt signals, and the corresponding GPIO is passed to the MMC/SD
> controller driver. Depending on other configuration parameters the driver can
> then either poll the Card Detect signal, or register an interrupt handler to
> detect changes in the signal state. This features is implemented by the MMC/SD
> core, which call gpio_to_irq() on the GPIO to retrieve the corresponding IRQ
> On non-DT systems the external IRQs are statically mapped at a known offset.
> The sh-pfc driver, to implement the gpio_to_irq() function (through its
> gpiochip .to_irq() handler), simply searches a SoC-specific lookup table for
> the fixed IRQ number associated with a given GPIO.
> However, on DT systems, IRQs are mapped dynamically on demand. The irqpin
> driver registers a simple IRQ domain, and the irq_create_mapping() function
> can then be used to map a given IRQ, specified as an offset in the domain.
> This is where the problem appears, as the irqchip .to_irq() function is
> implemented in the sh-pfc driver, which doesn't have access to the IRQ domain
> registered by the irqpin driver.
> I could hack around this by exporting a function in the irqpin driver that
> would map an IRQ, and call that function from the sh-pfc driver. I'd rather
> avoid that solution as it would add a direct dependency between the two
Well, the gpio controller really does need to know what irq is
associated with a GPIO line. If the gpio controller driver doesn't have
direct access to that information, then it needs to have a hook to set
In the past, I've seen gpio controllers have an interrupts property
specifying which interrupts it is connected to and can use for GPIO
events. That seems like a resonable scenario in this regard, but if
GPIOS are 1:1 mapped to irqs, then it means a lot of interrupt entries
need to appear in the GPIO node. The other option is to add a hook
directly to the gpio driver so that it knows to use a specific irq
controller; but that feels wrong. Thought it may be a bit verbose, the
addition of an interrupts property to the GPIO controller node is
probably what is wanted.
There has also been a trend to make gpio controllers also interrupt
controllers if they support being used directly as irq inputs, but that
doesn't really help your problem. :-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/