PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1

Ulf Hansson ulf.hansson at linaro.org
Wed Feb 3 10:37:31 PST 2016


On 3 February 2016 at 19:28, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
>>
>> One more thing though. I just realized that you have yet another issue
>> to consider going for the approach fixing *only* drivers.
>>
>> Let me summarize it here:
>>
>> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
>> driver becomes unbound, the driver will not be able to suspend the
>> device by using any of the pm_runtime_suspend() APIs, as the usage
>> count is isn't zero.
>>
>> As pm_runtime_reinit() is invoked as part of the driver unbind
>> sequence, the runtime PM status goes out of sync. A following driver
>> rebind will then trigger the warning when the PM domain's
>> ->runtime_resume() callback gets invoked. Again, forever preventing
>> the device from being runtime suspended.
>
> Hmm yeah that's a good point.
>
>> How do you intend to solve this case?
>> I guess there are two options, pick up the patch I posted for omap
>> hwmod or make use of pm_runtime_force_suspend() in the driver.
>
> My gut feeling right now is we should just have
> BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
> automatically as it's unused after the driver has unloaded :)

BUS_NOTIFY_UNBIND_DRIVER is sent prior the ->remove() callbacks is
invoked from driver core.
So if the driver requires to do a pm_runtime_get_sync() during
->remove() callback, this won't work.

BUS_NOTIFY_UNBOUND_DRIVER may work though.

Kind regards
Uffe



More information about the linux-arm-kernel mailing list