Message-ID: <20241106110134.1871a7f6@kf-ir16>
Date: Wed, 6 Nov 2024 11:01:34 -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 Wed, 6 Nov 2024 08:06:35 +0200
Mika Westerberg <mika.westerberg@...ux.intel.com> wrote:

> Hi Aaron,
> 
> On Tue, Nov 05, 2024 at 02:16:36PM -0600, Aaron Rainbolt wrote:
> > 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.  
> 
> Exactly so while it "works" for this particular case all other cases
> will not pass.
> 
> > > 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?  
> 
> Unfortunately that does not help here. I need to figure something else
> how to detect the redrive case with this firmware but first, does this
> work in Windows? I mean if you install Windows to this same system
> does it work as expected?

It does work as expected under Windows 11, with one major caveat. We
used a Windows 11 ISO with a setup.exe created on April 05 2023 for
installing the test system, and after initial installation it behaved
exactly the same way as Linux behaves now (displays going blank soon
after being plugged in). However, after installing all available
Windows updates, the issue resolved, and the displays worked exactly as
intended (the screens are recognized when attached and do not end up
disconnecting after a timeout).

Would it be helpful to test on Windows 11, and provide a report and
system logs?

Powered by blists - more mailing lists