From: Mario Limonciello <superm1@kernel.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: "open list:THUNDERBOLT DRIVER" <linux-usb@vger.kernel.org>,
linux-kernel@vger.kernel.org,
Andreas Noever <andreas.noever@gmail.com>,
Michael Jamet <michael.jamet@intel.com>,
Yehezkel Bernat <YehezkelShB@gmail.com>
Subject: Re: [PATCH v2 0/2] thunderbolt: Fix S4 resume incongruities
Date: Wed, 7 Jan 2026 14:50:54 -0600 [thread overview]
Message-ID: <158442b3-28c2-4f8c-ba42-0b9c6661c650@kernel.org> (raw)
In-Reply-To: <20260107093353.GO2275908@black.igk.intel.com>
On 1/7/26 3:33 AM, Mika Westerberg wrote:
> Hi,
>
> On Mon, Jan 05, 2026 at 11:37:47PM -0600, Mario Limonciello (AMD) wrote:
>> When a machine is restored from S4 if the firmware CM has created
>> tunnels there can be an incongruity of expectation from the kernel
>> when compared to booting from S5. This series addresses those.
>
> I suspect there is no Firmware CM in AMD platforms so this actually means
> the BIOS CM, correct?
That's correct.
>
> However, on S4 we actually do reset host router when the "boot kernel" is
> started before loading and jumping to the hibernation image.
That's only if thunderbolt.ko is built into the kernel or is included in
the initramfs before it does the pivot to the hibernation image.
At least in the tests we were doing it's not part of the boot kernel.
> It might be
> that this boot kernel tunnel configuration is causing the issues you are
> seeing (can you elaborate on those?)
The issues manifest "downstream" in the GPU driver. There are a bunch
of aux failures and a non functional display. Tracing it back the GPU
driver isn't alive at the time that the tunnels are attempted to be
reconstructed at the moment and so CM tears DP tunnel down and then when
GPU driver does come up it is not functional.
DP tunnel constructed at:
[ 486.007194] thunderbolt 0000:c6:00.6: AUX RX path activation complete
First DPRx timeout at:
[ 486.135483] thunderbolt 0000:c6:00.6: 0:6 <-> 2:13 (DP): DPRX read
timeout
DP tunnel deactivating at:
[ 486.331856] thunderbolt 0000:c6:00.6: 0:6 <-> 2:13 (DP): deactivating
First DPRx DPCD reading starts at:
[ 486.351765] amdgpu 0000:c4:00.0: amdgpu: [drm] DPIA AUX failed on
0xf0000(10), error 7
I believe by doing the reset in this series we instead get HPD events
and react to those. If we keep things as they are today I think we need
to work out some changes to device ordering.
> but given that it is (typically the
> same kernel binary) it should be creating the tunnels the same way.
>
>>
>> v1:
>> Link: https://lore.kernel.org/linux-usb/20251023050354.115015-1-superm1@kernel.org/
>>
>> Mario Limonciello (AMD) (2):
>> thunderbolt: Move nhi_reset before pmops declaration
>> thunderbolt: Reset NHI during S4 restore_noirq() callback
>>
>> drivers/thunderbolt/nhi.c | 77 ++++++++++++++++++++++-----------------
>> drivers/thunderbolt/tb.c | 29 ++++++++-------
>> drivers/thunderbolt/tb.h | 1 +
>> 3 files changed, 61 insertions(+), 46 deletions(-)
>>
>> --
>> 2.43.0
next prev parent reply other threads:[~2026-01-07 20:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 5:37 Mario Limonciello (AMD)
2026-01-06 5:37 ` [PATCH v2 1/2] thunderbolt: Move nhi_reset before pmops declaration Mario Limonciello (AMD)
2026-01-06 5:37 ` [PATCH v2 2/2] thunderbolt: Reset NHI during S4 restore_noirq() callback Mario Limonciello (AMD)
2026-01-07 9:33 ` [PATCH v2 0/2] thunderbolt: Fix S4 resume incongruities Mika Westerberg
2026-01-07 20:50 ` Mario Limonciello [this message]
2026-01-08 11:42 ` Mika Westerberg
2026-01-08 19:18 ` Mario Limonciello
2026-01-09 7:23 ` Mika Westerberg
2026-01-09 15:38 ` Mario Limonciello
2026-01-10 0:42 ` Katiyar, Pooja
2026-01-13 18:44 ` Mario Limonciello (AMD) (kernel.org)
2026-01-17 16:57 ` Katiyar, Pooja
2026-01-19 19:59 ` Mario Limonciello (AMD) (kernel.org)
2026-01-19 22:13 ` Kenneth Crudup
2026-01-29 23:13 ` Katiyar, Pooja
2026-01-30 1:39 ` Kenneth Crudup
2026-01-30 1:42 ` Kenneth Crudup
2026-02-04 0:50 ` Katiyar, Pooja
2026-05-05 21:21 ` Mario Limonciello
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:
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=158442b3-28c2-4f8c-ba42-0b9c6661c650@kernel.org \
--to=superm1@kernel.org \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
/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
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
all inboxes | Powered by JetHome®