On 23 October 2013 12:11, Tomi Valkeinen <[email protected]> wrote: > Hi, > > I was debugging why clocks were left enabled after removing omapdss > driver, and I found this commit: > > fa180eb448fa263cf18dd930143b515d27d70d7b (PM / Runtime: Idle devices > asynchronously after probe|release) > > I don't understand how that is supposed to work. > > When a driver is removed, instead of using pm_runtime_put_sync() the > commit uses pm_runtime_put(), so the runtime_suspend call is queued. But > who is going to handle the queued suspend call, as the driver is already > removed? At least in my case, obviously nobody, as I only get > runtime_resume call in my driver, never the runtime_suspend. > > Is there something I need to add to my driver to make this work, or > should that part of the patch be reverted?
I believe it is quite common that a device driver calls pm_runtime_get_sync as a part of it's remove callback, then it explicitly returns it's resources that has been fetched during probe. Like a clk_disable_unprepare for example. The idea behind the change in __device_release_driver, was to try to prevent devices from going active->idle->active and instead just remain active (if possible). In your case, which seems like a more modern way of implementing "remove", you shall call "pm_runtime_suspend" to make sure the runtime_suspend callbacks gets called. Kind regards Ulf Hansson > > Tomi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
