linux-kernel - Re: USB-C DisplayPort display failing to stay active with Intel Barlow Ridge USB4 controller, power-management related issue?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241105141627.5e5199b3@kf-ir16>
Date: Tue, 5 Nov 2024 14:16:36 -0600
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 Mon, 4 Nov 2024 08:01:59 +0200
Mika Westerberg <mika.westerberg@...ux.intel.com> wrote:

...snip...

> 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.

6.5 is *broken*. 6.1 works correctly, but that's probably because it
doesn't have Thunderbolt support for Barlow Ridge chips at all. I
suspect this is because the chip is just acting as a USB-C controller,
and that works just fine without the Thunderbolt driver.

> 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.

We'd be happy to run this testing on the 6.1 kernel if it would be
helpful. Will that work, or is 6.1 too old?