1. 15 Jan, 2019 1 commit
  2. 14 Jan, 2019 8 commits
  3. 11 Jan, 2019 6 commits
  4. 10 Jan, 2019 11 commits
  5. 09 Jan, 2019 11 commits
  6. 08 Jan, 2019 3 commits
    • Lyude Paul's avatar
      drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume() · c235316d
      Lyude Paul authored
      Since I've had to fix two cases of drivers not checking the return code
      from this function, let's make the compiler complain so this doesn't
      come up again in the future.
      
      Changes since v1:
      * Remove unneeded __must_check in function declaration - danvet
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-4-lyude@redhat.com
      c235316d
    • Lyude Paul's avatar
      drm/amdgpu: Don't fail resume process if resuming atomic state fails · 2d1af6a1
      Lyude Paul authored
      This is an ugly one unfortunately. Currently, all DRM drivers supporting
      atomic modesetting will save the state that userspace had set before
      suspending, then attempt to restore that state on resume. This probably
      worked very well at one point, like many other things, until DP MST came
      into the picture. While it's easy to restore state on normal display
      connectors that were disconnected during suspend regardless of their
      state post-resume, this can't really be done with MST because of the
      fact that setting up a downstream sink requires performing sideband
      transactions between the source and the MST hub, sending out the ACT
      packets, etc.
      
      Because of this, there isn't really a guarantee that we can restore the
      atomic state we had before suspend once we've resumed. This sucks pretty
      bad, but so far I haven't run into any compositors that this actually
      causes serious issues with. Most compositors will notice the hotplug we
      send afterwards, and then reprobe state.
      
      Since nouveau and i915 also don't fail the suspend/resume process due to
      failing to restore the atomic state, let's make amdgpu match this
      behavior. Better to resume the GPU properly, then to stop the process
      half way because of a potentially unavoidable atomic commit failure.
      
      Eventually, we'll have a real fix for this problem on the DRM level. But
      we've got some more important low-hanging fruit to deal with first.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Cc: <stable@vger.kernel.org> # v4.15+
      Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com
      2d1af6a1
    • Lyude Paul's avatar
      drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume() · fe7553be
      Lyude Paul authored
      drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
      find the topology in question after a suspend resume cycle, and the
      driver is supposed to check this value and disable MST accordingly if
      it's gone-in addition to sending a hotplug in order to notify userspace
      that something changed during suspend.
      
      Currently, amdgpu just makes the mistake of ignoring the return code
      from drm_dp_mst_topology_mgr_resume() which means that if a topology was
      removed in suspend, amdgpu never notices and assumes it's still
      connected which leads to all sorts of problems.
      
      So, fix this by actually checking the rc from
      drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
      function while we're at it to fix the over-indenting.
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Jerry Zuo <Jerry.Zuo@amd.com>
      Cc: <stable@vger.kernel.org> # v4.15+
      Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com
      fe7553be