Message ID | 20190618161858.77834-1-mika.westerberg@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | PCI / ACPI: Handle sibling devices sharing power resources | expand |
On Tue, Jun 18, 2019 at 6:19 PM Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > > Hi all, > > Based on a discussion regarding patch series I sent previously [1] to deal > with sibling devices sharing ACPI power resources, I prepared a new > reworked version according to the comments I got. > > To summarize, in Intel Ice Lake the Thunderbolt controller, PCIe root ports > and xHCI all share power resources. When they are all in D3hot power > resources (returned by _PR3) can be turned off powering off the whole > block. However, there are two issues around this. > > Firstly the PCI core sets the device power state by asking what the real > ACPI power state is. This results that all but last device sharing the > power resources are in D3hot when the power resources are turned off. This > causes issues if user runs for example 'lspci' because the device is really > in D3cold so what user gets back is all ones (0xffffffff). > > Secondly if any of the device is runtime resumed the power resources are > turned on bringing all other devices sharing the resources to > D0uninitialized losing their wakeup configuration. > > This series aims to fix the two issues by: > > 1. Using the ACPI cached power state when PCI devices are transitioned > into low power states instead of reading back the "real" power state. > > 2. Introducing concept of "_PR0 dependent devices" that get runtime > resumed whenever their power resource (which they might share with > other sibling devices) gets turned on. > > The series is based on the idea of Rafael J. Wysocki <rafael@kernel.org>. > > [1] https://www.spinics.net/lists/linux-pci/msg83583.html > > Mika Westerberg (3): > PCI / ACPI: Use cached ACPI device state to get PCI device power state > ACPI / PM: Introduce concept of a _PR0 dependent device > PCI / ACPI: Add _PR0 dependent devices LGMT overall, patch [2/3] can be simplified slightly IMO (already sent comments for that one). As far as I'm concerned, the other patches need not be updated.