Requesting a GPIO that hasn't been registered yet

Requesting a GPIO that hasn't been registered yet

[Bill Gatliff]

Guys:


I'm sure this is a FAQ, but I can't seem to find the answer.  I'm happy
to RTFM, if someone can please tell me where the FM is.  :)

I'm adding device table support to gpio_keys.  The target is an
MPC5200B.  I have statements in my dts file that look like this:

...
        i2c@3d40 {
            #address-cells = <1>;
            #size-cells = <0>;
            compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
            reg = <0x3d40 0x40>;
            interrupts = <2 16 0>;
...
            lext60: max7314@60 {
                compatible = "maxim,max7314","phillips,pca953x";
                reg = <0x60>;
                gpio-controller;
                #gpio-cells = <2>;
            };
        };
...
        gpio-keys {
              compatible = "gpio-keys";
              encoder_button {
                     gpios = <&lext60 12 0>;
                     code = <28>;
                     type = <1>;
                     active-low = <0>;
                     wakeup = <0>;
                     debounce-interval = <0>;
                     rep = <0>;
                     };
             };

In other words, the GPIO pin I'm using for the key is one of the bits on
my pca953x GPIO expander chip.

The above would all be great, except that I haven't come up with a way
to make sure that my encoder_button doesn't try to probe before lext60
is available.  In fact, I'm consistently getting initialization in the
wrong order!

Eventually the GPIO expander chip gets plugged in, because I can see it
show up in sysfs.  And what's really odd is, I recently made similar
mods to gpio_leds and they are working fine--- although the GPIO pin is
on a pca953x at address 20, instead of 60.  I'm at a loss to explain why
one works, but the other doesn't.  And I don't know how to really fix
this problem for good!

Any suggestions?  Thanks!!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Requesting a GPIO that hasn't been registered yet

[Anton Vorontsov]

On Tue, Mar 30, 2010 at 10:05:01PM -0500, Bill Gatliff wrote:
[...]
> In other words, the GPIO pin I'm using for the key is one of the bits on
> my pca953x GPIO expander chip.
> 
> The above would all be great, except that I haven't come up with a way
> to make sure that my encoder_button doesn't try to probe before lext60
> is available.  In fact, I'm consistently getting initialization in the
> wrong order!
> 
> Eventually the GPIO expander chip gets plugged in, because I can see it
> show up in sysfs.  And what's really odd is, I recently made similar
> mods to gpio_leds and they are working fine--- although the GPIO pin is
> on a pca953x at address 20, instead of 60.  I'm at a loss to explain why
> one works, but the other doesn't.  And I don't know how to really fix
> this problem for good!

That's because of drivers/Makefile:

obj-$(CONFIG_INPUT)             += input/
...
obj-y                           += i2c/ media/
...
obj-$(CONFIG_NEW_LEDS)          += leds/

So, all these drivers use module_init(), which means that the
order of execution depends on link order. To fix probing you need
to move i2c/ above input/:

diff --git a/drivers/Makefile b/drivers/Makefile
index 34f1e10..d31bb52 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,12 +67,12 @@ obj-$(CONFIG_USB)		+= usb/
 obj-$(CONFIG_USB_MUSB_HDRC)	+= usb/musb/
 obj-$(CONFIG_PCI)		+= usb/
 obj-$(CONFIG_USB_GADGET)	+= usb/gadget/
+obj-y				+= i2c/ media/
 obj-$(CONFIG_SERIO)		+= input/serio/
 obj-$(CONFIG_GAMEPORT)		+= input/gameport/
 obj-$(CONFIG_INPUT)		+= input/
 obj-$(CONFIG_I2O)		+= message/
 obj-$(CONFIG_RTC_LIB)		+= rtc/
-obj-y				+= i2c/ media/
 obj-$(CONFIG_PPS)		+= pps/
 obj-$(CONFIG_W1)		+= w1/
 obj-$(CONFIG_POWER_SUPPLY)	+= power/