From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Zhao Yakui <yakui.zhao@intel.com>,
Zhang Rui <rui.zhang@intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Len Brown <lenb@kernel.org>,
pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH 6/9] PCI ACPI: Introduce acpi_pm_device_sleep_wake function
Date: Thu, 26 Jun 2008 22:31:34 +0200 [thread overview]
Message-ID: <200806262231.35375.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0806261538310.3893-100000@iolanthe.rowland.org>
On Thursday, 26 of June 2008, Alan Stern wrote:
> On Thu, 26 Jun 2008, Rafael J. Wysocki wrote:
>
> > > Question: Does the PME Status ever get cleared at any other times?
> >
> > Currently, PME# status is only cleared when executing pci_pme_active() (for
> > example via pci_enable_wake()).
> >
> > > For instance, suppose a PCI device does use PME# to wake up the system.
> > > Does its status get cleared?
> >
> > If the driver of the device executes pci_enable_wake(dev, PCI_D0, false) during
> > resume, then the PME# status will be cleared.
>
> Hmm. So if the resume routine doesn't get called for some reason then
> most likely the status won't get cleared.
That's correct.
> > Do you think the core should clear PME# status automatically in that case?
>
> Yes.
Okay, but that will require us to add the clearing of PME# to the PCI
resume/restore callbacks. Perfectly doable, but I'd prefer to do that on top
of the $subject patch.
> > > Or suppose a PCI device is runtime-suspended and it generates a wakeup
> > > request? This will turn on PME# at a time when the system isn't asleep
> > > -- what happens then? Does it get lost somewhere in the bowels of
> > > ACPI?
> >
> > Currently, yes, AFAICS.
>
> Back around last November some initial patches were posted by Shaohua
> Li, as part of Bugzilla #6892.
OK, I will.
> You'd probably be interested to read through the entire bug report. Maybe we
> should start working on it again.
I have nothing against that, but quite frankly I wouldn't like it to become a
road block for the present patch series. Thus, I'd like to add new patches on
top of it rather than to modify it to achieve new goals.
> > > Does the PCI core need new code to handle such things?
> >
> > Well, I thought of adding such things like the clearing of PME# status to the
> > PCI bus type suspend/resume callbacks.
> >
> > Apart from this, I think that to implement PCI runtime PM we'll need to add
> > some new code. First of all, we need to handle the case when some devices are
> > in low power states before suspend/hibernation. Second, we need to handle PME#
> > generated by devices being in low power states (or even in D0) at run time and
> > that will certainly require new code.
>
> Yes it will. We don't have any runtime PM infrastructure for PCI yet.
>
> Although to tell the truth, I'm not sure how important it is. How much
> power can we save by doing runtime suspends of PCI devices? With USB
> controllers, for example, much or most of the savings comes from
> disabling the USB portions of the device, which we _are_ doing. It's
> not clear how much more would be gained by shutting down the PCI
> portions as well.
That can only be determined by experimentation, IMO, so in fact we'll need a
prototype implementation to find that out.
Thanks,
Rafael
next prev parent reply other threads:[~2008-06-26 20:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 23:45 [RFC][PATCH 0/9] PCI PM: Rework PCI device PM Rafael J. Wysocki
2008-06-19 23:46 ` [RFC][PATCH 1/9] ACPI: Introduce acpi_bus_power_manageable function Rafael J. Wysocki
2008-06-24 12:25 ` [linux-pm] " Pavel Machek
2008-06-19 23:47 ` [RFC][PATCH 2/9] PCI: Introduce platform_pci_power_manageable function Rafael J. Wysocki
2008-06-24 12:31 ` [linux-pm] " Pavel Machek
2008-06-19 23:48 ` [RFC][PATCH 3/9] PCI: Rework pci_set_power_state function Rafael J. Wysocki
2008-06-24 12:34 ` [linux-pm] " Pavel Machek
2008-06-19 23:49 ` [RFC][PATCH 4/9] ACPI: Introduce acpi_device_sleep_wake function Rafael J. Wysocki
2008-06-24 12:38 ` [linux-pm] " Pavel Machek
2008-06-19 23:50 ` [RFC][PATCH 5/9] ACPI: Introduce new device wakeup flag 'prepared' Rafael J. Wysocki
2008-06-19 23:51 ` [RFC][PATCH 6/9] PCI ACPI: Introduce acpi_pm_device_sleep_wake function Rafael J. Wysocki
2008-06-25 8:11 ` Zhang Rui
2008-06-25 10:29 ` Zhao Yakui
2008-06-25 18:57 ` Rafael J. Wysocki
2008-06-25 21:31 ` Rafael J. Wysocki
2008-06-26 14:12 ` Alan Stern
2008-06-26 18:21 ` Rafael J. Wysocki
2008-06-26 19:54 ` Alan Stern
2008-06-26 20:31 ` Rafael J. Wysocki [this message]
2008-06-26 20:38 ` Alan Stern
2008-06-19 23:52 ` [RFC][PATCH 7/9] PCI ACPI: Introduce can_wakeup platform callback Rafael J. Wysocki
2008-06-19 23:52 ` [RFC][PATCH 8/9] PCI PM: Rework device PM initialization Rafael J. Wysocki
2008-06-20 15:59 ` [RFC][PATCH 8/9] PCI PM: Rework device PM initialization (rev. 2) Rafael J. Wysocki
2008-06-20 16:07 ` [RFC][PATCH 8.5/9] PCI PM: Add diagnostic statements to PCI device PM initialization Rafael J. Wysocki
2008-06-19 23:57 ` [RFC][PATCH 9/9] PCI PM: Introduce pci_prepare_to_sleep and pci_back_from_sleep 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=200806262231.35375.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=jbarnes@virtuousgeek.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rui.zhang@intel.com \
--cc=stern@rowland.harvard.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox