GPIO/IRQ expander cannot map interrupt

GPIO/IRQ expander cannot map interrupt

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

Hi,

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

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

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

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

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

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

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

		keypad2: sx8634@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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

RE: GPIO/IRQ expander cannot map interrupt

[Stephen Warren]

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

Re: GPIO/IRQ expander cannot map interrupt

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]

* Stephen Warren wrote:
> 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.

I've seen some patches floating around, but I'm not sure that, in the current
form, deferred probing will solve this issue. Or at least not solve it in the
most efficient way. From what I understand, deferred probing is merely a sort
of hook that allows the driver to specify at probe time that some resources
are still missing and is used for cases where there is no explicit dependency
information and thus the driver core doesn't know in which order devices need
to be probed.

However, for this particular case we actually have this explicit dependency
information because the devices specify an interrupt and/or GPIO parent.
Moreover it's not really the probing that is the issue here, but rather the
device instantiation. The OF core instantiates the I2C slaves much too early
(i.e. together with the interrupt parent) and therefore requires access to
the IRQ domain mapping at the time of the instantiation already.

Using deferred probing in this case would require the driver to repeat the
complete IRQ mapping sequence that is already done when OF populates the
device tree. Perhaps in addition to deferred probing we also need deferred
*instantiation*.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: GPIO/IRQ expander cannot map interrupt

[Mark Brown]

On Tue, Nov 29, 2011 at 07:59:26AM +0100, Thierry Reding wrote:

> of hook that allows the driver to specify at probe time that some resources
> are still missing and is used for cases where there is no explicit dependency
> information and thus the driver core doesn't know in which order devices need
> to be probed.

The intention is to use it at all times and just not bother with
explicit ordering information as this is going to be more robust
especially given the need to sort out things like driver registration
ordering.

> However, for this particular case we actually have this explicit dependency
> information because the devices specify an interrupt and/or GPIO parent.
> Moreover it's not really the probing that is the issue here, but rather the
> device instantiation. The OF core instantiates the I2C slaves much too early
> (i.e. together with the interrupt parent) and therefore requires access to
> the IRQ domain mapping at the time of the instantiation already.

That's a separate issue though.