Re: [PATCH v4 3/3] Input: gpio_keys.c: Enable use with non-local GPIO chips.

On Sat, Jun 18, 2011 at 07:51:54AM -0700, Dmitry Torokhov wrote:

On Sat, Jun 18, 2011 at 07:18:28AM -0600, Grant Likely wrote:

quoted

On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Thu, Jun 16, 2011 at 01:27:32PM -0600, Grant Likely wrote:

quoted

On Tue, Jun 14, 2011 at 11:08:11AM +0200, David Jander wrote:

quoted

Use a threaded interrupt handler in order to permit the handler to use
a GPIO driver that causes things like I2C transactions being done inside
the handler context.
Also, gpio_keys_init needs to be declared as a late_initcall, to make sure
all needed GPIO drivers have been loaded if the drivers are built into the
kernel.

...which is a horrid hack, but until device dependencies can be
described, it isn't one that can be solved easily.

I really do not want to apply this... Currently the order of
initialization does not matter since nothing actually happens until
corresponding device appears on the bus. Does the OF code creates
devices before all resources are ready?

It's not an OF problem.  The problem is that all the platform_devices
typically get registered all at once at machine_init time (on arm),
and if the gpio expander isn't a platform_device, (like an i2c gpio
expander which would end up being a child of a platform_device), then
it won't be ready.

Ah, I see. But that can be handled in board code that should ensure that
it registers devices in correct order.

Unfortunately, handling it in board code doesn't really work either.
It just shuffles the complexity to the board code to implement some
kind of deferred mechanism for registering devices, and it has to take
into account that it may be a long time before the device actually
appears, such as when the driver is configured as a module.

I completely agree that shuffling initcall order isn't maintainable
though.

A related concern is that changing the device registration order, or
the initcall order, does absolutely nothing to tell runtime PM about
the dependencies between devices.  For instance, how does runtime PM
know when it is safe to PM a gpio controller, when it has no reference
to devices depending on it, like gpio-keys?  (although gpio-keys isn't
a great example because it doesn't really have any runtime PM states).

I think part of the solution is to give drivers the option of
returning a 'defer' code at probe time if it cannot obtain all it's
resources, and have the driver core re-probe it when more devices
become available, but I haven't had time to prototype it yet.

g.

quoted

 The real problem is that we have no mechanism for
holding off or deferring a driver probe if it depends on an
asynchronous resource.

The mechanism we do have - we should not be creating the device for the
driver to bind to unless all resources that are needed by that device
are ready.

Just shuffling the initcall order is not maintanable. Next there will be
GPIO expander that is for some reason registered as late_initcall and
we'll be back to square one. I am going to take the threaded IRQ bit but
will drop the initcall bit from the patch.

Thanks.

-- 
Dmitry