Hi Aaron, On Tue, Nov 12, 2024 at 04:44:47PM -0500, Aaron Rainbolt wrote: > On Mon, 11 Nov 2024 10:22:23 +0200 > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > Hi, > > > > On Thu, Nov 07, 2024 at 11:45:44AM +0200, Mika Westerberg wrote: > > > Hi, > > > > > > On Wed, Nov 06, 2024 at 11:01:34AM -0600, Aaron Rainbolt wrote: > > > > > 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? > > > > > > Unfortunately, I don't know anything about Windows ;-) > > > > > > However, I asked our Thunderbolt hardware/firmware team about this, > > > if they have any idea how it was solved in Windows side. Might take > > > a couple of days though. > > > > While waiting for this, I wonder if you guys could do one more > > experiment? I would like to get the traces what is happening there > > (hoping something pops out there). Following steps: > > > > 1. Download and install tbtools [1]. > > 2. Build and install the kernel with my "redrive" patch. > > 3. Boot the system up, nothing connected. > > 4. Wait until the Barlow Ridge is in runtime suspend (so wait for > > ~30s or so) > > 5. Enable tracing: > > > > # tbtrace enable > > > > 6. Plug in USB-C monitor to the USB-C port of the Barlow Ridge. Do > > not run 'lspci -k'. Expectation here is that there is no picture on > > the monitor (in other words the issue reproduces). > > > > 7. Stop tracing and take full dump: > > > > # tbtrace disable > > # tbtrace dump -vv > trace.out > > > > 8. Send trace.out along with full dmesg to me. > > > > Thanks! > > > > [1] https://github.com/intel/tbtools > > Testing done as requested. Notes from tester: Thanks! > * I verified lsmod |grep thunderbolt which showed module. > * When running sudo ./tbtrace enable, output was Thunderbolt/USB4 > tracing: Enabled. > * When plugging in monitor, it wakes the backlight, but there is no > image. syslog shows it as LG monitor controls. The monitor reports > "no signal" and eventually turns off the backlight to save power. > * When running sudo ./tbtrace disable, output was Thunderbolt/USB4 > tracing: Disabled. > * Output was save using tbtrace dump -vv > trace.out and sudo dmesg > > trace.dmesg. trace.out is an empty file. > > --- > > (Yes, that's correct, trace.out is empty. I attached it nonetheless, > but it's a 0-byte file. I'm guessing the Thunderbolt chip probably > didn't come out of suspend?) Yes, that's possible and this could explain the Linux behaviour but it does not explain why it works in Windows. Also the dmesg is full of stacktraces, not much else. I got reply from our experts. They say that we are expected to get the DP IN unplugs every single time we enter redrive mode. There is nothing "special" added to the Windows side for this either so there is no real explanation why it works in Windows and why we see this in Linux. What they also wanted to check is that with the "production quality" Barlow Ridge firmwares this is not expected to happen and yours is in 14.x so is this some pre-production hardware that you are dealing with or this can be purchased from somewhere? Where did you get the firmware? Thanks!
