On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote: > * Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> [111212 15:13]: > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote: > > > > > > Might be worth checking if some board specific __initcall helps here > > > too? > > > > If I only knew how I could insert a board specific __initcall between > > two points from where the generic-gpio first, then the 8250 driver, are > > called. > > > > Any hints? > > Hmm, can't you do all that in the order you want in > ams_delta_modem_init()? Or make that into a late_initcall so > you have generic-gpio available? > > It seems that the pieces of code you're talking about don't need > to be initialized early, just needs to be done in the right > order to get things working. Hi, I'm almost done with moving registration of all latch dependent devices down to a late_initcall hook, however while working on this, I've found still another arrangement, yet better in my opinion: 1) generic-gpio driver registration moved from device_initcall up to subsys_initcall, 2) latch dependent device registration left at arch_initcall, as it is now, 3) a temporary hack, removed with the last patch in the series, that requests GPIO pins on behalf of device drivers before those are updated, placed between subsys_initcall and device_initcall, i.e., at fs_initcall or rootfs_initcall; both look ugly, but this is only for a while, in order to keep things working while in the transition, 4) the modem init hook, once updated with extra GPIO setup that must be done on behalf of the 8250 driver, which is not prepared for accepting any extra init hooks passed with the device platform data, moved down to late_initcall, as suggested, 5) once all drivers are updated, the hack is removed, and an initialization of unused pins added to that late_initcall modem hook, perhaps renamed in order to not suggest it is still modem only related. What do you think? Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
