On Tue, Aug 27, 2019 at 4:50 AM Daniel Drake [off-list ref] wrote:

On Mon, Aug 26, 2019 at 9:32 PM Mathias Nyman
[off-list ref] wrote:

quoted

On 26.8.2019 12.29, Rafael J. Wysocki wrote:

quoted

I wonder if you can reproduce this with the pm-s2idle-rework branch
from linux-pm.git merged in.

Root cause looks similar to:
https://bugzilla.kernel.org/show_bug.cgi?id=203885

Mika wrote a fix for that:
https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@linux.intel.com/ (local)

Thanks for the suggestions. Mika's patch was already applied then
reverted, I applied it again but there's no change.
Also merging in pm-s2idle-rework doesn't make any difference.

Any other ideas? Or comments on my findings so far?
Given that I can't shift D0-D3-D0 reliably directly with setpci before
loading the driver, is that indicative of a fundamental problem with
the platform, or is my test invalid?

That depends on what exactly happens when you try to do the D0-D3-D0
with setpci.  If the device becomes unreachable (or worse) after that,
it indicates a platform issue.  It should not do any harm at the
least.

However, in principle D0-D3-D0 at the PCI level alone may not be
sufficient, because ACPI may need to be involved.

I think that PM-runtime should suspend XHCI controllers without
anything on the bus under them, so I wonder what happens if
".../power/control" is set to "on" and then to "auto" for that device,
with the driver loaded.

Or in terms of other ways of testing the power transition outside of
the suspend path, if a PCI dev is runtime suspended with no driver
loaded, should Linux not be attempting to put it into D3?

PCI devices without drivers cannot be runtime-suspended at all.

Cheers,
Rafael