1. 26 3月, 2022 2 次提交
  2. 24 2月, 2022 1 次提交
  3. 17 1月, 2022 1 次提交
  4. 18 11月, 2021 1 次提交
  5. 20 5月, 2021 1 次提交
  6. 24 3月, 2021 1 次提交
    • M
      drm/amdgpu: Verify bo size can fit framebuffer size on init. · f258907f
      Mark Yacoub 提交于
      To initialize the framebuffer, call drm_gem_fb_init_with_funcs which
      verifies that the BO size can fit the FB size by calculating the minimum
      expected size of each plane.
      
      The bug was caught using igt-gpu-tools test: kms_addfb_basic.too-high
      and kms_addfb_basic.bo-too-small
      
      Tested on ChromeOS Zork by turning on the display and running a YT
      video.
      
      === Changes from v1 ===
      1. Added new line under declarations.
      2. Use C style comment.
      
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: "Christian König" <christian.koenig@amd.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Signed-off-by: NMark Yacoub <markyacoub@chromium.org>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f258907f
  7. 31 10月, 2020 1 次提交
  8. 16 9月, 2020 1 次提交
  9. 11 8月, 2020 1 次提交
  10. 13 2月, 2020 1 次提交
  11. 25 5月, 2019 1 次提交
  12. 11 4月, 2019 1 次提交
  13. 03 4月, 2019 1 次提交
    • M
      drm/amd/display: Rework vrr flip throttling for late vblank irq. · fdd1fe57
      Mario Kleiner 提交于
      For throttling to work correctly, we always need a baseline vblank
      count last_flip_vblank that increments at start of front-porch.
      
      This is the case for drm_crtc_vblank_count() in non-VRR mode, where
      the vblank irq fires at start of front-porch and triggers DRM core
      vblank handling, but it is no longer the case in VRR mode, where
      core vblank handling is done later, after end of front-porch.
      
      Therefore drm_crtc_vblank_count() is no longer useful for this.
      We also can't use drm_crtc_accurate_vblank_count(), as that would
      screw up vblank timestamps in VRR mode when called in front-porch.
      
      To solve this, use the cooked hardware vblank counter returned by
      amdgpu_get_vblank_counter_kms() instead, as that one is cooked to
      always increment at start of front-porch, independent of when
      vblank related irq's fire.
      
      This patch allows vblank irq handling to happen anywhere within
      vblank of even after it, without a negative impact on flip
      throttling, so followup patches can shift the vblank core
      handling trigger point wherever they need it.
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      fdd1fe57
  14. 06 3月, 2019 1 次提交
    • M
      drm/amd/display: Use vrr friendly pageflip throttling in DC. · 7b19bba5
      Mario Kleiner 提交于
      In VRR mode, keep track of the vblank count of the last
      completed pageflip in amdgpu_crtc->last_flip_vblank, as
      recorded in the pageflip completion handler after each
      completed flip.
      
      Use that count to prevent mmio programming a new pageflip
      within the same vblank in which the last pageflip completed,
      iow. to throttle pageflips to at most one flip per video
      frame, while at the same time allowing to request a flip
      not only before start of vblank, but also anywhere within
      vblank.
      
      The old logic did the same, and made sense for regular fixed
      refresh rate flipping, but in vrr mode it prevents requesting
      a flip anywhere inside the possibly huge vblank, thereby
      reducing framerate in vrr mode instead of improving it, by
      delaying a slightly delayed flip requests up to a maximum
      vblank duration + 1 scanout duration. This would limit VRR
      usefulness to only help applications with a very high GPU
      demand, which can submit the flip request before start of
      vblank, but then have to wait long for fences to complete.
      
      With this method a flip can be both requested and - after
      fences have completed - executed, ie. it doesn't matter if
      the request (amdgpu_dm_do_flip()) gets delayed until deep
      into the extended vblank due to cpu execution delays. This
      also allows clients which want to regulate framerate within
      the vrr range a much more fine-grained control of flip timing,
      a feature that might be useful for video playback, and is
      very useful for neuroscience/vision research applications.
      
      In regular non-VRR mode, retain the old flip submission
      behavior. This to keep flip scheduling for fullscreen X11/GLX
      OpenGL clients intact, if they use the GLX_OML_sync_control
      extensions glXSwapBufferMscOML(, ..., target_msc,...) function
      with a specific target_msc target vblank count.
      
      glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
      not flip at the proper target_msc for a non-zero target_msc
      if VRR mode is active with this patch. They'd often flip one
      frame too early. However, this limitation should not matter
      much in VRR mode, as scheduling based on vblank counts is
      pretty futile/unusable under variable refresh duration
      anyway, so no real extra harm is done.
      
      According to some testing already done with this patch by
      Nicholas on top of my tests, IGT tests didn't report any
      problems. If fixes stuttering and flickering when flipping
      at rates below the minimum vrr refresh rate.
      
      Fixes: bb47de73 ("drm/amdgpu: Set FreeSync state using drm VRR
      properties")
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: <stable@vger.kernel.org>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Tested-by: NBruno Filipe <bmilreu@gmail.com>
      Reviewed-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7b19bba5
  15. 28 2月, 2019 1 次提交
    • M
      drm/amd/display: Use vrr friendly pageflip throttling in DC. · d6371665
      Mario Kleiner 提交于
      In VRR mode, keep track of the vblank count of the last
      completed pageflip in amdgpu_crtc->last_flip_vblank, as
      recorded in the pageflip completion handler after each
      completed flip.
      
      Use that count to prevent mmio programming a new pageflip
      within the same vblank in which the last pageflip completed,
      iow. to throttle pageflips to at most one flip per video
      frame, while at the same time allowing to request a flip
      not only before start of vblank, but also anywhere within
      vblank.
      
      The old logic did the same, and made sense for regular fixed
      refresh rate flipping, but in vrr mode it prevents requesting
      a flip anywhere inside the possibly huge vblank, thereby
      reducing framerate in vrr mode instead of improving it, by
      delaying a slightly delayed flip requests up to a maximum
      vblank duration + 1 scanout duration. This would limit VRR
      usefulness to only help applications with a very high GPU
      demand, which can submit the flip request before start of
      vblank, but then have to wait long for fences to complete.
      
      With this method a flip can be both requested and - after
      fences have completed - executed, ie. it doesn't matter if
      the request (amdgpu_dm_do_flip()) gets delayed until deep
      into the extended vblank due to cpu execution delays. This
      also allows clients which want to regulate framerate within
      the vrr range a much more fine-grained control of flip timing,
      a feature that might be useful for video playback, and is
      very useful for neuroscience/vision research applications.
      
      In regular non-VRR mode, retain the old flip submission
      behavior. This to keep flip scheduling for fullscreen X11/GLX
      OpenGL clients intact, if they use the GLX_OML_sync_control
      extensions glXSwapBufferMscOML(, ..., target_msc,...) function
      with a specific target_msc target vblank count.
      
      glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
      not flip at the proper target_msc for a non-zero target_msc
      if VRR mode is active with this patch. They'd often flip one
      frame too early. However, this limitation should not matter
      much in VRR mode, as scheduling based on vblank counts is
      pretty futile/unusable under variable refresh duration
      anyway, so no real extra harm is done.
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      d6371665
  16. 24 1月, 2019 1 次提交
  17. 29 11月, 2018 1 次提交
    • N
      drm/amdgpu: Set FreeSync state using drm VRR properties · bb47de73
      Nicholas Kazlauskas 提交于
      Support for AMDGPU specific FreeSync properties and ioctls are dropped
      from amdgpu_dm in favor of supporting drm variable refresh rate
      properties.
      
      The notify_freesync and set_freesync_property functions are dropped
      from amdgpu_display_funcs.
      
      The drm vrr_capable property is now attached to any DP/HDMI connector.
      Its value is updated accordingly to the connector's FreeSync capabiltiy.
      
      The freesync_enable logic and ioctl control has has been dropped in
      favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
      fine grained atomic control over which CRTCs should support variable
      refresh rate.
      
      To handle state changes for vrr_enabled it was easiest to drop the
      forced modeset on freesync_enabled change. This patch now performs the
      required stream updates when planes are flipped.
      
      This is done for a few reasons:
      
      (1) VRR stream updates can be done in the fast update path
      
      (2) amdgpu_dm_atomic_check would need to be hacked apart to check
          desired variable refresh state and capability before the CRTC
          disable pass.
      
      (3) Performing VRR stream updates on-flip is needed for enabling BTR
          support.
      
      VRR packets and timing adjustments are now tracked and compared to
      previous values sent to the hardware.
      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>
      bb47de73
  18. 27 11月, 2018 2 次提交
  19. 20 11月, 2018 1 次提交
  20. 16 11月, 2018 1 次提交
  21. 07 11月, 2018 1 次提交
  22. 12 4月, 2018 1 次提交
  23. 15 3月, 2018 3 次提交
  24. 20 2月, 2018 10 次提交
  25. 07 12月, 2017 1 次提交
  26. 05 12月, 2017 1 次提交
  27. 09 11月, 2017 1 次提交