From: ebiederm@xmission.com (Eric W. Biederman)
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Huang Ying <ying.huang@intel.com>
Subject: Re: [RFC 1/3] PCI/PM: Fix kexec for D3cold and bridge suspending
Date: Thu, 20 Sep 2012 00:38:33 -0700 [thread overview]
Message-ID: <877grpywhy.fsf@xmission.com> (raw)
In-Reply-To: <CAErSpo5fVbN2vD5Omc7dGJFWUccYZoCOVRF4YmXPe2Oxm81u5g@mail.gmail.com> (Bjorn Helgaas's message of "Mon, 17 Sep 2012 14:54:16 -0600")
Bjorn Helgaas <bhelgaas@google.com> writes:
> +cc Eric and kexec list
>
> On Mon, Sep 17, 2012 at 2:54 AM, Huang Ying <ying.huang@intel.com> wrote:
>> If PCI devices are put into D3cold before kexec, because the
>> configuration registers of PCI devices in D3cold are not accessible.
>>
>> And if PCI bridges are put into low power state before kexec,
>> configuration registers of PCI devices underneath the PCI bridges are
>> not accessible too.
>>
>> These will make some PCI devices can not be scanned after kexec, so
>> resume the PCI devices in D3cold or PCI bridges in low power state
>> before kexec.
>
> Don't we need to resume the device even without the kexec issue? And
> even if it's in D1 or D2?
The basic requirement is that the device needs to be visible so we can
auto discover it. As I recall most sleep states don't make the device
invisible and we can handle the rest in the device initializatoin code.
> It looks to me like pci_msi_shutdown() (and probably drv->shutdown())
> depend on the device being in D0.
There is certainly a depenency on the config registers being visible.
Although I don't know if much will go wrong if they aren't.
Ceratinly pci_msi_shutdown doesn't have anything to do if the device has
had so much power removed that the device is not even exectuing.
Eric
>> Signed-off-by: Huang Ying <ying.huang@intel.com>
>> ---
>> drivers/pci/pci-driver.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -421,6 +421,10 @@ static void pci_device_shutdown(struct d
>> struct pci_dev *pci_dev = to_pci_dev(dev);
>> struct pci_driver *drv = pci_dev->driver;
>>
>> + /* Resume bridges and devices in D3cold for kexec to work properly */
>> + if (pci_dev->current_state == PCI_D3cold || pci_dev->subordinate)
>> + pm_runtime_resume(dev);
>> +
>> if (drv && drv->shutdown)
>> drv->shutdown(pci_dev);
>> pci_msi_shutdown(pci_dev);
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Huang Ying <ying.huang@intel.com>,
linux-pm@vger.kernel.org, linux-pci@vger.kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [RFC 1/3] PCI/PM: Fix kexec for D3cold and bridge suspending
Date: Thu, 20 Sep 2012 00:38:33 -0700 [thread overview]
Message-ID: <877grpywhy.fsf@xmission.com> (raw)
In-Reply-To: <CAErSpo5fVbN2vD5Omc7dGJFWUccYZoCOVRF4YmXPe2Oxm81u5g@mail.gmail.com> (Bjorn Helgaas's message of "Mon, 17 Sep 2012 14:54:16 -0600")
Bjorn Helgaas <bhelgaas@google.com> writes:
> +cc Eric and kexec list
>
> On Mon, Sep 17, 2012 at 2:54 AM, Huang Ying <ying.huang@intel.com> wrote:
>> If PCI devices are put into D3cold before kexec, because the
>> configuration registers of PCI devices in D3cold are not accessible.
>>
>> And if PCI bridges are put into low power state before kexec,
>> configuration registers of PCI devices underneath the PCI bridges are
>> not accessible too.
>>
>> These will make some PCI devices can not be scanned after kexec, so
>> resume the PCI devices in D3cold or PCI bridges in low power state
>> before kexec.
>
> Don't we need to resume the device even without the kexec issue? And
> even if it's in D1 or D2?
The basic requirement is that the device needs to be visible so we can
auto discover it. As I recall most sleep states don't make the device
invisible and we can handle the rest in the device initializatoin code.
> It looks to me like pci_msi_shutdown() (and probably drv->shutdown())
> depend on the device being in D0.
There is certainly a depenency on the config registers being visible.
Although I don't know if much will go wrong if they aren't.
Ceratinly pci_msi_shutdown doesn't have anything to do if the device has
had so much power removed that the device is not even exectuing.
Eric
>> Signed-off-by: Huang Ying <ying.huang@intel.com>
>> ---
>> drivers/pci/pci-driver.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -421,6 +421,10 @@ static void pci_device_shutdown(struct d
>> struct pci_dev *pci_dev = to_pci_dev(dev);
>> struct pci_driver *drv = pci_dev->driver;
>>
>> + /* Resume bridges and devices in D3cold for kexec to work properly */
>> + if (pci_dev->current_state == PCI_D3cold || pci_dev->subordinate)
>> + pm_runtime_resume(dev);
>> +
>> if (drv && drv->shutdown)
>> drv->shutdown(pci_dev);
>> pci_msi_shutdown(pci_dev);
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-09-20 7:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 8:54 [RFC 0/3] PCI/PM: RTD3 fixes/changes for 3.7 Huang Ying
2012-09-17 8:54 ` [RFC 1/3] PCI/PM: Fix kexec for D3cold and bridge suspending Huang Ying
2012-09-17 20:54 ` Bjorn Helgaas
2012-09-17 20:54 ` Bjorn Helgaas
2012-09-20 7:38 ` Eric W. Biederman [this message]
2012-09-20 7:38 ` Eric W. Biederman
2012-09-20 8:19 ` Huang Ying
2012-09-20 8:19 ` Huang Ying
2012-09-20 8:27 ` Eric W. Biederman
2012-09-20 8:27 ` Eric W. Biederman
2012-09-20 19:20 ` Rafael J. Wysocki
2012-09-20 19:20 ` Rafael J. Wysocki
2012-09-21 0:28 ` Huang Ying
2012-09-21 0:28 ` Huang Ying
2012-09-21 19:30 ` Rafael J. Wysocki
2012-09-21 19:30 ` Rafael J. Wysocki
2012-09-17 8:54 ` [RFC 2/3] PCI/PM: Make PCI devices notified when its power resource turned on Huang Ying
2012-09-20 19:33 ` Rafael J. Wysocki
2012-09-17 8:54 ` [RFC 3/3] PCI/PM: Disable PME poll for PCIe devices Huang Ying
2012-09-20 19:31 ` Rafael J. Wysocki
2012-09-20 19:39 ` Matthew Garrett
2012-09-21 1:50 ` Huang Ying
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=877grpywhy.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=bhelgaas@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=ying.huang@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.