1. 17 Nov, 2022 5 commits
    • Lyude Paul's avatar
      drm/amdgpu/dm/mst: Use the correct topology mgr pointer in amdgpu_dm_connector · d3e2c664
      Lyude Paul authored
      This bug hurt me. Basically, it appears that we've been grabbing the
      entirely wrong mutex in the MST DSC computation code for amdgpu! While
      we've been grabbing:
      
        amdgpu_dm_connector->mst_mgr
      
      That's zero-initialized memory, because the only connectors we'll ever
      actually be doing DSC computations for are MST ports. Which have mst_mgr
      zero-initialized, and instead have the correct topology mgr pointer located
      at:
      
        amdgpu_dm_connector->mst_port->mgr;
      
      I'm a bit impressed that until now, this code has managed not to crash
      anyone's systems! It does seem to cause a warning in LOCKDEP though:
      
        [   66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
      
      This was causing the problems that appeared to have been introduced by:
      
        commit 4d07b0bc ("drm/display/dp_mst: Move all payload info into the atomic state")
      
      This wasn't actually where they came from though. Presumably, before the
      only thing we were doing with the topology mgr pointer was attempting to
      grab mst_mgr->lock. Since the above commit however, we grab much more
      information from mst_mgr including the atomic MST state and respective
      modesetting locks.
      
      This patch also implies that up until now, it's quite likely we could be
      susceptible to race conditions when going through the MST topology state
      for DSC computations since we technically will not have grabbed any lock
      when going through it.
      
      So, let's fix this by adjusting all the respective code paths to look at
      the right pointer and skip things that aren't actual MST connectors from a
      topology.
      
      Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share")
      Cc: <stable@vger.kernel.org> # v5.6+
      Reviewed-by: default avatarWayne Lin <Wayne.Lin@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      d3e2c664
    • Lyude Paul's avatar
      drm/display/dp_mst: Fix drm_dp_mst_add_affected_dsc_crtcs() return code · a3ae9959
      Lyude Paul authored
      Looks like that we're accidentally dropping a pretty important return code
      here. For some reason, we just return -EINVAL if we fail to get the MST
      topology state. This is wrong: error codes are important and should never
      be squashed without being handled, which here seems to have the potential
      to cause a deadlock.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarWayne Lin <Wayne.Lin@amd.com>
      Fixes: 8ec04671 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs")
      Cc: <stable@vger.kernel.org> # v5.6+
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a3ae9959
    • Lyude Paul's avatar
      drm/amdgpu/mst: Stop ignoring error codes and deadlocking · 7cce4cd6
      Lyude Paul authored
      It appears that amdgpu makes the mistake of completely ignoring the return
      values from the DP MST helpers, and instead just returns a simple
      true/false. In this case, it seems to have come back to bite us because as
      a result of simply returning false from
      compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a
      deadlock happened from these helpers. This could definitely result in some
      kernel splats.
      
      V2:
      * Address Wayne's comments (fix another bunch of spots where we weren't
        passing down return codes)
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 8c20a1ed ("drm/amd/display: MST DSC compute fair share")
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: <stable@vger.kernel.org> # v5.6+
      Reviewed-by: default avatarWayne Lin <Wayne.Lin@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      7cce4cd6
    • Roman Li's avatar
      drm/amd/display: Align dcn314_smu logging with other DCNs · c6023d73
      Roman Li authored
      [Why]
      Assert on non-OK response from SMU is unnecessary.
      It was replaced with respective log message on other asics
      in the past with commit:
      "drm/amd/display: Removing assert statements for Linux"
      
      [How]
      Remove assert and add dbg logging as on other DCNs.
      Signed-off-by: default avatarRoman Li <roman.li@amd.com>
      Reviewed-by: default avatarSaaem Rizvi <SyedSaaem.Rizvi@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c6023d73
    • Alex Deucher's avatar
      drm/amd/display: fix the build when DRM_AMD_DC_DCN is not set · 5ca9b33e
      Alex Deucher authored
      Move the new callback outside of the guard.
      
      Fixes: dc55b106 ("drm/amd/display: Disable phantom OTG after enable for plane disable")
      CC: Alvin Lee <Alvin.Lee2@amd.com>
      CC: Alan Liu <HaoPing.Liu@amd.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      5ca9b33e
  2. 15 Nov, 2022 35 commits