linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Automatic S1 sleep
Date: Tue, 11 May 2010 16:19:05 -0400	[thread overview]
Message-ID: <4BE9BBB9.6030008@cfl.rr.com> (raw)
In-Reply-To: <4BE9A54D.2060500@cfl.rr.com>

On 5/11/2010 2:43 PM, Phillip Susi wrote:
> How does the PCI core get called when changing state?  I would think it
> would be when suspend_devices_and_enter() calls
> dpm_suspend_start(PMESG_SUSPEND) but that does not differentiate between
> S1 and S3, so I would think that currently it would result in placing
> the device in D3, and that if I remove the PMESG_SUSPEND for
> PM_SUSPEND_STANDBY that it would result in leaving devices in D0.

The more I have looked at it the more I think that D1 is NOT used the
way Documentation/power/states.txt says.  It looks to me that the way it
works now is that the PM_EVENT_SUSPEND message is sent to the drivers by
dpm_suspend_start(), and it is up to each individual driver to call
pci_set_power_state() passing it the value returned by
pci_choose_state().  This ends up calling acpi_pci_choose_state() which
calls acpi_pm_device_sleep_state() which consults the ACPI tables to
find out the highest D state the device can wake the system in, if the
device is set to wake up the system.  Otherwise it just returns D3.

In the case of the video card, it is not and can not be set to wakeup
the system, so it should end up using D3.

If suspend_devices_and_enter() is modified NOT to call
dpm_suspend_start(PMESG_SUSPEND) for PM_SUSPEND_STANDBY, then the
drivers would never call into the pci core to set the power state of the
device, so they would remain in D0.

So it seems that what is needed is a PMESG_SUSPEND_STANDBY to cause the
drivers to call pci_set_power_state() and acpi_choose_state() needs
modified to either use D1 if the device supports it, or D0 otherwise
when switching to S1.

Either that or have suspend_devices_and_enter() skip the PMESG_SUSPEND
and instead call into the pci core to walk all devices on the bus and
set them to D1 if they support it without the knowledge of the
controlling driver.

  reply	other threads:[~2010-05-11 20:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 16:03 Automatic S1 sleep Phillip Susi
2010-05-11 17:19 ` Matthew Garrett
2010-05-11 18:18   ` Phillip Susi
2010-05-11 18:21     ` Matthew Garrett
2010-05-11 18:43       ` Phillip Susi
2010-05-11 20:19         ` Phillip Susi [this message]
2010-05-12  5:57 ` Len Brown
2010-05-12 13:39   ` Phillip Susi
2010-05-20  4:07     ` Len Brown
2010-05-20 13:51       ` Phillip Susi

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=4BE9BBB9.6030008@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mjg59@srcf.ucam.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 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).