[OEM5.14/J][SRU][PATCH v2 0/7] Fix DP tunneling issues on AMD Rembrandt
mario.limonciello at amd.com
Wed Aug 3 14:42:31 UTC 2022
On 8/3/22 09:35, Stefan Bader wrote:
> On 02.08.22 20:11, Mario Limonciello wrote:
>> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1983143
>> When a Thunderbolt monitor or Thunderbolt dock are connected to a USB4
>> port on AMD Yellow Carp (Rembrandt) a software connection manager works
>> with the hardware to initialize tunnels.
>> One of those tunnels is for DP (display port). It was observed that
>> on both the OEM-5.14 as well as Jammy-5.15 kernel that DP tunneling
>> specifically when connecting to a Thunderbolt monitor fails.
>> This circumstance does not happen on OEM-5.17 or mainline kernels.
>> This is due to a backport error on the USB4 patch series that went
>> into OEM-5.14 and moved forward to Jammy-5.15. Patch 1/7 in this
>> series corrects that error as minimally as possible as a SAUCE patch.
>> It was also observed that DP tunneling is not working for Thunderbolt
>> monitor connected at boot, but this is a different root cause.
>> The "Pre-OS" connection manager creates DP tunnels that are expected
>> to be re-used by the OS connection manager. The remaining patches in
>> this series enable this flow.
>> Patches 2-6 are upstream patches or reverts to closer match upstream.
>> Patch 7 is a SAUCE patch because it is not landed upstream yet, but
>> will be needed for patch 2-6 to work properly. If the Thunderbolt
>> CM doesn't hand off resources, amdgpu can't possibly re-use them.
>> For this whole flow to work an updated AMDGPU DMCUB firmware is also
>> needed. This is already in process as part of:
>> * Fixup [1/4], it didn't work due to a contextual error
>> * Add a revert of a stable patch before previous patch [3/4] applied
>> so that it can re-apply cleanly.
>> * Add missing dependencies for patch [3/4] to allow applying cleanly
>> * Re-apply revert commit
>> Mario Limonciello (2):
>> UBUNTU: SAUCE: drm/amd: Fix DP Tunneling with Thunderbolt monitors
>> Revert "drm/amd/display: Fix DPIA outbox timeout after S3/S4/reset"
>> Meenakshikumar Somasundaram (1):
>> drm/amd/display: Fix for dmub outbox notification enable
>> Nicholas Kazlauskas (2):
>> drm/amd/display: Reset link encoder assignments for GPU reset
>> drm/amd/display: Fix DPIA outbox timeout after S3/S4/reset
>> Sanjay R Mehta (1):
>> UBUNTU: SAUCE: thunderbolt: Add DP out resource when DP tunnel is
>> Stylon Wang (1):
>> drm/amd/display: Fix new dmub notification enabling in DM
>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 39 +++++++++--
>> drivers/gpu/drm/amd/display/dc/core/dc.c | 66 +++++++++++++++++--
>> drivers/gpu/drm/amd/display/dc/dc.h | 3 +
>> .../gpu/drm/amd/display/dc/dce/dmub_outbox.c | 25 +++----
>> .../gpu/drm/amd/display/dc/dce/dmub_outbox.h | 4 +-
>> .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 4 --
>> .../drm/amd/display/dc/dcn20/dcn20_hwseq.c | 5 +-
>> .../drm/amd/display/dc/dcn31/dcn31_hwseq.c | 2 +-
>> drivers/thunderbolt/tb.c | 15 +++++
>> drivers/thunderbolt/tb.h | 1 +
>> drivers/thunderbolt/tunnel.c | 2 +
>> 11 files changed, 133 insertions(+), 33 deletions(-)
> I think this is a replacement for the previous set but lacking the
> topic. If that is correct, then the previous thread should be NACKed to
> make it clear.
Yes it's replacement for previous series to make everything apply
cleanly. I'll drop a message to that thread to make it clearer.
> The method chosen to work around the context change is somewhat
> worrying. Basically the patch reverted was upstream stable and had been
> adjusted in context to match the v5.15.y code base. Then you re-apply
> the unmodified upstream patch. So we are closer to what code looks like
> in upstream v5.16 or later but further away from linux-5.15.y.
Yes that's correct. I guess it's up to you which way you prefer to take
it. I thought it was more important to make things apply cleanly.
If you prefer the previous approach I'll resubmit the previous patches
[2-4] and the fixed [1/7] in this series as a v3.
> I know we
> are already diverting. Just scary to see this example of how mind
> boggling things can become. This time it is just context but it might be
> a different flow of execution or locking in other cases. And this is
> near impossible to properly review.
Yeah I don't think this approach works every single time.
More information about the kernel-team