Re: [RFC PATCH] PCIe: Add PCIe runtime D3cold support

Rafael J. Wysocki
2012-04-17T21:10:38Z

On Tuesday, April 17, 2012, huang ying wrote:
> On Tue, Apr 17, 2012 at 5:30 AM, Rafael J. Wysocki <rjw@sisk.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.

I think it should be sufficient to wait for the PME message to arrive at
the root port (which will cause the PME interrupt to appear), at which
point the device that sent it should be able to receive configuration
requests.

At this point, I need to konw what exactly happens when the GPE is triggered
by WAKE#.

Thanks,
Rafael