On Mon, Jun 20, 2011 at 2:45 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Mon, Jun 20, 2011 at 09:48:15AM +0200, David Jander wrote: >> On Sat, 18 Jun 2011 09:16:45 -0600 >> Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: >> >> > 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: >> > > > On Sat, Jun 18, 2011 at 4:17 AM, Dmitry Torokhov >> > > > <dmitry.torokhov@xxxxxxxxx> wrote: >> > > > > On Thu, Jun 16, 2011 at 01:27:32PM -0600, Grant Likely wrote: >> > > > >> On Tue, Jun 14, 2011 at 11:08:11AM +0200, David Jander wrote: >> > > > >> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
