Re: [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state

Bjorn Helgaas
2019-06-19T21:28:05Z

On Tue, Jun 18, 2019 at 07:18:56PM +0300, Mika Westerberg wrote:
> Intel Ice Lake has an integrated Thunderbolt controller which means that
> the PCIe topology is extended directly from the two root ports (RP0 and
> RP1).

A PCIe topology is always extended directly from root ports,
regardless of whether a Thunderbolt controller is integrated, so I
guess I'm missing the point you're making. It doesn't sound like this
is anything specific to Thunderbolt?

> Power management is handled by ACPI power resources that are
> shared between the root ports, Thunderbolt controller (NHI) and xHCI
> controller.
>
> The topology with the power resources (marked with []) looks like:
>
> Host bridge
> |
> +- RP0 ---\
> +- RP1 ---|--+--> [TBT]
> +- NHI --/ |
> | |
> | v
> +- xHCI --> [D3C]
>
> Here TBT and D3C are the shared ACPI power resources. ACPI _PR3() method
> returns either TBT or D3C or both.
>
> Say we runtime suspend first the root ports RP0 and RP1, then NHI. Now
> since the TBT power resource is still on when the root ports are runtime
> suspended their dev->current_state is set to D3hot. When NHI is runtime
> suspended TBT is finally turned off but state of the root ports remain
> to be D3hot.
>
> If the user now runs lspci for instance, the result is all 1's like in
> the below output (07.0 is the first root port, RP0):
>
> 00:07.0 PCI bridge: Intel Corporation Device 8a1d (rev ff) (prog-if ff)
> !!! Unknown header type 7f
> Kernel driver in use: pcieport
>
> I short the hardware state is not in sync with the software state
> anymore. The exact same thing happens with the PME polling thread which
> ends up bringing the root ports back into D0 after they are runtime
> suspended.

s/I /In /