1. 16 11月, 2022 2 次提交
  2. 07 10月, 2022 1 次提交
  3. 22 9月, 2022 1 次提交
  4. 21 9月, 2022 1 次提交
  5. 14 9月, 2022 2 次提交
  6. 07 7月, 2022 1 次提交
  7. 06 7月, 2022 1 次提交
  8. 30 6月, 2022 1 次提交
  9. 04 6月, 2022 1 次提交
  10. 07 4月, 2022 1 次提交
  11. 29 3月, 2022 1 次提交
  12. 26 3月, 2022 3 次提交
  13. 03 3月, 2022 1 次提交
  14. 24 2月, 2022 2 次提交
  15. 23 2月, 2022 1 次提交
  16. 01 2月, 2022 1 次提交
  17. 26 1月, 2022 1 次提交
  18. 19 1月, 2022 1 次提交
  19. 08 12月, 2021 1 次提交
  20. 18 11月, 2021 1 次提交
  21. 17 11月, 2021 1 次提交
  22. 04 10月, 2021 1 次提交
  23. 02 10月, 2021 1 次提交
  24. 30 9月, 2021 1 次提交
    • S
      drm/amdgpu: check tiling flags when creating FB on GFX8- · 2f350dda
      Simon Ser 提交于
      On GFX9+, format modifiers are always enabled and ensure the
      frame-buffers can be scanned out at ADDFB2 time.
      
      On GFX8-, format modifiers are not supported and no other check
      is performed. This means ADDFB2 IOCTLs will succeed even if the
      tiling isn't supported for scan-out, and will result in garbage
      displayed on screen [1].
      
      Fix this by adding a check for tiling flags for GFX8 and older.
      The check is taken from radeonsi in Mesa (see how is_displayable
      is populated in gfx6_compute_surface).
      
      Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel)
      
      [1]: https://github.com/swaywm/wlroots/issues/3185Signed-off-by: NSimon Ser <contact@emersion.fr>
      Acked-by: NMichel Dänzer <mdaenzer@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Harry Wentland <hwentlan@amd.com>
      Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      2f350dda
  25. 29 9月, 2021 1 次提交
    • S
      drm/amdgpu: check tiling flags when creating FB on GFX8- · 98122e63
      Simon Ser 提交于
      On GFX9+, format modifiers are always enabled and ensure the
      frame-buffers can be scanned out at ADDFB2 time.
      
      On GFX8-, format modifiers are not supported and no other check
      is performed. This means ADDFB2 IOCTLs will succeed even if the
      tiling isn't supported for scan-out, and will result in garbage
      displayed on screen [1].
      
      Fix this by adding a check for tiling flags for GFX8 and older.
      The check is taken from radeonsi in Mesa (see how is_displayable
      is populated in gfx6_compute_surface).
      
      Changes in v2: use drm_WARN_ONCE instead of drm_WARN (Michel)
      
      [1]: https://github.com/swaywm/wlroots/issues/3185Signed-off-by: NSimon Ser <contact@emersion.fr>
      Acked-by: NMichel Dänzer <mdaenzer@redhat.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Harry Wentland <hwentlan@amd.com>
      Cc: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
      Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      98122e63
  26. 31 8月, 2021 1 次提交
  27. 22 6月, 2021 1 次提交
    • M
      drm/amdgpu: Call drm_framebuffer_init last for framebuffer init · 4c6a2318
      Michel Dänzer 提交于
      Once drm_framebuffer_init has returned 0, the framebuffer is hooked up
      to the reference counting machinery and can no longer be destroyed with
      a simple kfree. Therefore, it must be called last.
      
      If drm_framebuffer_init returns 0 but its caller then returns non-0,
      there will likely be memory corruption fireworks down the road.
      The following lead me to this fix:
      
      [   12.891228] kernel BUG at lib/list_debug.c:25!
      [...]
      [   12.891263] RIP: 0010:__list_add_valid+0x4b/0x70
      [...]
      [   12.891324] Call Trace:
      [   12.891330]  drm_framebuffer_init+0xb5/0x100 [drm]
      [   12.891378]  amdgpu_display_gem_fb_verify_and_init+0x47/0x120 [amdgpu]
      [   12.891592]  ? amdgpu_display_user_framebuffer_create+0x10d/0x1f0 [amdgpu]
      [   12.891794]  amdgpu_display_user_framebuffer_create+0x126/0x1f0 [amdgpu]
      [   12.891995]  drm_internal_framebuffer_create+0x378/0x3f0 [drm]
      [   12.892036]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892075]  drm_mode_addfb2+0x34/0xd0 [drm]
      [   12.892115]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892153]  drm_ioctl_kernel+0xe2/0x150 [drm]
      [   12.892193]  drm_ioctl+0x3da/0x460 [drm]
      [   12.892232]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892274]  amdgpu_drm_ioctl+0x43/0x80 [amdgpu]
      [   12.892475]  __se_sys_ioctl+0x72/0xc0
      [   12.892483]  do_syscall_64+0x33/0x40
      [   12.892491]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Fixes: f258907f "drm/amdgpu: Verify bo size can fit framebuffer size on init."
      Signed-off-by: NMichel Dänzer <mdaenzer@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      4c6a2318
  28. 19 6月, 2021 1 次提交
    • M
      drm/amdgpu: Call drm_framebuffer_init last for framebuffer init · 24981fa3
      Michel Dänzer 提交于
      Once drm_framebuffer_init has returned 0, the framebuffer is hooked up
      to the reference counting machinery and can no longer be destroyed with
      a simple kfree. Therefore, it must be called last.
      
      If drm_framebuffer_init returns 0 but its caller then returns non-0,
      there will likely be memory corruption fireworks down the road.
      The following lead me to this fix:
      
      [   12.891228] kernel BUG at lib/list_debug.c:25!
      [...]
      [   12.891263] RIP: 0010:__list_add_valid+0x4b/0x70
      [...]
      [   12.891324] Call Trace:
      [   12.891330]  drm_framebuffer_init+0xb5/0x100 [drm]
      [   12.891378]  amdgpu_display_gem_fb_verify_and_init+0x47/0x120 [amdgpu]
      [   12.891592]  ? amdgpu_display_user_framebuffer_create+0x10d/0x1f0 [amdgpu]
      [   12.891794]  amdgpu_display_user_framebuffer_create+0x126/0x1f0 [amdgpu]
      [   12.891995]  drm_internal_framebuffer_create+0x378/0x3f0 [drm]
      [   12.892036]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892075]  drm_mode_addfb2+0x34/0xd0 [drm]
      [   12.892115]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892153]  drm_ioctl_kernel+0xe2/0x150 [drm]
      [   12.892193]  drm_ioctl+0x3da/0x460 [drm]
      [   12.892232]  ? drm_internal_framebuffer_create+0x3f0/0x3f0 [drm]
      [   12.892274]  amdgpu_drm_ioctl+0x43/0x80 [amdgpu]
      [   12.892475]  __se_sys_ioctl+0x72/0xc0
      [   12.892483]  do_syscall_64+0x33/0x40
      [   12.892491]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Fixes: f258907f "drm/amdgpu: Verify bo size can fit framebuffer size on init."
      Signed-off-by: NMichel Dänzer <mdaenzer@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      24981fa3
  29. 09 6月, 2021 1 次提交
  30. 06 6月, 2021 1 次提交
  31. 05 6月, 2021 1 次提交
  32. 27 5月, 2021 1 次提交
  33. 11 5月, 2021 3 次提交