1. 06 2月, 2019 10 次提交
  2. 29 1月, 2019 3 次提交
  3. 26 1月, 2019 6 次提交
  4. 15 1月, 2019 10 次提交
  5. 21 12月, 2018 1 次提交
  6. 19 12月, 2018 2 次提交
    • N
      drm/amd/display: Add below the range support for FreeSync · 180db303
      Nicholas Kazlauskas 提交于
      [Why]
      When the flip-rate is below the minimum supported variable refresh rate
      range for the monitor the front porch wait will timeout and be
      frequently misaligned resulting in stuttering and/or flickering.
      
      The FreeSync module can still maintain a smooth and flicker free
      image when the monitor has a refresh rate range such that the maximum
      refresh > 2 * minimum refresh by utilizing low framerate compensation,
      "below the range".
      
      [How]
      Hook up the pre-flip and post-flip handlers from the FreeSync module.
      These adjust the minimum/maximum vrr range to duplicate frames
      when appropriate by tracking flip timestamps.
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      180db303
    • N
      drm/amd/display: Skip fast cursor updates for fb changes · 77acd1cd
      Nicholas Kazlauskas 提交于
      [Why]
      The behavior of drm_atomic_helper_cleanup_planes differs depending on
      whether the commit was asynchronous or not. When it's called from
      amdgpu_dm_atomic_commit_tail during a typical atomic commit the
      plane state has been swapped so it calls cleanup_fb on the old plane
      state.
      
      However, in the asynchronous commit codepath the call to
      drm_atomic_helper_commit also calls dm_plane_helper_cleanup_fb after
      atomic_async_update has been called. Since the plane state is updated
      in place and has not been swapped the cleanup_fb call affects the new
      plane state.
      
      This results in a use after free for the given sequence:
      
      - Fast update, fb1 pin/ref, fb1 unpin/unref
      - Fast update, fb2 pin/ref, fb2 unpin/unref
      - Slow update, fb1 pin/ref, fb2 unpin/unref
      - Fast update, fb2 pin/ref -> use after free. bug
      
      [How]
      Disallow framebuffer changes in the fast path. Since this includes
      a NULL framebuffer, this means that only framebuffers that have
      been previously pin+ref at least once will be used, preventing a
      use after free.
      
      This has a significant throughput reduction for cursor updates where
      the framebuffer changes. For most desktop usage this isn't a problem,
      but it does introduce performance regressions for two specific IGT
      tests:
      
      - cursor-vs-flip-toggle
      - cursor-vs-flip-varying-size
      
      Fixes: 2cc751931afc ("drm/amd/display: Add fast path for cursor plane updates")
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
      Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      77acd1cd
  7. 13 12月, 2018 1 次提交
  8. 12 12月, 2018 3 次提交
  9. 06 12月, 2018 1 次提交
  10. 05 12月, 2018 1 次提交
    • N
      drm/amd/display: Fix overflow/truncation from strncpy. · 090afc1e
      Nicholas Kazlauskas 提交于
      [Why]
      
      New GCC warnings for stringop-truncation and stringop-overflow help
      catch common misuse of strncpy. This patch suppresses these warnings
      by fixing bugs identified by them.
      
      [How]
      
      Since the parameter passed for name in amdpgu_dm_create_common_mode has
      no fixed length, if the string is >= DRM_DISPLAY_MODE_LEN then
      mode->name will not be null-terminated.
      
      The truncation in fill_audio_info won't actually occur (and the string
      will be null-terminated since the buffer is initialized to zero), but
      the warning can be suppressed by using the proper buffer size.
      
      This patch fixes both issues by using the real size for the buffer and
      making use of strscpy (which always terminates).
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      090afc1e
  11. 01 12月, 2018 2 次提交