From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Aaron Rainbolt <arainbolt@kfocus.org>
Cc: YehezkelShB@gmail.com, michael.jamet@intel.com,
andreas.noever@gmail.com, linux-usb@vger.kernel.org,
mmikowski@kfocus.org, linux-kernel@vger.kernel.org,
Gil Fine <gil.fine@linux.intel.com>
Subject: Re: USB-C DisplayPort display failing to stay active with Intel Barlow Ridge USB4 controller, power-management related issue?
Date: Fri, 11 Oct 2024 19:38:11 +0300 [thread overview]
Message-ID: <20241011163811.GU275077@black.fi.intel.com> (raw)
In-Reply-To: <20241010232656.7fc6359e@kf-ir16>
Hi,
On Thu, Oct 10, 2024 at 11:26:56PM -0500, Aaron Rainbolt wrote:
> > Can you share full dmesg with the repro and "thunderbolt.dyndbg=+p" in
> > the kernel command line?
>
> The full log is very long, so I've included it as an email attachment.
> The exact steps taken after booting with the requested kernel parameter
> were:
>
> 1. boot with thunderbolt.dyndbg=+p kernel param, no USB-C plugged in.
> 2. After login, hot-plug two USB-C cables. This time, the displays came
> up and stayed resident (this happens sometimes)
> 3. Unplugged both cables.
> 4. Replugged both. This time, the displays did not show anything.
> 5. lspci -k "jiggled" the displays and they came back on.
> 6. After ~15s, the displays blacked out again.
> 7. Save to the demsg file after about 30s.
>
> The laptop's firmware is fully up-to-date. One of the fixes we tried
> was installing Windows 11, updating the firmware, and then
> re-installing Kubuntu 24.04. This had no effect on the issue.
>
> Notes:
>
> * Kernel 6.1 does not exhibit this time out. 6.5 and later do.
> * Windows 11 had very similar behavior before installing Windows
> updates. After update, it was fixed.
> * All distros and W11 were tested on the same hardware with the latest
> firmware, so we know this is not a hardware failure.
Thanks for the logs and steps!
I now realize that
a75e0684efe5 ("thunderbolt: Keep the domain powered when USB4 port is in redrive mode")
was half-baked. Yes it deals with the situation where plugging in
monitor when the domain is powered. However, it completely misses these
cases:
* Plug in monitor to the Type-C port when the controller is runtime
suspended.
* Boot with monitor plugged in to the Type-C port.
At the end of this email there is a hack patch that tries to solve this.
Can you try it out? I will be on vacation next week but I'm copying my
colleague Gil who is familiar with this too. He should be able to help
you out during my absense.
Couple of notes about the dmesg you shared. They don't affect this issue
but may cause other issues:
> [ 1.382718] thunderbolt 0000:06:00.0: device links to tunneled native ports are missing!
This is means the BIOS does not implement the USB4 power contract which
means that USB 3.x and PCIe tunnels will not work as expected after
power transition.
> [ 1.416488] thunderbolt 0000:06:00.0: 0: NVM version 14.86
This is really old firmware version. My development system for example
has 56.x so yours might have a bunch of issues that are solved in the
later versions.
The hack patch below:
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index 07a66594e904..0e424b7661be 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -2113,6 +2113,37 @@ static void tb_exit_redrive(struct tb_port *port)
}
}
+static void tb_switch_enter_redrive(struct tb_switch *sw)
+{
+ struct tb_port *port;
+
+ tb_switch_for_each_port(sw, port)
+ tb_enter_redrive(port);
+}
+
+/*
+ * Called during system and runtime suspend to forcefully exit redrive
+ * mode without querying whether the resource is available.
+ */
+static void tb_switch_exit_redrive(struct tb_switch *sw)
+{
+ struct tb_port *port;
+
+ if (!(sw->quirks & QUIRK_KEEP_POWER_IN_DP_REDRIVE))
+ return;
+
+ tb_switch_for_each_port(sw, port) {
+ if (!tb_port_is_dpin(port))
+ continue;
+
+ if (port->redrive) {
+ port->redrive = false;
+ pm_runtime_put(&sw->dev);
+ tb_port_dbg(port, "exit redrive mode\n");
+ }
+ }
+}
+
static void tb_dp_resource_unavailable(struct tb *tb, struct tb_port *port,
const char *reason)
{
@@ -2987,6 +3018,7 @@ static int tb_start(struct tb *tb, bool reset)
tb_create_usb3_tunnels(tb->root_switch);
/* Add DP IN resources for the root switch */
tb_add_dp_resources(tb->root_switch);
+ tb_switch_enter_redrive(tb->root_switch);
/* Make the discovered switches available to the userspace */
device_for_each_child(&tb->root_switch->dev, NULL,
tb_scan_finalize_switch);
@@ -3002,6 +3034,7 @@ static int tb_suspend_noirq(struct tb *tb)
tb_dbg(tb, "suspending...\n");
tb_disconnect_and_release_dp(tb);
+ tb_switch_exit_redrive(tb->root_switch);
tb_switch_suspend(tb->root_switch, false);
tcm->hotplug_active = false; /* signal tb_handle_hotplug to quit */
tb_dbg(tb, "suspend finished\n");
@@ -3094,6 +3127,7 @@ static int tb_resume_noirq(struct tb *tb)
tb_dbg(tb, "tunnels restarted, sleeping for 100ms\n");
msleep(100);
}
+ tb_switch_enter_redrive(tb->root_switch);
/* Allow tb_handle_hotplug to progress events */
tcm->hotplug_active = true;
tb_dbg(tb, "resume finished\n");
@@ -3157,6 +3191,8 @@ static int tb_runtime_suspend(struct tb *tb)
struct tb_cm *tcm = tb_priv(tb);
mutex_lock(&tb->lock);
+ tb_disconnect_and_release_dp(tb);
+ tb_switch_exit_redrive(tb->root_switch);
tb_switch_suspend(tb->root_switch, true);
tcm->hotplug_active = false;
mutex_unlock(&tb->lock);
@@ -3188,6 +3224,7 @@ static int tb_runtime_resume(struct tb *tb)
tb_restore_children(tb->root_switch);
list_for_each_entry_safe(tunnel, n, &tcm->tunnel_list, list)
tb_tunnel_activate(tunnel);
+ tb_switch_enter_redrive(tb->root_switch);
tcm->hotplug_active = true;
mutex_unlock(&tb->lock);
next prev parent reply other threads:[~2024-10-11 16:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 3:01 USB-C DisplayPort display failing to stay active with Intel Barlow Ridge USB4 controller, power-management related issue? Aaron Rainbolt
2024-10-10 4:49 ` Mika Westerberg
2024-10-11 4:26 ` Aaron Rainbolt
2024-10-11 16:38 ` Mika Westerberg [this message]
2024-10-11 18:02 ` Aaron Rainbolt
2024-10-11 23:37 ` Aaron Rainbolt
2024-10-23 6:27 ` Mika Westerberg
2024-10-23 7:39 ` Mika Westerberg
2024-10-23 22:44 ` Aaron Rainbolt
2024-10-24 15:43 ` Mika Westerberg
2024-10-31 14:55 ` Aaron Rainbolt
2024-11-01 7:21 ` Mika Westerberg
2024-11-01 23:13 ` Aaron Rainbolt
2024-11-04 6:01 ` Mika Westerberg
2024-11-05 20:16 ` Aaron Rainbolt
2024-11-06 6:06 ` Mika Westerberg
2024-11-06 17:01 ` Aaron Rainbolt
2024-11-07 9:45 ` Mika Westerberg
2024-11-11 8:22 ` Mika Westerberg
2024-11-12 21:44 ` Aaron Rainbolt
2024-11-14 11:51 ` Mika Westerberg
2024-11-14 16:41 ` Aaron Rainbolt
2024-11-15 13:20 ` Mika Westerberg
2024-12-12 22:12 ` Aaron Rainbolt
2024-12-13 12:03 ` Mika Westerberg
2025-01-24 23:05 ` Aaron Rainbolt
2025-01-26 5:53 ` Mika Westerberg
2025-01-26 16:12 ` Gil Fine
2025-01-28 8:29 ` Gil Fine
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=20241011163811.GU275077@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=arainbolt@kfocus.org \
--cc=gil.fine@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.com \
--cc=mmikowski@kfocus.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
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).