On Mon, 4 Nov 2024 08:01:59 +0200 Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> 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?
