From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Huang Ying <ying.huang@intel.com>
Cc: huang ying <huang.ying.caritas@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
ming.m.lin@intel.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, Zheng Yan <zheng.z.yan@intel.com>
Subject: Re: [RFC v2 5/5] PCIe, Add PCIe runtime D3cold support
Date: Thu, 10 May 2012 21:28:06 +0200 [thread overview]
Message-ID: <201205102128.06914.rjw@sisk.pl> (raw)
In-Reply-To: <1336466097.6190.196.camel@yhuang-dev>
On Tuesday, May 08, 2012, Huang Ying wrote:
> On Tue, 2012-05-08 at 10:22 +0800, Huang Ying wrote:
> > On Mon, 2012-05-07 at 23:22 +0200, Rafael J. Wysocki wrote:
> > > On Saturday, May 05, 2012, huang ying wrote:
> [...]
> > > > >> --- a/drivers/pci/pci-acpi.c
> > > > >> +++ b/drivers/pci/pci-acpi.c
> > > > >> @@ -48,6 +48,21 @@ static void pci_acpi_wake_dev(acpi_handl
> > > > >> if (event != ACPI_NOTIFY_DEVICE_WAKE || !pci_dev)
> > > > >> return;
> > > > >>
> > > > >> + if (pci_dev->current_state == PCI_D3cold) {
> > > > >> + unsigned int count = 0;
> > > > >> +
> > > > >> + /*
> > > > >> + * Powering on bridge need to resume whole hierarchy,
> > > > >> + * just resume the children to avoid the bridge going
> > > > >> + * suspending as soon as resumed
> > > > >> + */
> > > > >
> > > > > Don't you need to resume the bridge before you start walking the hierarchy
> > > > > below it?
> > > >
> > > > When we resume the hierarchy below the bridge, its parent, the bridge,
> > > > will be resumed firstly. That is:
> > > >
> > > > rpm_resume(child)
> > > > rpm_resume(parent)
> > > > ->runtime_suspend(child)
> > > >
> > > > >> + if (pci_dev->subordinate)
> > > > >> + count = pci_wakeup_bus(pci_dev->subordinate);
> > > > >> + if (count == 0)
> > > > >> + pm_runtime_resume(&pci_dev->dev);
> > > > >
> > > > > What's the count for, exactly?
> > > >
> > > > If there is no devices under the bridge, count returned will be 0,
> > > > then we will resume bridge itself.
> > >
> > > So it looks like you will resume the bridge in both cases, right?
> > >
> > > Why don't you call pm_runtime_get_sync() on the bridge first and then
> > > go for resuming the devices below it, then?
> >
> > OK. I will do that.
>
> After some thinking, have some question on this method.
>
> Do you suggest something like below?
>
> pm_runtime_get_sync(&pci_dev->dev);
> pci_wakeup_bus(pci_dev->subordinate);
> pm_runtime_put(&pci_dev->dev);
>
> If so, because pci_wakeup_bus() will call pm_request_resume() on
> subordinate devices, which is asynchronous, bridge may go suspended
> (powered off) again after pm_runtime_put(), if resuming of subordinate
> devices are still pending in work queue.
I don't think this is a big problem. Worst case it will be resumed
again by the first resuming child, but I doubt we'll see much of that
in practice.
Alternatively, you can use pm_runtime_put_noidle() followed by
pm_runtime_schedule_suspend() with appropriate delay.
Thanks,
Rafael
prev parent reply other threads:[~2012-05-10 19:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 8:13 [RFC v2 0/5] PCIe, Add PCIe runtime D3cold support Huang Ying
2012-05-04 8:13 ` [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag Huang Ying
2012-05-04 19:37 ` Rafael J. Wysocki
2012-05-05 5:15 ` huang ying
2012-05-07 20:33 ` Rafael J. Wysocki
2012-05-04 19:50 ` Bjorn Helgaas
2012-05-05 5:59 ` huang ying
2012-05-07 20:37 ` Rafael J. Wysocki
2012-05-04 8:13 ` [RFC v2 2/5] PM, Add sysfs file power_off to control device power off policy Huang Ying
2012-05-04 19:33 ` Rafael J. Wysocki
2012-05-05 6:29 ` huang ying
2012-05-07 20:53 ` Rafael J. Wysocki
2012-05-08 1:44 ` Huang Ying
2012-05-08 21:34 ` Rafael J. Wysocki
2012-05-09 6:46 ` Huang Ying
2012-05-09 10:38 ` Rafael J. Wysocki
2012-05-10 0:55 ` Huang Ying
2012-05-10 14:48 ` Alan Stern
2012-05-10 19:03 ` Rafael J. Wysocki
2012-05-04 19:50 ` Bjorn Helgaas
2012-05-04 21:00 ` Rafael J. Wysocki
2012-05-05 6:36 ` huang ying
2012-05-04 8:13 ` [RFC v2 3/5] PCIe, Add runtime PM support to PCIe port Huang Ying
2012-05-04 19:43 ` Rafael J. Wysocki
2012-05-05 6:46 ` huang ying
2012-05-07 21:00 ` Rafael J. Wysocki
2012-05-11 7:57 ` Huang Ying
2012-05-11 18:44 ` Rafael J. Wysocki
2012-05-04 19:50 ` Bjorn Helgaas
2012-05-04 20:55 ` Rafael J. Wysocki
2012-05-05 6:54 ` huang ying
2012-05-07 21:06 ` Rafael J. Wysocki
2012-05-05 6:53 ` huang ying
2012-05-04 8:13 ` [RFC v2 4/5] ACPI, PM, Specify lowest allowed state for device sleep state Huang Ying
2012-05-04 20:10 ` Rafael J. Wysocki
2012-05-05 7:25 ` huang ying
2012-05-07 21:15 ` Rafael J. Wysocki
2012-05-08 1:49 ` Huang Ying
2012-05-04 8:13 ` [RFC v2 5/5] PCIe, Add PCIe runtime D3cold support Huang Ying
2012-05-04 19:51 ` Bjorn Helgaas
2012-05-05 7:34 ` huang ying
2012-05-04 20:50 ` Rafael J. Wysocki
2012-05-05 8:08 ` huang ying
2012-05-07 21:22 ` Rafael J. Wysocki
2012-05-08 2:22 ` Huang Ying
2012-05-08 8:34 ` Huang Ying
2012-05-10 19:28 ` Rafael J. Wysocki [this message]
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=201205102128.06914.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=bhelgaas@google.com \
--cc=huang.ying.caritas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=ying.huang@intel.com \
--cc=zheng.z.yan@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;
as well as URLs for NNTP newsgroup(s).