All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Jouni Högander" <jouni.hogander@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Add new frontbuffer tracking interface to queue flush
Date: Mon, 28 Aug 2023 05:50:55 +0300	[thread overview]
Message-ID: <ZOwLj3AQJj0ahKdJ@intel.com> (raw)
In-Reply-To: <20230727053518.709345-4-jouni.hogander@intel.com>

On Thu, Jul 27, 2023 at 08:35:17AM +0300, Jouni Högander wrote:
> We want to wait dma fences in dirtyfb ioctl. As we don't want to make
> dirtyfb ioctl as blocking call we need to use
> dma_fence_add_callback. Callback used for dma_fence_add_callback is
> called from atomic context. Due to this we need to add a new
> frontbuffer tracking interface to queue flush.
> 
> v2: Check if flush work is already pending
> 
> Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
> ---
>  .../gpu/drm/i915/display/intel_frontbuffer.c  | 33 +++++++++++++++++++
>  .../gpu/drm/i915/display/intel_frontbuffer.h  |  4 +++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 17a7aa8b28c2..d33b6021d9ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> @@ -202,6 +202,39 @@ void __intel_fb_flush(struct intel_frontbuffer *front,
>  		frontbuffer_flush(i915, frontbuffer_bits, origin);
>  }
>  
> +static void intel_frontbuffer_flush_work(struct work_struct *work)
> +{
> +	struct intel_frontbuffer *front =
> +		container_of(work, struct intel_frontbuffer, flush_work);
> +
> +	i915_gem_object_flush_if_display(front->obj);
> +	intel_frontbuffer_flush(front, ORIGIN_DIRTYFB);
> +	intel_frontbuffer_put(front);
> +}
> +
> +/**
> + * intel_frontbuffer_queue_flush - queue flushing frontbuffer object
> + * @front: GEM object to flush
> + *
> + * This function is targeted for our dirty callback for queueing flush when
> + * dma fence is signales
> + */
> +void intel_frontbuffer_queue_flush(struct intel_frontbuffer *front)
> +{
> +	unsigned int frontbuffer_bits;
> +
> +	if (!front)
> +		return;
> +
> +	frontbuffer_bits = atomic_read(&front->bits);

I'm thinking we could check that already before we add the fence cb.

> +	if (!frontbuffer_bits || work_pending(&front->flush_work))

The work_pending() check is here to kep the kref in sync?
Maybe better to just use the return value of schedule_work() for
that?

> +		return;
> +
> +	kref_get(&front->ref);
> +	INIT_WORK(&front->flush_work, intel_frontbuffer_flush_work);

Don't we have a better place for the INIT_WORK() (eg. when we initialize
the intel_frontbuffer)?

> +	schedule_work(&front->flush_work);
> +}
> +
>  static int frontbuffer_active(struct i915_active *ref)
>  {
>  	struct intel_frontbuffer *front =
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.h b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
> index 3c474ed937fb..11760b5ce9fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
> @@ -47,6 +47,8 @@ struct intel_frontbuffer {
>  	struct i915_active write;
>  	struct drm_i915_gem_object *obj;
>  	struct rcu_head rcu;
> +
> +	struct work_struct flush_work;
>  };
>  
>  /*
> @@ -163,6 +165,8 @@ static inline void intel_frontbuffer_flush(struct intel_frontbuffer *front,
>  	__intel_fb_flush(front, origin, frontbuffer_bits);
>  }
>  
> +void intel_frontbuffer_queue_flush(struct intel_frontbuffer *front);
> +
>  void intel_frontbuffer_track(struct intel_frontbuffer *old,
>  			     struct intel_frontbuffer *new,
>  			     unsigned int frontbuffer_bits);
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2023-08-28  2:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27  5:35 [Intel-gfx] [PATCH v2 0/4] Handle dma fences in dirtyfb ioctl Jouni Högander
2023-07-27  5:35 ` [Intel-gfx] [PATCH v2 1/4] drm/i915/fbc: Clear frontbuffer busy bits on flip Jouni Högander
2023-07-27  5:35 ` [Intel-gfx] [PATCH v2 2/4] drm/i915/psr: " Jouni Högander
2023-07-27  5:35 ` [Intel-gfx] [PATCH v2 3/4] drm/i915: Add new frontbuffer tracking interface to queue flush Jouni Högander
2023-08-28  2:50   ` Ville Syrjälä [this message]
2023-07-27  5:35 ` [Intel-gfx] [PATCH v2 4/4] drm/i915: Handle dma fences in dirtyfb callback Jouni Högander
2023-08-29  9:30   ` Ville Syrjälä
2023-08-30  8:06     ` Hogander, Jouni
2023-07-27  5:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Handle dma fences in dirtyfb ioctl (rev2) Patchwork
2023-07-27  6:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-27  7:38 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-07-27 20:50 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Handle dma fences in dirtyfb ioctl (rev3) Patchwork
2023-07-27 20:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-07-28  2:41 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=ZOwLj3AQJj0ahKdJ@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jouni.hogander@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.