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