Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Lukas Wunner <lukas@wunner.de>,
	Keith Busch <keith.busch@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	linux-acpi@vger.kernel.org, linux-pci@vger.kernel.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 08:16:49 -0500
Message-ID: <20190620131649.GG143205@google.com> (raw)
In-Reply-To: <20190620082730.GM2640@lahna.fi.intel.com>

On Thu, Jun 20, 2019 at 11:27:30AM +0300, Mika Westerberg wrote:
> 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).

Sounds like you're using "PCIe topology extension" to mean
specifically something below a Thunderbolt controller, excluding a
subtree below a root port.  I don't think the PCI core is aware of
that distinction.

> Now the thing is part of the SoC so power management is different
> and causes problems in Linux.

The SoC is a physical packaging issue that really doesn't enter into
the specs directly.  I'm trying to get at the logical topology
questions in terms of the PCIe and ACPI specs.

I assume we could dream up a non-Thunderbolt topology that would show
the same problem?

> > > 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.

I'm not very familiar with _PR3.  I guess this is under an ACPI object
representing a PCI device, e.g., \_SB.PCI0.RP0._PR3?

> > > 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.

So in this example we might have:

  _SB.PCI0.RP0._PR3: TBT
  _SB.PCI0.RP1._PR3: TBT
  _SB.PCI0.NHI._PR3: TBT

And when Linux figures out that everything depending on TBT is in
D3hot, it evaluates TBT._OFF, which puts them all in D3cold?  And part
of the problem is that they're now in D3cold (where config access
doesn't work) but Linux still thinks they're in D3hot (where config
access would work)?

I feel like I'm missing something because I don't know how D3C is
involved, since you didn't mention suspending xHCI.

And I can't mentally match up the patch with the D3hot/D3cold state
change (if indeed that's the problem).  If we were updating the path
that evaluates _OFF so it changed the power state of all dependent
devices, *that* would make a lot of sense to me because it sounds like
that's where the physical change happens that makes things out of
sync.

> > > 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

  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
2019-06-20 13:16       ` Bjorn Helgaas [this message]
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=20190620131649.GG143205@google.com \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=keith.busch@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=rjw@rjwysocki.net \
    /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 \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

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.git