dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Jyri Sarha <jsarha@ti.com>
Cc: tomi.valkeinen@ti.com, dri-devel@lists.freedesktop.org,
	laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v2] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc()
Date: Mon, 30 Nov 2015 08:38:28 +0100	[thread overview]
Message-ID: <20151130073828.GD17050@phenom.ffwll.local> (raw)
In-Reply-To: <1448633641-6486-1-git-send-email-jsarha@ti.com>

On Fri, Nov 27, 2015 at 04:14:01PM +0200, Jyri Sarha wrote:
> Add drm_atomic_helper_disable_planes_on_crtc() for disabling all
> planes associated with the given CRTC. This can be used for instance
> in the CRTC helper disable callback to disable all planes before
> shutting down the display pipeline.
> 
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> v2:
> - Address Daniels review comments [1]
>   - Do atomic_begin() and atomic_flush() always if they are defined and
>     atomic knob is set
>   - update kerneldoc
> - Put drm_atomic_helper_disable_planes_on_crtc() after
>   drm_atomic_helper_commit_planes_on_crtc() in drm_atomic_helper.c 
>   to have functions in the same order as in drm_atomic_helper.h
>  
> Here the patch is again with latest review comment addressed, however
> I am not sure if we are going use the drm_atomic_helper_disable_planes_on_crtc()
> in omapdrm.
> 
> BTW, the latest change to this patch makes me wonder a how the
> atomic_begin() and atomic_flush() are supposed to work. 
> 
> 1. Should it be allowed to call atomic_begin() and atomic_flush()
> multiple times in a recursive manner?

No. Since the idea is to call this new disable_planes_on_crtc from
crtc_funcs->disable, which is called from commit_disables() there's not
problem. atomic_begin/end is just for plane updates (not for
enabling/disabling the entire display pipeline), and that's done with the
various commit_planes()/on_crtc() functions.

> If yes, how should the driver cope with that? Keep refcount of
> atomic_begins and do the magic only after the final matching
> atomic_flush comes and the refcount reaches zero?
> 
> 2. What about calling them consecutively (but not recursively)
> multiple times without vblank happening in the middle?
> 
> I am afraid that the current omapdrm implementation does not cope too
> well in either situation.

Currently atomic updates should only happen once per vblank (there's
planes for benchmark mode where we want to flip faster). Maybe just add a
drm_crtc_wait_one_vblank() call after calling this in your crtc_disable
functions?

Anyway, patch looks great, applied to drm-misc.

Thanks, Daniel

> 
> Cheers,
> Jyri
> 
> [1] http://www.spinics.net/lists/dri-devel/msg94942.html
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 43 +++++++++++++++++++++++++++++++++++++
>  include/drm/drm_atomic_helper.h     |  2 ++
>  2 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 0c6f621..1ab6821 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1334,6 +1334,49 @@ drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state *old_crtc_state)
>  EXPORT_SYMBOL(drm_atomic_helper_commit_planes_on_crtc);
>  
>  /**
> + * drm_atomic_helper_disable_planes_on_crtc - helper to disable CRTC's planes
> + * @crtc: CRTC
> + * @atomic: if set, synchronize with CRTC's atomic_begin/flush hooks
> + *
> + * Disables all planes associated with the given CRTC. This can be
> + * used for instance in the CRTC helper disable callback to disable
> + * all planes before shutting down the display pipeline.
> + *
> + * If the atomic-parameter is set the function calls the CRTC's
> + * atomic_begin hook before and atomic_flush hook after disabling the
> + * planes.
> + *
> + * It is a bug to call this function without having implemented the
> + * ->atomic_disable() plane hook.
> + */
> +void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
> +					      bool atomic)
> +{
> +	const struct drm_crtc_helper_funcs *crtc_funcs =
> +		crtc->helper_private;
> +	struct drm_plane *plane;
> +
> +	if (atomic && crtc_funcs && crtc_funcs->atomic_begin)
> +		crtc_funcs->atomic_begin(crtc, NULL);
> +
> +	drm_for_each_plane(plane, crtc->dev) {
> +		const struct drm_plane_helper_funcs *plane_funcs =
> +			plane->helper_private;
> +
> +		if (plane->state->crtc != crtc || !plane_funcs)
> +			continue;
> +
> +		WARN_ON(!plane_funcs->atomic_disable);
> +		if (plane_funcs->atomic_disable)
> +			plane_funcs->atomic_disable(plane, NULL);
> +	}
> +
> +	if (atomic && crtc_funcs && crtc_funcs->atomic_flush)
> +		crtc_funcs->atomic_flush(crtc, NULL);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_disable_planes_on_crtc);
> +
> +/**
>   * drm_atomic_helper_cleanup_planes - cleanup plane resources after commit
>   * @dev: DRM device
>   * @old_state: atomic state object with old state structures
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 8cba54a..b7d4237 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -62,6 +62,8 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,
>  void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
>  				      struct drm_atomic_state *old_state);
>  void drm_atomic_helper_commit_planes_on_crtc(struct drm_crtc_state *old_crtc_state);
> +void drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc *crtc,
> +					      bool atomic);
>  
>  void drm_atomic_helper_swap_state(struct drm_device *dev,
>  				  struct drm_atomic_state *state);
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2015-11-30  7:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 14:14 [PATCH v2] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc() Jyri Sarha
2015-11-30  7:38 ` Daniel Vetter [this message]

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=20151130073828.GD17050@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=tomi.valkeinen@ti.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