Re: GPIO/IRQ expander cannot map interrupt

[Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

[-- 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 --]