archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <>
To: Bjorn Helgaas <>
Cc: Konstantin Kharlamov <>,,
	"Rafael J. Wysocki" <>,
	Andreas Noever <>,
Subject: Re: [PATCH] PCI: don't power-off apple thunderbolt controller on s2idle
Date: Sat, 8 May 2021 10:20:42 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210507133002.GA1499665@bjorn-Precision-5520>

On Fri, May 07, 2021 at 08:30:02AM -0500, Bjorn Helgaas wrote:
> Apart from that, what I don't like about this (and about the original
> 1df5172c5c25) is that there's no connection to a spec or to documented
> behavior of the device or of suspend/resume.
> For example, "With s2idle, the machine isn't suspended via ACPI, so
> the AML code which powers the controller off isn't executed."  AFAICT
> that isn't actually a required, documented property of s2idle, but
> rather it reaches into the internal implementation.

Actually I'm not sure whether AML code is involved here, I may have mixed
up terms.  To the best of my knowledge, macOS doesn't use s2idle, at least
not on such older MacBooks.  It either puts the machine into ACPI S3
(S2RAM) or S4 (hibernate, suspend to disk).  The Thunderbolt controller's
power rail is off in ACPI S3 and S4.

A peculiarity of the "Cactus Ridge" Thunderbolt 1 controller built into
2012/2013 era MacBooks is that it requires execution of the ACPI methods
in quirk_apple_poweroff_thunderbolt() before power is cut.  Otherwise
the controller is dead when power is reinstated and a cold reboot is
required to resurrect it.  At least that's my understanding, I don't
own a machine with such a chip.  Neither older controllers (such as the
2011 era "Light Ridge") nor newer controllers (such as 2013/2014
"Falcon Ridge") need the quirk.

The ACPI methods seem to fiddle with GPIOs which are connected to
the Force Power, Go2Sx and Ok2Go2Sx pins of the Cactus Ridge controller.
The meaning of the ACPI methods and the pins isn't documented publicly,
it's all reverse-engineered from the macOS driver and leaked schematics.
Some educated guesses as to their meaning are contained in my Thunderbolt
runtime PM patches of 2016:

 * * On Macs with Thunderbolt 1 Gen 2 controllers (Cactus Ridge 4C):
 *   * Additional SXFP method ("Force Power"), accepts only argument 0,
 *     switches the controller off. This carries out just the raw power change,
 *     unlike XRPE which disables the link on the PCIe Root Port in an orderly
 *     fashion before switching off the controller.
 *   * Additional SXLV, SXIO, SXIL methods to utilize the Go2Sx and Ok2Go2Sx
 *     pins (see background below). Apparently SXLV toggles the value given to
 *     the POC via Go2Sx (0 or 1), SXIO changes the direction (0 or 1) and SXIL
 *     returns the value received from the POC via Ok2Go2Sx.
 * * On gen 2 controllers (Cactus Ridge 4C), Intel integrated the MCU into the
 *   controller and called it POC. This caused a change of semantics for XRIN
 *   and XRIL. The POC is powered by a separate 3.3V rail which is active even
 *   in sleep state S4. It only draws a very small current. The regular 3.3V
 *   and 1.05V power rails are no longer controlled by the southbridge but by
 *   the POC. In other words the controller powers *itself* up and down! It is
 *   instructed to do so with the Go2Sx pin. Another pin, Ok2Go2Sx, allows the
 *   controller to indicate if it is ready to power itself down. Apple wires
 *   Go2Sx and Ok2Go2Sx to the same GPIO pin on the southbridge, hence the pin
 *   is used bidirectionally. A third pin, Force Power, is intended by Intel
 *   for debug only but Apple abuses it for XRPE/TRPE and SXFP. Perhaps it
 *   leads to larger power saving gains. They utilize Go2Sx and Ok2Go2Sx only
 *   on Cactus Ridge, presumably because the controller somehow requires that.
 *   On Falcon Ridge they forego these pins and rely solely on Force Power.

With s2idle, the machine never transitions to ACPI S3 or S4.  Consequently,
power to the controller isn't cut, but the quirk prepares it for the
S3/S4 transition.  When the system is woken from s2idle, the chip is
apparently inaccessible.  Solution is to either not execute the PCI quirk
at all (as is done by the present patch) or to undo the quirk when waking
from s2idle.  We don't know how to do the latter, it would have to be
reverse-engineered.  Maybe it can't be done at all with the available
ACPI methods.



  parent reply	other threads:[~2021-05-08  8:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 17:38 [PATCH] PCI: don't power-off apple thunderbolt controller on s2idle Konstantin Kharlamov
2021-05-06 21:48 ` Bjorn Helgaas
2021-05-06 22:07   ` Lukas Wunner
2021-05-07  9:51     ` Rafael J. Wysocki
2021-05-08  8:48       ` Lukas Wunner
2021-05-07 13:30     ` Bjorn Helgaas
2021-05-07 14:08       ` Konstantin Kharlamov
2021-05-12 20:36         ` Konstantin Kharlamov
2021-05-17 19:51           ` PING " Konstantin Kharlamov
2021-05-19 17:28         ` Bjorn Helgaas
2021-05-19 19:12           ` Rafael J. Wysocki
2021-05-19 19:48             ` Bjorn Helgaas
2021-05-20 11:27               ` Rafael J. Wysocki
2021-05-20 11:54                 ` Rafael J. Wysocki
2021-05-20 19:49                   ` Bjorn Helgaas
2021-05-20 23:28                     ` Konstantin Kharlamov
2021-05-24  6:59                       ` Konstantin Kharlamov
2021-05-20 23:55                     ` [PATCH v2] PCI: don't call firmware hooks on suspend unless it's fw-controlled Konstantin Kharlamov
2021-05-28  7:39                       ` PING: " Konstantin Kharlamov
2021-06-03  8:36                         ` PING: " Konstantin Kharlamov
2021-06-03 17:46                           ` Bjorn Helgaas
2021-06-04  8:30                             ` Konstantin Kharlamov
2021-05-21  9:47                     ` [PATCH] PCI: don't power-off apple thunderbolt controller on s2idle Rafael J. Wysocki
2021-05-07 15:02       ` Rafael J. Wysocki
2021-05-08  8:20       ` Lukas Wunner [this message]
2021-05-07  9:32   ` Konstantin Kharlamov
2021-05-07 13:07     ` Bjorn Helgaas
2021-05-07 13:48       ` Konstantin Kharlamov
2021-05-20 11:58   ` Rafael J. Wysocki
2021-06-07 23:17 ` Bjorn Helgaas

Reply instructions:

You may reply publicly 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).