On Mon, Nov 11, 2019 at 11:31:18AM +0530, Vidya Sagar wrote: > On 11/6/2019 10:11 PM, Bjorn Helgaas wrote: > > Based on Vidya's backtrace, I think the resume path with problems > > is this: > > > > pci_pm_resume_noirq > > pci_pm_default_resume_early > > pci_power_up > > if (platform_pci_power_manageable(dev)) > > platform_pci_set_power_state(dev, PCI_D0) # <-- FW delay here? > > pci_raw_set_power_state > > pci_update_current_state > > pci_device_is_present # <-- config read returns CRS > > > > So I think your suggestion is that Vidya's firmware should be > > doing the delay inside platform_pci_set_power_state()? > > > > Vidya, you typically work on Tegra, so I assume this is on an > > arm64 system? Does it have ACPI? Do you have access to the > > firmware developers to ask about who they expect to do the delays? > > Yes. This is on arm64 (Tegra) and we don't have any ACPI or any > other firmware for that matter. PCIe is brought up directly in the > kernel. I assume that your device is coming out of D3cold because apparently you're seeing a CRS status from the config read when pci_update_current_state() calls pci_device_is_present(). CRS status should only happen after reset or power-on from D3cold, and you're not doing a reset. I'm pretty sure platform_pci_power_manageable() returns false on your system (can you confirm that?) because the only scenarios with platform power management are MID (Intel platform) and ACPI (which you don't have). Maybe you have some other platform-specific mechanism that controls power to PCI devices, and it's not integrated into the platform_pci_*() framework? Bjorn
