Question about expected behavior when PM runtime is disabled

[Kenneth Heitke <kheitke@codeaurora.org>]

Hi Rafael,

Sorry if this question has been raised before.  I actually have two 
questions here.  These questions are related to PM runtime being 
disabled at runtime (i.e. call to pm_runtime_disable() )

If I call pm_runtime_enabled() to first determine if PM runtime is 
enabled followed conditionally by a call to pm_runtime_get_sync(), it 
would be possible for PM runtime to be disabled between these two calls 
and the get_sync() will fail.  Is there any reason to even use the 
enabled() call?  My goal here was to use the enabled() call to determine 
if PM runtime was configured/enabled in the kernel and then to manage my 
resources, clocks etc, in a different way if PM runtime is not present.

My second question then is what if PM runtime is enabled in the kernel 
and then gets disabled at runtime.  What is the expected behavior for a 
driver?  Should it fail all requests with EGAIN until PM runtime is 
enabled again? (in suspend state, PM runtime gets disable, new i/o 
request is made, power and clocks need to be turned on).

What about delayed autosuspend?  I believe that if PM runtime is 
disabled while there is a delayed autosuspend pending, the suspend will 
fail without notification (clocks and power will be left on).  Will PM 
runtime still be in the idle state once PM runtime is re-enabled?

thanks,
Ken


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.