Message-ID: <20241023062737.GG275077@black.fi.intel.com>
Date: Wed, 23 Oct 2024 09:27:37 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Aaron Rainbolt <arainbolt@...cus.org>
Cc: YehezkelShB@...il.com, michael.jamet@...el.com,
	andreas.noever@...il.com, linux-usb@...r.kernel.org,
	mmikowski@...cus.org, linux-kernel@...r.kernel.org,
	Gil Fine <gil.fine@...ux.intel.com>
Subject: Re: USB-C DisplayPort display failing to stay active with Intel
 Barlow Ridge USB4 controller, power-management related issue?

Hi Aaron,

On Fri, Oct 11, 2024 at 06:37:51PM -0500, Aaron Rainbolt wrote:
> Attached are the test results (including dmesg log) after testing with
> our version of the 6.8 kernel with this patch applied. Sadly we didn't
> have time to test with 6.11.2 as the machines we were testing on had to
> be shipped to customers and we found a working stop-gap solution in the
> mean time. The test that we did, along with it's results, are as
> follows:

Thanks for testing!

> 1. Start with Laptop powered-off
> 2. Unplug all USB-C connectors.
> 3. Attempt to update firmware using Windows.
>    Version remains 'thunderbolt 0000:06:00.0: 0: NVM version 14.86'
> 4. Boot Kubuntu 24.04 with patched kernel, add cmdline parameter
> thunderbolt.dyndbg=+p Note that a "thunderbolt.kf_force_redrive=1"
> kernel parameter was also included by mistake, but it is ignored in
> this kernel. (That was a leftover of a testing kernel we made.)
> 5. Log in to normal SDDM to KDE 5.27.11.
> 6. Open 'Display Settings KCM' to view display
>    detection.
> 7. Plug in 2 x UBC-C connectors attached to 4k displays.
>     - Note these work with Kernel 6.1 and non-Barlow Ridge systems (TB
>       4). 
>     - Displays wake up, but never show graphics signal. They timeout
>       and resume powersave mode.
>     - Displays never appear in 'Display Settings KCM.'
>     - This is NOT desired behavior; displays should show.

Let's stop here so that we deal with one issue at the time. The
corresponding entries in you dmesg are below with my comments. Please
correct me if my analysis does not match your steps.

So here you plug in the first Type-C cable:

> [  182.118304] thunderbolt 0000:06:00.0: control channel starting...
> [  182.118314] thunderbolt 0000:06:00.0: starting TX ring 0
> [  182.118325] thunderbolt 0000:06:00.0: enabling interrupt at register 0x38200 bit 0 (0x0 -> 0x1)
> [  182.118329] thunderbolt 0000:06:00.0: starting RX ring 0
> [  182.118338] thunderbolt 0000:06:00.0: enabling interrupt at register 0x38200 bit 12 (0x1 -> 0x1001)
> [  182.118348] thunderbolt 0000:06:00.0: 0: resuming switch
> [  182.118351] thunderbolt 0000:06:00.0: restoring Switch at 0x0 (depth: 0, up port: 15)
> [  182.118608] thunderbolt 0000:06:00.0: 0: disabling wakeup
> [  182.127404] thunderbolt 0000:06:00.0: 0: TMU: supports uni-directional mode
> [  182.127416] thunderbolt 0000:06:00.0: 0: TMU: supports enhanced uni-directional mode
> [  182.127524] thunderbolt 0000:06:00.0: 0: TMU: current mode: off
> [  182.127527] thunderbolt 0000:06:00.0: 0: TMU: mode change off -> bi-directional, HiFi requested
> [  182.128042] thunderbolt 0000:06:00.0: 0: TMU: mode set to: bi-directional, HiFi
> [  182.128938] thunderbolt 0000:06:00.0: 0:13: enter redrive mode, keeping powered

We notice this as "redrive" and keep the domain powered.

> [  182.129059] thunderbolt 0000:06:00.0: acking hot plug event on 0:16
> [  182.129759] thunderbolt 0000:06:00.0: 0:14: enter redrive mode, keeping powered

We notice the second Type-C connection too.

So at this point the domain keeps powered and if you wait here it should
never runtime suspend because there are two Type-C ports in "redrive"
mode.

> [  315.601384] thunderbolt 0000:06:00.0: acking hot plug event on 0:14

You unplugged the second monitor.

> [  315.601762] thunderbolt 0000:06:00.0: 0:14: DP IN resource available after hotplug
> [  315.602370] thunderbolt 0000:06:00.0: 0:14: exit redrive mode
> [  315.602375] thunderbolt 0000:06:00.0: looking for DP IN <-> DP OUT pairs:
> [  315.602549] thunderbolt 0000:06:00.0: 0:14: DP IN available
> [  315.602553] thunderbolt 0000:06:00.0: no suitable DP OUT adapter available, not tunneling
> [  353.610947] thunderbolt 0000:06:00.0: acking hot plug event on 0:13

And then the first monitor.

> [  353.611260] thunderbolt 0000:06:00.0: 0:13: DP IN resource available after hotplug
> [  353.611921] thunderbolt 0000:06:00.0: 0:13: exit redrive mode

So at this point we are not in "redrive" mode anymore and the domain is
allowed to runtime suspend.

> [  353.611933] thunderbolt 0000:06:00.0: looking for DP IN <-> DP OUT pairs:
> [  353.612076] thunderbolt 0000:06:00.0: 0:14: DP IN available
> [  353.612258] thunderbolt 0000:06:00.0: 0:13: DP IN available
> [  353.612264] thunderbolt 0000:06:00.0: no suitable DP OUT adapter available, not tunneling
> [  372.362496] thunderbolt 0000:06:00.0: 0: suspending switch
> [  372.362506] thunderbolt 0000:06:00.0: 0: enabling wakeup: 0x3f
> [  372.363480] thunderbolt 0000:06:00.0: stopping RX ring 0
> [  372.363497] thunderbolt 0000:06:00.0: disabling interrupt at register 0x38200 bit 12 (0x1001 -> 0x1)
> [  372.363523] thunderbolt 0000:06:00.0: stopping TX ring 0
> [  372.363539] thunderbolt 0000:06:00.0: disabling interrupt at register 0x38200 bit 0 (0x1 -> 0x0)
> [  372.363558] thunderbolt 0000:06:00.0: control channel stopped

Which is what happens here.

I think the driver does the correct thing but why you don't see anything
in the screen is beyond me. Can reproduce just this case with the patch
and then run "xrandr" and see if the monitors are visible there?

Powered by blists - more mailing lists