[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yk2qMt568oEeTj8H@lahna>
Date: Wed, 6 Apr 2022 17:56:50 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Brad Campbell <lists2009@...rfbargle.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: Apple Thunderbolt Display chaining
Hi,
On Wed, Apr 06, 2022 at 10:51:41AM +0800, Brad Campbell wrote:
> Both included in-line.
>
> This is cold boot with the chain plugged in. I've re-added the dbg to
> print the link number, and I've included your path discovery debugs.
> Boot with chain plugged in, wait for it to settle, unplug and replug.
> First head in the chain fails with :
>
> [ 65.778129] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
> [ 65.778158] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Thanks for the logs!
The DP tunnels look pretty much the same except that the Apple EFI CM
seems to assign 7 buffers for the AUX RX path first hop whereas we
always use 1 buffer. Not sure if that really makes a difference and we
could try to use the same number but first, I realized that the PCI
resource allocation seems not to work properly.
Can you disable PCIe tunneling (if you use Ubuntu/Fedora or similar
there is the "Thunderbolt -> Direct Access" switch that you can turn
off) and try again? Please also take 'sudo lspci -vv' for the resulting
topology. I suspect this might also affect the other issues (the
timeouts) you are seeing. Note this makes the peripherals connected to
the monitors unusable too.
Powered by blists - more mailing lists