Message-ID: <20241023174413.451710ea@kf-ir16>
Date: Wed, 23 Oct 2024 17:44:13 -0500
From: Aaron Rainbolt <arainbolt@...cus.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
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?

On Wed, 23 Oct 2024 10:39:31 +0300
Mika Westerberg <mika.westerberg@...ux.intel.com> wrote:

> On Wed, Oct 23, 2024 at 09:27:37AM +0300, Mika Westerberg wrote:
> > 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?  
> 
> The other option is that there is no wake when you plugged in the
> monitors and it only wakes up when you did this:
> 
> > 8. Open a terminal and run 'lspci -k' 
> >     - Both displays are activated and remain active.
> >     - There is no timeout.
> >     - This is desired behavior.  
> 
> There is one such wake in the dmesg, this:
> 
> [   60.126328] thunderbolt 0000:06:00.0: control channel starting...
> [   60.126332] thunderbolt 0000:06:00.0: starting TX ring 0
> [   60.126337] thunderbolt 0000:06:00.0: enabling interrupt at
> register 0x38200 bit 0 (0x0 -> 0x1) [   60.126339] thunderbolt
> 0000:06:00.0: starting RX ring 0 [   60.126344] thunderbolt
> 0000:06:00.0: enabling interrupt at register 0x38200 bit 12 (0x1 ->
> 0x1001) [   60.126347] thunderbolt 0000:06:00.0: 0: resuming switch [
>   60.126348] thunderbolt 0000:06:00.0: restoring Switch at 0x0
> (depth: 0, up port: 15) [   60.128535] thunderbolt 0000:06:00.0: 0:
> disabling wakeup [   60.129481] thunderbolt 0000:06:00.0: acking hot
> plug event on 0:13 [   60.129601] thunderbolt 0000:06:00.0: acking
> hot plug event on 0:14 [   60.129730] thunderbolt 0000:06:00.0:
> acking hot plug event on 0:16
> 
> but here we get plug event for all the DP IN adapters (13, 14, 16)
> which tells me that there is nothing connected to the Type-C ports.
> Otherwise it would not send the plug event. This may be due the older
> firmware.
> 
> [   60.137467] thunderbolt 0000:06:00.0: 0: TMU: supports
> uni-directional mode [   60.137478] thunderbolt 0000:06:00.0: 0: TMU:
> supports enhanced uni-directional mode [   60.137589] thunderbolt
> 0000:06:00.0: 0: TMU: current mode: off [   60.137591] thunderbolt
> 0000:06:00.0: 0: TMU: mode change off -> bi-directional, HiFi
> requested [   60.138102] thunderbolt 0000:06:00.0: 0: TMU: mode set
> to: bi-directional, HiFi [   60.139778] thunderbolt 0000:06:00.0:
> 0:13: DP IN resource available after hotplug [   60.139783]
> thunderbolt 0000:06:00.0: looking for DP IN <-> DP OUT pairs: [
> 60.139895] thunderbolt 0000:06:00.0: 0:13: DP IN available [
> 60.139896] thunderbolt 0000:06:00.0: no suitable DP OUT adapter
> available, not tunneling [   60.140018] thunderbolt 0000:06:00.0:
> 0:14: DP IN resource available after hotplug [   60.140021]
> thunderbolt 0000:06:00.0: looking for DP IN <-> DP OUT pairs: [
> 60.140145] thunderbolt 0000:06:00.0: 0:13: DP IN available [
> 60.140277] thunderbolt 0000:06:00.0: 0:14: DP IN available [
> 60.140278] thunderbolt 0000:06:00.0: no suitable DP OUT adapter
> available, not tunneling [   78.863111] thunderbolt 0000:06:00.0: 0:
> suspending switch [   78.863125] thunderbolt 0000:06:00.0: 0:
> enabling wakeup: 0x3f [   78.864812] thunderbolt 0000:06:00.0:
> stopping RX ring 0 [   78.864825] thunderbolt 0000:06:00.0: disabling
> interrupt at register 0x38200 bit 12 (0x1001 -> 0x1) [   78.864849]
> thunderbolt 0000:06:00.0: stopping TX ring 0 [   78.864857]
> thunderbolt 0000:06:00.0: disabling interrupt at register 0x38200 bit
> 0 (0x1 -> 0x0) [   78.864870] thunderbolt 0000:06:00.0: control
> channel stopped
> 
> There is no unplug at all here so the domain can go back to runtime
> suspend.

Hey, thanks for taking a look! Our tester re-did the tests with kernel
6.12~rc4, and reported the following results doing so, along with
another dmesg log. I think your question about xrandr is answered in
this report. The dmesg log is attached.

With the vanilla rc4 kernel plus your patch from earlier:

-----

1. Start with Laptop powered-off
2. Unplug all USB-C connectors.
3. Boot Kubuntu 24.04 with patched kernel 6.12.0-rc4, add cmdline
   parameter thunderbolt.dyndbg=+p. All other optional parameters were
   removed.
4. Log in to normal SDDM to KDE 5.27.11.
5. Open 'Display Settings KCM' to view display detection.
6. Plug in one UBC-C connector attached to 4k display.
   * Note these work with Kernel 6.1 and non-Barlow Ridge systems (TBT
     4).
   * Display does not wake up.
   * Display never appears in 'Display Settings KCM.'
   * This is NOT desired behavior; display should show.
   * (Note: The test results I was given do not mention xrandr here,
     however as subsequent results mention it I believe that the
     monitor does *not* appear in xrandr here. I will double-check
     to be sure.)
7. Open a terminal and run 'lspci -k'
   * Display is activated and remains active. There is a checkerboard
     pattern pattern of where 50% of pixels are black. Probably
     caused by Nouveau.
   * There is no timeout.
   * Device is shown in xrandr --listmonitors
   * This is desired behavior (except for checkerboard)
8. Plug in secone UBC-C connector attached to 4k display.
   * Display is activated and remains active
   * Device is shown in xrandr --listmonitors
   * This is desired behavior (except for checkerboard)

Notes:

1. With debug off, the recognition of screens is better, and previously
   "just worked", at least for one screen.
2. W11 updated works, as do kernels Kernels 6.1 and earlier.
3. W11 from Q4 2022 (pre-update) and kernels 6.5+ do not. With both,
   the screens usually initially attach and then time out after 15s.

-----

Looking at what you describe, it sounds like we should pursue trying to
update the firmware to see if that resolves the issue in combination
with the patch. I'm not entirely sure if it will be possible to do
that, but I'll see if our ODM can help us with that.

View attachment "2024-10-23_6.12.0-rc4_dmesg_barlow-ridge-tbt.log" of type "text/x-log" (119318 bytes)

Powered by blists - more mailing lists