From: Lan Tianyu <tianyu.lan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: lenb@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Lan Tianyu <lantianyu1986@gmail.com>,
Aaron Lu <aaron.lu@intel.com>
Subject: Re: [PATCH] ACPI/Power: Check physical device's runtime pm status before requesting to resume it
Date: Fri, 18 Oct 2013 21:05:13 +0800 [thread overview]
Message-ID: <52613209.3000104@intel.com> (raw)
In-Reply-To: <4249062.PmvqKh0Nrz@vostro.rjw.lan>
On 10/17/2013 07:38 PM, Rafael J. Wysocki wrote:
>>>>>>> Unfortunately, I don't see how we can fix this race in a
>>>>>>> satisfactory way and I'm starting to think that the whole
>>>>>>> resuming of dependent devices may be a bad idea.
>>>>>>>
>>>>>>> IIRC, the original concern was that devices may end up in
>>>>>>> D0-uninitialized if we don't do that, but then whoever
>>>>>>> turned the power resource on will probably turn if off at
>>>>>>> one point anyway, so they will be in that state
>>>>>>> temporarily. In other words, in addition to the fact
>>>>>>> that this is racy, there even is no reason to do it.
>>>>>>>
>>>>>>> I'll send a patch to rip off that stuff later today.
>>>
>>> Currently, dropping it should be the better choice but I think we
>>> still need to resolve the D0-uninitialized problem, right?
> Why do you think it is a problem in the first place? Those devices
> will not be accessed while in that state (unless there's a bug
> somewhere).
>
Yes, those devices will not be accessed but they will continue to stay
D0-uninitiallized without any users before next resume and suspend. PM
core and device driver still think they are in the lower power state.
At this point, it seems these devices should be put into lower power
state(E.G D3hot) than D0-uninitiallized.
E.G, two devices share one power resource. After they are suspended and
power resource turns off, one device is resumed and power resource turns
on. The other device will remain D0-uninitallized until there are resume
and suspend for it. It may consume more power than lowest power state it
can reach at that point.
> Thanks!
>
> -- I speak only for myself. Rafael J. Wysocki, Intel Open Source
> Technology Center.
next prev parent reply other threads:[~2013-10-18 13:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 8:16 [PATCH] ACPI/Power: Check physical device's runtime pm status before requesting to resume it tianyu.lan
2013-10-11 11:19 ` Rafael J. Wysocki
2013-10-15 8:58 ` Lan Tianyu
2013-10-15 21:22 ` Rafael J. Wysocki
2013-10-16 7:12 ` Lan Tianyu
2013-10-16 8:57 ` Lan Tianyu
2013-10-16 9:26 ` Lan Tianyu
2013-10-16 12:42 ` Rafael J. Wysocki
2013-10-17 1:02 ` Lan Tianyu
2013-10-17 2:40 ` Lan Tianyu
2013-10-17 8:50 ` Lan Tianyu
2013-10-17 11:38 ` Rafael J. Wysocki
2013-10-18 13:05 ` Lan Tianyu [this message]
2013-10-18 17:54 ` Rafael J. Wysocki
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=52613209.3000104@intel.com \
--to=tianyu.lan@intel.com \
--cc=aaron.lu@intel.com \
--cc=lantianyu1986@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).