On 11/12/2019 4:02 AM, Bjorn Helgaas wrote:
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).
Yes. I can confirm that platform_pci_power_manageable() is false in case of
Tegra.
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
