On 25 February 2016 at 01:11, Derek Basehore <dbasehore@xxxxxxxxxxxx> wrote:
> This tries to runtime suspend devices that are still active for direct
> complete. This is for cases such as autosuspend delays which leaves
> devices able to runtime suspend but still active. It's beneficial in
> this case to runtime suspend the device to take advantage of direct
> complete when possible.
Unfortunate this doesn't work. In the device_prepare() phase the PM
core prevents runtime suspend via a call to pm_runtime_get_noresume().
Kind regards
Uffe
>
> Signed-off-by: Derek Basehore <dbasehore@xxxxxxxxxxxx>
> Reviewed-by: Eric Caruso <ejcaruso@xxxxxxxxxxxx>
> ---
> drivers/base/power/main.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index e0017d9..9693032 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1380,7 +1380,12 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
> goto Complete;
>
> if (dev->power.direct_complete) {
> - if (pm_runtime_status_suspended(dev)) {
> + /*
> + * Check if we're runtime suspended. If not, try to runtime
> + * suspend for autosuspend cases.
> + */
> + if (pm_runtime_status_suspended(dev) ||
> + !pm_runtime_suspend(dev)) {
> pm_runtime_disable(dev);
> if (pm_runtime_status_suspended(dev))
> goto Complete;
> --
> 2.7.0.rc3.207.g0ac5344
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
