Message-ID: <20241104060159.GY275077@black.fi.intel.com>
Date: Mon, 4 Nov 2024 08:01:59 +0200
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,

On Fri, Nov 01, 2024 at 06:13:34PM -0500, Aaron Rainbolt wrote:
> Thanks! We have tested the 6.11.5 kernel with this patch. Here's the
> report from our testing team. dmesg logs are attached.
> 
> -----
> 
> 1. Created 2024-11-01_6.11.5_tbt-barlow-ridge-01.dmesg,
>   2024-11-01_6.11.5_tbt-barlow-ridge-02.dmesg.
>   Version 01 is with nouveau. Version 02 is with Nivida (rebuilt); could
>   NOT build keyboard module (complained did not support 6.11 kernel).
> 2. In both cases, hot-plug does not wake display. However, after lspci
>   -k, displays wake and are reliable.

Okay, thanks again for testing!

It means disabling adapter 16 in DROM is actually intentional as that
is not connected to the dGPU and so makes sense.

> * Boot the system up, nothing connected.
> * Wait for Barlow Ridge to enter runtime suspend. This takes ~15
>   seconds so waiting for > 15 seconds should be enough.
> * Plug in USB-C monitor to the USB-C port of the Barlow Ridge.
>   Screen shows in log, screen wakes, but then no signal is received, and
>   no image ever appears. Screen then sleeps after its timeout.
> * Run lspci -k to wake up the monitors. Once this is run, the display
>   shows correctly and is stable. Adding another USB-C display after this
>   also works correctly: It is recognized and lights up in seconds to
>   show the desktop background, and remains stable.
> 
> Notice that pre-6.5 kernels work fine with Barlow Ridge, which implies
> that new code is causing this. It may be new support code for tbt
> capability (and therefore pretty much required). But regardless, it's
> still new code. With the current patch, we can run a udev rule that
> enables hot plugging that likely always work, or (worst case) at least
> empowers the customer to refresh monitors by clicking a button.

We definitely want to fix this properly so there is no need for anyone
to run 'lspci' or similar hacks but because I'm unable to reproduce this
with my reference Barlow Ridge setup, I need some help from you.

You say with v6.5 it works? That's interesting because we only added
this redrive mode workaround for v6.9 and without that the domain surely
will not be kept powered but maybe I'm missing something.

I wonder if your test team could provide log from v6.5 as well following
the same steps, no need to run 'lspci' just do:

  1. Boot the system up, nothing connected.
  2. Wait for ~15 seconds for the domain to enter runtime suspend.
  3. Plug in USB-C monitor to the USB-C port of Barlow Ridge.
  4. Verify that it wakes up and, there is picture on the screen.
  5. Wait for ~15 seconds.

Expectation: After step 5 the monitor still displays picture.

If this works as above then I'm really surprised but if that's the case
then we can maybe think of another approach of dealing with the redrive
mode.

> -----
> 
> To my awareness, we have not yet reported the "device links to tunneled
> native ports are missing" error to the hardware manufacturer. I'll see
> if we can get that reported. Thanks for the heads-up!

Okay thanks. The corresponding "requirement" is here:

https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#map-native-protocols-pcie-displayport-tunneled-through-usb4-to-usb4-host-routers

Powered by blists - more mailing lists