On Wed, Oct 16, 2019 at 1:52 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > On Tue, Oct 15, 2019 at 7:31 AM Daniel Drake <drake@xxxxxxxxxxxx> wrote: > > It's actually coming out of D3cold here, however what happens right > > before this is that __pci_start_power_transition() calls > > pci_platform_power_transition(D0) to leave D3cold state, then > > pci_update_current_state() reads PMCSR and updates dev->current_state > > to D3hot. > > Which pci_update_current_state() do you mean, exactly? > > Note that pci_platform_power_transition() itself contains one, which > triggers after a successful change of the ACPI power state of the > device (which should be the case here). That's the one I mean. pci_pm_default_resume_early - pci_power_up -- __pci_start_power_transition --- pci_platform_power_transition ---- pci_update_current_state(D0) At this point, PMCSR is read and dev->current_status is set to D3 accordingly. Then, continuing in pci_power_up(), pci_raw_set_power_state(D0) is called and the extra delay is needed there after writing PMCSR to transition to D0. I didn't go further along the call trace because at that point the problem has already been triggered. > That I agree with and the platform firmware doesn't compensate for > that (which it could do, arguably). I tried to get official AMD support on this but their response was that they don't have available resources to dedicate to Linux support. Without guidance from AMD I don't think there's any chance of a firmware change from the platform vendor. I think we just have to figure out how to work with it. It seems that Windows 10 delays longer or uses some other scheme. Another alternative that I just tried is retrying the PMCSR write & readback if it didn't complete the transition on the first try. That works fine, let me know if it's preferred to implement something along those lines as a more generic workaround. Daniel
