Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use vblank worker to unpin old legacy cursor fb safely
Date: Fri, 1 Sep 2023 12:16:21 +0200	[thread overview]
Message-ID: <5b340552-e09b-48cb-0677-7f65f24ee6ce@linux.intel.com> (raw)
In-Reply-To: <20230831162643.20354-1-ville.syrjala@linux.intel.com>

Hey,


Den 2023-08-31 kl. 18:26, skrev Ville Syrjala:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The cursor hardware only does sync updates, and thus the hardware
> will be scanning out from the old fb until the next start of vblank.
> So in order to make the legacy cursor fastpath actually safe we
> should not unpin the old fb until we're sure the hardware has
> ceased accessing it. The simplest approach is to just use a vblank
> work here to do the delayed unpin.
>
> Not 100% sure it's a good idea to put this onto the same high
> priority vblank worker as eg. our timing critical gamma updates.
> But let's keep it simple for now, and it we later discover that
> this is causing problems we can think about adding a lower
> priority worker for such things.
>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>   drivers/gpu/drm/i915/display/intel_cursor.c   | 25 +++++++++++++++++--
>   .../drm/i915/display/intel_display_types.h    |  3 +++
>   2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c
> index b342fad180ca..2bd1a79c6955 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -603,6 +603,16 @@ static bool intel_cursor_format_mod_supported(struct drm_plane *_plane,
>   	return format == DRM_FORMAT_ARGB8888;
>   }
>   
> +static void intel_cursor_unpin_work(struct kthread_work *base)
> +{
> +	struct drm_vblank_work *work = to_drm_vblank_work(base);
> +	struct intel_plane_state *plane_state =
> +		container_of(work, typeof(*plane_state), unpin_work);
> +
> +	intel_plane_unpin_fb(plane_state);
> +	intel_plane_destroy_state(plane_state->uapi.plane, &plane_state->uapi);
> +}
> +
>   static int
>   intel_legacy_cursor_update(struct drm_plane *_plane,
>   			   struct drm_crtc *_crtc,
> @@ -730,14 +740,25 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>   
>   	local_irq_enable();
>   
> -	intel_plane_unpin_fb(old_plane_state);
> +	if (old_plane_state->hw.fb != new_plane_state->hw.fb) {
> +		drm_vblank_work_init(&old_plane_state->unpin_work, &crtc->base,
> +				     intel_cursor_unpin_work);
> +
> +		drm_vblank_work_schedule(&old_plane_state->unpin_work,
> +					 drm_crtc_accurate_vblank_count(&crtc->base) + 1,
> +					 false);
> +
> +		old_plane_state = NULL;
> +	} else {
> +		intel_plane_unpin_fb(old_plane_state);
> +	}

Maybe check if crtc is active and no modeset is happening? Similar to 
how the vblank worker is used in other cases. That should hopefully fix 
the cursor leak test.

Cheers,

~Maarten


  parent reply	other threads:[~2023-09-01 10:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-31 16:26 [Intel-gfx] [PATCH] drm/i915: Use vblank worker to unpin old legacy cursor fb safely Ville Syrjala
2023-09-01  0:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-09-01  5:26 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-09-01 10:16 ` Maarten Lankhorst [this message]
2023-09-01 10:56   ` [Intel-gfx] [PATCH] " Ville Syrjälä
2023-09-12 19:44     ` Maarten Lankhorst

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b340552-e09b-48cb-0677-7f65f24ee6ce@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox