From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: ykzhao <yakui.zhao@intel.com>
Cc: Len Brown <lenb@kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [Resend][PATCH 0/3] ACPI / PM: Patches missing from linux-acpi-2.6/test
Date: Wed, 15 Dec 2010 23:20:09 +0100 [thread overview]
Message-ID: <201012152320.09384.rjw@sisk.pl> (raw)
In-Reply-To: <1292379455.3983.129.camel@localhost.localdomain>
On Wednesday, December 15, 2010, ykzhao wrote:
> On Wed, 2010-12-15 at 04:24 +0800, Rafael J. Wysocki wrote:
> > On Tuesday, December 14, 2010, ykzhao wrote:
> > > On Tue, 2010-12-14 at 05:25 +0800, Rafael J. Wysocki wrote:
> > > > On Monday, December 13, 2010, ykzhao wrote:
> > > > > On Sun, 2010-12-12 at 06:39 +0800, Rafael J. Wysocki wrote:
...
> >
> > The force_power_state was _only_ a workaround for the case when
> > acpi_bus_set_power() called acpi_bus_get_power() and apparently received
> > a wrong value from it on some systems (two of them had been identified, one was
> > blacklisted in the end). However, after my changes acpi_bus_set_power()
> > doesn't call acpi_bus_get_power() (or any equivalent) any more, so this
> > workaround isn't necessary any more either.
>
> The flag of force_power_state will force it to do the transition of
> power state even when the target state is already the same as the
> current power state. Without this flag, it will skip the power
> transition if the two states are consistent. This is useful under the
> following cases: (The FAN device is used as an example)
> 1. The initial state is reported as D0 state (But we don't know
> whether the FAN device is really turned on)
> 2. If we expect to turn on the corresponding FAN device for the
> first time(put it into D0 state), it will skip the power transition as
> the check of "state == device->power.state". In such case it will be
> better that the power transition is forced in order to assure that the
> FAN device is turned on by calling the _PSC/_ON object.
Before my changes the force_power_state device flag was used only by the fan
driver in two places: in acpi_fan_add() (ie. during fan initialization) and in
acpi_fan_resume(). In both cases it was used to make acpi_bus_set_power()
accept the state read by acpi_bus_get_power(). In both cases
acpi_bus_update_power() can be used to obtain _exactly_ the same result,
so the flag is not necessary any more.
Thanks,
Rafael
next prev parent reply other threads:[~2010-12-15 22:21 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-11 22:39 [Resend][PATCH 0/3] ACPI / PM: Patches missing from linux-acpi-2.6/test Rafael J. Wysocki
2010-12-11 22:43 ` [Resend][PATCH 1/3] Platform / x86: Make fujitsu_laptop use acpi_bus_update_power() Rafael J. Wysocki
2010-12-11 22:43 ` Rafael J. Wysocki
2011-01-01 2:34 ` Jonathan Woithe
2011-01-01 2:34 ` Jonathan Woithe
2010-12-11 22:44 ` [Resend][PATCH 2/3] ACPI / PM: Drop acpi_bus_get_power() Rafael J. Wysocki
2010-12-11 22:44 ` Rafael J. Wysocki
2010-12-11 22:45 ` [Resend][PATCH 3/3] ACPI / PM: Drop acpi_power_nocheck Rafael J. Wysocki
2010-12-11 22:45 ` Rafael J. Wysocki
2010-12-13 8:35 ` [Resend][PATCH 0/3] ACPI / PM: Patches missing from linux-acpi-2.6/test ykzhao
2010-12-13 21:25 ` Rafael J. Wysocki
2010-12-14 1:21 ` ykzhao
2010-12-14 20:24 ` Rafael J. Wysocki
2010-12-14 20:24 ` Rafael J. Wysocki
2010-12-15 2:17 ` ykzhao
2010-12-15 2:17 ` ykzhao
2010-12-15 22:20 ` Rafael J. Wysocki [this message]
2010-12-15 22:20 ` Rafael J. Wysocki
2010-12-14 1:21 ` ykzhao
2010-12-13 21:25 ` Rafael J. Wysocki
2010-12-13 8:35 ` ykzhao
2010-12-13 20:31 ` Len Brown
2010-12-13 21:11 ` Rafael J. Wysocki
2010-12-13 21:11 ` Rafael J. Wysocki
2010-12-13 20:31 ` Len Brown
-- strict thread matches above, loose matches on Subject: below --
2010-12-11 22:39 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=201012152320.09384.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mjg59@srcf.ucam.org \
--cc=yakui.zhao@intel.com \
/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.