Message-ID: <20241106060635.GJ275077@black.fi.intel.com>
Date: Wed, 6 Nov 2024 08:06:35 +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 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?

Powered by blists - more mailing lists