[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC=cRTMXNnZQ_bDes9JFp9yreGC63b_i9fUX6apQzWrUHw2a0Q@mail.gmail.com>
Date: Tue, 17 Apr 2012 13:13:39 +0800
From: huang ying <huang.ying.caritas@...il.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: "Yan, Zheng" <zheng.z.yan@...el.com>, bhelgaas@...gle.com,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
linux-pm@...r.kernel.org, Lin Ming <ming.m.lin@...el.com>,
Zhang Rui <rui.zhang@...el.com>,
ACPI Devel Mailing List <linux-acpi@...r.kernel.org>
Subject: Re: [RFC PATCH] PCIe: Add PCIe runtime D3cold support
On Tue, Apr 17, 2012 at 5:30 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int pcie_port_runtime_resume(struct device *dev)
>> >> +{
>> >> + struct pci_dev *pdev = to_pci_dev(dev);
>> >> +
>> >> + pci_restore_state(pdev);
>> >> + if (pdev->runtime_d3cold)
>> >> + msleep(100);
>> >
>> > What's _that_ supposed to do?
>>
>> When resume from d3cold, PCIe main link will be powered on again, it
>> will take quite some time before the main link go into L0 state.
>> Otherwise, accessing devices under the port may return wrong result.
>
> OK, but this is generic code and as per the standard the link should have been
> reestablished at this point already.
>
> Please don't put some nonstandard-platform-specific quirks like this into
> code that's supposed to handle _every_ PCIe system.
After checking PCIe spec, I found that the 100ms here has its standard origin :)
In PCI Express Base Specification Revision 2.0:
Section 6.6.1 Conventional Reset
"
To allow components to perform internal initialization, system
software must wait for at least
100 ms from the end of a Conventional Reset of one or more devices
before it is permitted to
issue Configuration Requests to those devices
"
But I think we should move the 100ms delay here to PCIe bus code or
PCIe/ACPI code, because that is needed by all PCIe devices for D3cold
support.
Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists