mbox series

[v2,00/10] drm/ast: Clean-up cursor-plane updates

Message ID 20210209134632.12157-1-tzimmermann@suse.de (mailing list archive)
Headers show
Series drm/ast: Clean-up cursor-plane updates | expand

Message

Thomas Zimmermann Feb. 9, 2021, 1:46 p.m. UTC
(was: drm/ast: Move cursor vmap calls out of commit tail)

Ast has vmap calls in its cursor's atomic_update function. This is not
supported as vmap might aquire the dma reservation lock. While at it,
cleanup the whole cursor code: the patchset removes all possible runtime
errors from the atomic_update function and reduces the overhead from
vmap calls on the HW cursor BOs to a minimum.

Patches 1 to 3 update the cursor code and prepare before the refactoring.

Patch 4 and 5 inline the cursor update logic into the rsp cursor-plane
functions. This is mostly about moving code around.

Patches 6 to 9 add a dedicated cursor plane that maintains the two BOs
for HW cursors. The HW cursor BOs are permanently pinned and vmapped
while the cursor plane is initialized. Thus removing the related vmap
operations from atomic_update.

Finally patch 10 converts ast cursors to struct drm_shadow_plane_state.
BOs with cursor image data from userspace are vmapped in prepare_fb and
vunampped in cleanup_fb. The actual update of the cursor image is being
moved from prepare_fb to atomic_update.

With the patchset applied, all cursor preparation is performed before
the commit-tail functions; while the actual update is performed within.

Tested by running X11 and Weston on ast hardware.

v2:
	* convert to drm_shadow_plane_state helpers

Thomas Zimmermann (10):
  drm/ast: Add constants for VGACRCB register bits
  drm/ast: Fix invalid usage of AST_MAX_HWC_WIDTH in cursor atomic_check
  drm/ast: Initialize planes in helper functions
  drm/ast: Allocate HW cursor BOs during cursor-plane initialization
  drm/ast: Inline ast cursor-update functions into modesetting code
  drm/ast: Add cursor-plane data structure
  drm/ast: Store cursor BOs in cursor plane
  drm/ast: Map HW cursor BOs permanently
  drm/ast: Store each HW cursor offset after pinning the rsp BO
  drm/ast: Move all of the cursor-update functionality to atomic_update

 drivers/gpu/drm/ast/Makefile     |   3 +-
 drivers/gpu/drm/ast/ast_cursor.c | 286 --------------------------
 drivers/gpu/drm/ast/ast_drv.h    |  47 +++--
 drivers/gpu/drm/ast/ast_mode.c   | 334 +++++++++++++++++++++++++------
 4 files changed, 312 insertions(+), 358 deletions(-)
 delete mode 100644 drivers/gpu/drm/ast/ast_cursor.c

--
2.30.0

Comments

Gerd Hoffmann Feb. 17, 2021, 9:53 a.m. UTC | #1
On Tue, Feb 09, 2021 at 02:46:22PM +0100, Thomas Zimmermann wrote:
> (was: drm/ast: Move cursor vmap calls out of commit tail)
> 
> Ast has vmap calls in its cursor's atomic_update function. This is not
> supported as vmap might aquire the dma reservation lock. While at it,
> cleanup the whole cursor code: the patchset removes all possible runtime
> errors from the atomic_update function and reduces the overhead from
> vmap calls on the HW cursor BOs to a minimum.
> 
> Patches 1 to 3 update the cursor code and prepare before the refactoring.
> 
> Patch 4 and 5 inline the cursor update logic into the rsp cursor-plane
> functions. This is mostly about moving code around.
> 
> Patches 6 to 9 add a dedicated cursor plane that maintains the two BOs
> for HW cursors. The HW cursor BOs are permanently pinned and vmapped
> while the cursor plane is initialized. Thus removing the related vmap
> operations from atomic_update.
> 
> Finally patch 10 converts ast cursors to struct drm_shadow_plane_state.
> BOs with cursor image data from userspace are vmapped in prepare_fb and
> vunampped in cleanup_fb. The actual update of the cursor image is being
> moved from prepare_fb to atomic_update.
> 
> With the patchset applied, all cursor preparation is performed before
> the commit-tail functions; while the actual update is performed within.
> 
> Tested by running X11 and Weston on ast hardware.
> 
> v2:
> 	* convert to drm_shadow_plane_state helpers

Looks all sane to me.
Acked-by: Gerd Hoffmann <kraxel@redhat.com>