GPIO/IRQ expander cannot map interrupt

Thierry Reding thierry.reding at avionic-design.de
Fri Nov 25 21:45:11 EST 2011


Hi,

The following is an extract from a device tree of a Tegra2-based board I'm
working on:

	i2c at 7000c000 {
		clock-frequency = <400000>;

		keypad1: sx8634 at 2b {
			compatible = "sx8634";
			reg = <0x2b>;
			interrupt-parent = <&gpioext>;
			interrupts = <2>;
		};

		gpioext: gpio-ad8p at 41 {
			compatible = "gpio-ad8p";
			reg = <0x41>;
			interrupts = <320>; /* gpio PU0 */

			gpio-controller;
			#gpio-cells = <2>;

			interrupt-controller;
			#interrupt-cells = <1>;
		};
	};

	i2c at 7000c400 {
		clock-frequency = <400000>;

		keypad2: sx8634 at 2b {
			compatible = "sx8634";
			reg = <0x2b>;
			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.

Is there anything I can do to make this work? Perhaps the OF code needs to be
patched to ensure that devices which have the gpio-/interrupt-controller
properties are always probed before other devices are registered?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20111125/37f5ee08/attachment.pgp>


More information about the devicetree-discuss mailing list