On Wed, Jul 27, 2011 at 05:14:58PM +0530, DebBarma, Tarun Kanti wrote: ... > > omap_gpio_mod_init calls mpuio_init calls platform_driver_register > > which can't be called in an IRQs off and spinlocked atomic context, ... > I have isolated mpuio_init() from omap_gpio_mod_init(). > mpuio_init() is now called once in omap_gpio_probe().
Looking at omap_gpio_mod_init() it seems like much of its processing could probably be done once at probe time (or at pm_runtime_get_sync time) as well, namely setting the IRQ enable masks. Ungating the interface clock, enabling wakeup, setting smart idle for the module, and enabling the (old-style) system clock seem like either one-time actions at probe, or a part of the pm_runtime_get_sync callback. Or is there some other reason these power management actions should be taken each time a GPIO is requested in the block (when none were previously requested), after the runtime PM get_sync callback, but not as part of the get_sync callback? If so, what caused the smart idle setting to be lost, or the interface clock gated, if not the pm_runtime_put_sync? Todd > > The omap_gpio_mod_init may be unbalanced with the code performed below > > on last free of a GPIO for the bank? If all GPIOs are freed and then > > a new GPIO used, does omap_gpio_mod_init do the right thing? Need a > > separate flag to indicate whether one-time init has ever been > > performed, vs. needing runtime PM enable/disable? > With the above changes I am seeing omap_gpio_mod_init() is balanced. > Let me know if I am still missing something. > -- > Tarun -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
