From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
Kevin Hilman <khilman@kernel.org>,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended
Date: Thu, 21 Apr 2016 02:30:11 +0300 [thread overview]
Message-ID: <1747840.aL2QAkXYBh@avalon> (raw)
In-Reply-To: <CAPDyKFqtrdw+MHh6tAz658=PQi+REGAEiNzNs_4aRzTTpOwP9Q@mail.gmail.com>
Hello,
Reviving this old thread.
On Monday 07 Mar 2016 11:10:08 Ulf Hansson wrote:
> [...]
>
> >> I agree, that's a better idea. Drivers shouldn't call
> >> pm_runtime_force_resume() if they haven't called
> >> pm_runtime_force_suspend(), so checking the PM use count should be fine.
> >> I'll modify the patch, test it and resubmit.
> >
> > I gave it an unfortunately unsuccessful try. The problem I ran into is
> > that device_prepare() calls pm_runtime_get_noresume() calls
> > pm_runtime_get_noresume(), with the corresponding pm_runtime_put() call
> > being performed in device_complete(). The device power usage_count is
> > thus always non-zero in the system resume handler, so I can't base the
> > decision on that.
>
> As Alan said, let's just check against 1 instead.
I gave this a try, and unfortunately it won't work.
pm_genpd_prepare() resumes devices without increasing the usage count, which
leads to the device always being active in pm_runtime_force_suspend(). The
usage count will be 1 if the device was suspended prior to entering system
suspend (due to the pm_runtime_get_noresume() call in device_prepare()) or
higher than 1 if the device was active.
However, pm_genpd_prepare() will not resume the device if suspend_power_off is
set. In that case the device will be suspended with a usage count of 1 in
pm_runtime_force_suspend() or active with a usage count higher than 1.
We thus can't detect at resume time whether we have force-suspended the device
using the usage count.
Unless someone has another clever idea I'll keep the power.is_force_suspended
flag and protect it with power.lock.
> > I also noticed that pm_genpd_prepare() runtime-resumes the device (when
> > the power domain is in the GPD_STATE_ACTIVE state). I don't know why that
> > is, but it means that in practice my device gets runtime-resumed when
> > suspending the system while it could stay runtime-suspended in practice.
>
> I am aware of this and it's on my TODO list of improvements of genpd,
> The issue is related to an unoptimized behaviour for how genpd deal
> with wakeups during system PM.
Looking forward to seeing patches :-)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2016-04-20 23:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 20:16 [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended Laurent Pinchart
2016-03-03 20:35 ` Kevin Hilman
2016-03-03 20:44 ` Laurent Pinchart
2016-03-03 20:54 ` Sergei Shtylyov
2016-03-04 10:34 ` Ulf Hansson
2016-03-04 15:24 ` Alan Stern
2016-03-04 15:24 ` Alan Stern
2016-03-04 21:04 ` Laurent Pinchart
2016-03-06 15:38 ` Laurent Pinchart
2016-03-06 16:59 ` Alan Stern
2016-03-06 16:59 ` Alan Stern
2016-03-07 10:10 ` Ulf Hansson
2016-04-20 23:30 ` Laurent Pinchart [this message]
2016-04-21 9:10 ` Ulf Hansson
2016-04-21 12:41 ` Laurent Pinchart
2016-04-21 13:52 ` Ulf Hansson
2016-04-21 15:11 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1747840.aL2QAkXYBh@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=khilman@kernel.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.