Re: [PATCH v4 3/3] Input: gpio_keys.c: Enable use with non-local GPIO chips.
From: Grant Likely <hidden>
Date: 2011-06-20 18:13:58
On Mon, Jun 20, 2011 at 2:45 AM, Dmitry Torokhov [off-list ref] wrote:
On Mon, Jun 20, 2011 at 09:48:15AM +0200, David Jander wrote:quoted
On Sat, 18 Jun 2011 09:16:45 -0600 Grant Likely [off-list ref] wrote:quoted
On Sat, Jun 18, 2011 at 07:51:54AM -0700, Dmitry Torokhov wrote:quoted
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.Besides... we don't want anymore board-code, do we? I mean, if a board can use a generic board configuration and specify all it needs in the device-tree, why should something as trivial as connecting a gpio_keys device to a I2C GPIO expander force us to do special board setup all of a sudden? IMHO specifying I2C-gpios to be used for gpio_keys should "just work", even if declared in a device-tree.This is a laudable goal, but then device-tree needs to be able to express device dependencies better. Until then board-specific code is needed to register devices in proper order.
Do: $ git grep _initcall drivers/gpio and $ git grep module_init drivers/gpio I curse and hold my nose every time I have to apply one of those initcall patches, but I have to anyway since there isn't even a good way in board-specific code to control the device registration order. Everything gets registered at machine_init time, and the /order/ that things get registered has barely any effect. It all ends up hanging on the initcall order. The only way for board code to have a meaningful impact on initialization order is to wait for a driver to get probed on a prerequisite device, probably by using a notifier, and then register the device at that point. As far as I can tell, no board code does that. As ugly as fiddling with initcall levels is, it has been sufficient up to this point for existing (non-DT) board ports. g. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html