RE: GPIO/IRQ expander cannot map interrupt

[Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

Thierry Reding wrote at Friday, November 25, 2011 3:45 AM:
> The following is an extract from a device tree of a Tegra2-based board I'm
> working on:
> 
[swarren: Abbreviated the DT during quoting]
> 	i2c@7000c000 {
> 		keypad1: sx8634@2b {
> 			interrupt-parent = <&gpioext>;
> 			interrupts = <2>;
> 		gpioext: gpio-ad8p@41 {
> 			gpio-controller;
> 			#gpio-cells = <2>;
> 			interrupt-controller;
> 			#interrupt-cells = <1>;
> 	i2c@7000c400 {
> 		keypad2: sx8634@2b {
> 			interrupt-parent = <&gpioext>;
> 			interrupts = <3>;
> 
> So basically I have a GPIO/IRQ expander on the first I2C bus (gpioext) to
> which the two keypad (sx8634) chips are connected. They use GPIOs 2 and 3 of
> the expander as interrupts.
> 
> This all seems to work partially: the gpioext is properly detected as parent
> for both keypad controllers during I2C device registration. Within the
> gpio-ad8p driver I register an IRQ domain (using irq_domain_add_simple()) in
> order to allow the OF code to properly map the IRQs for the controller's
> children.
> 
> The problem, however, is that the keypad I2C devices are registered before the
> gpioext device is probed, which results in a situation where the IRQs cannot
> be mapped because the gpioext device hasn't had a chance to register the IRQ
> domain yet.

I believe this is something that the forthcoming "deferred probing"
mechanism will solve. This isn't in place yet. I /think/ it's one of the
things that Grant Likely is working on getting going during his sabattical,
so hopefully there will be some patches you can try out soon.

-- 
nvpublic