From: Mika Westerberg <email@example.com> To: Bjorn Helgaas <firstname.lastname@example.org> Cc: "Rafael J. Wysocki" <email@example.com>, Len Brown <firstname.lastname@example.org>, Lukas Wunner <email@example.com>, Keith Busch <firstname.lastname@example.org>, Alex Williamson <email@example.com>, Alexandru Gagniuc <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state Date: Thu, 20 Jun 2019 11:27:30 +0300 Message-ID: <20190620082730.GM2640@lahna.fi.intel.com> (raw) In-Reply-To: <20190619212801.GC143205@google.com> On Wed, Jun 19, 2019 at 04:28:01PM -0500, Bjorn Helgaas wrote: > 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? The point I'm trying to make here is to explain why this is problem now and not with the previous discrete controllers. With the previous there was only a single ACPI power resource for the root port and the Thunderbolt host router was connected to that root port. PCIe hierarchy was extended through downstream ports (not root ports) of that controller (which includes PCIe switch). Now the thing is part of the SoC so power management is different and causes problems in Linux. > > 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 / Thanks, I'll fix it.
next prev parent reply index Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-18 16:18 [PATCH v2 0/3] PCI / ACPI: Handle sibling devices sharing power resources Mika Westerberg 2019-06-18 16:18 ` [PATCH v2 1/3] PCI / ACPI: Use cached ACPI device state to get PCI device power state Mika Westerberg 2019-06-19 21:28 ` Bjorn Helgaas 2019-06-20 8:27 ` Mika Westerberg [this message] 2019-06-20 13:16 ` Bjorn Helgaas 2019-06-20 13:37 ` Mika Westerberg 2019-06-20 14:15 ` Bjorn Helgaas 2019-06-21 10:32 ` Rafael J. Wysocki 2019-06-21 13:09 ` Bjorn Helgaas 2019-06-22 8:51 ` Rafael J. Wysocki 2019-06-24 10:57 ` Mika Westerberg 2019-06-24 11:14 ` Rafael J. Wysocki 2019-06-25 9:45 ` Mika Westerberg 2019-06-25 10:00 ` Rafael J. Wysocki 2019-06-25 10:08 ` Mika Westerberg 2019-06-21 11:56 ` Rafael J. Wysocki 2019-06-24 10:58 ` Mika Westerberg 2019-06-18 16:18 ` [PATCH v2 2/3] ACPI / PM: Introduce concept of a _PR0 dependent device Mika Westerberg 2019-06-19 13:20 ` Rafael J. Wysocki 2019-06-19 13:34 ` Mika Westerberg 2019-06-18 16:18 ` [PATCH v2 3/3] PCI / ACPI: Add _PR0 dependent devices Mika Westerberg 2019-06-19 13:24 ` [PATCH v2 0/3] PCI / ACPI: Handle sibling devices sharing power resources Rafael J. Wysocki
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190620082730.GM2640@lahna.fi.intel.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-ACPI Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \ email@example.com firstname.lastname@example.org public-inbox-index linux-acpi Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi AGPL code for this site: git clone https://public-inbox.org/ public-inbox