All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Thierry Reding <treding@nvidia.com>,
	Peter Rosin <peda@axentia.se>
Subject: Re: [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths
Date: Thu, 29 Jun 2017 12:22:25 +0200	[thread overview]
Message-ID: <28764010-74e0-5049-ee9c-9ddc944efb20@linux.intel.com> (raw)
In-Reply-To: <20170627145936.18983-10-daniel.vetter@ffwll.ch>

Op 27-06-17 om 16:59 schreef Daniel Vetter:
> Like with panning and modesetting, and like with those, stick with
> simple drm_modeset_locking_all for the legacy path, and the full
> atomic dance for atomic drivers.
>
> This means a bit more boilerplate since setting up the atomic state
> machinery is rather verbose, but then this is shared code for 30+
> drivers or so, so meh.
>
> After this patch there's only the LUT/cmap path which is still using
> drm_modeset_lock_all for an atomic driver. But Peter is already
> locking into reworking that, so I'll leave that code as-is for now.
>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 88 +++++++++++++++++++++++++++++++++++------
>  1 file changed, 76 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 59e2916471b2..bbd4c6d0378d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -616,23 +616,13 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = {
>  static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
>  #endif
>  
> -static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
> +static void dpms_legacy(struct drm_fb_helper *fb_helper, int dpms_mode)
>  {
> -	struct drm_fb_helper *fb_helper = info->par;
>  	struct drm_device *dev = fb_helper->dev;
>  	struct drm_crtc *crtc;
>  	struct drm_connector *connector;
>  	int i, j;
>  
> -	/*
> -	 * For each CRTC in this fb, turn the connectors on/off.
> -	 */
> -	mutex_lock(&fb_helper->lock);
> -	if (!drm_fb_helper_is_bound(fb_helper)) {
> -		mutex_unlock(&fb_helper->lock);
> -		return;
> -	}
> -
>  	drm_modeset_lock_all(dev);
>  	for (i = 0; i < fb_helper->crtc_count; i++) {
>  		crtc = fb_helper->crtc_info[i].mode_set.crtc;
> @@ -649,6 +639,81 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
>  		}
>  	}
>  	drm_modeset_unlock_all(dev);
> +}
> +
> +static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode)
> +{
> +	struct drm_device *dev = fb_helper->dev;
> +	struct drm_atomic_state *state;
> +	int i, ret;
> +
> +	struct drm_modeset_acquire_ctx ctx;
> +
> +	drm_modeset_acquire_init(&ctx, 0);
> +
> +	state = drm_atomic_state_alloc(dev);
> +	if (!state) {
> +		ret = -ENOMEM;
> +		goto out_ctx;
> +	}
> +
> +	state->acquire_ctx = &ctx;
> +retry:
> +	for (i = 0; i < fb_helper->crtc_count; i++) {
> +		struct drm_crtc_state *crtc_state;
> +		struct drm_crtc *crtc;
> +
> +		if (!fb_helper->crtc_info[i].mode_set.mode)
> +			continue;
> +
> +		crtc = fb_helper->crtc_info[i].mode_set.crtc;
> +
> +		crtc_state = drm_atomic_get_crtc_state(state, crtc);
> +		if (IS_ERR(crtc_state)) {
> +			ret = PTR_ERR(crtc_state);
> +			goto out_state;
> +		}
Hm, maybe remove the early continue, and change this to if (crtc_state->enable) crtc_state->active = ...; ?

I don't know if it matters in practice, but it might be more resilient when crtc state does not match our expected state,
similar to how DPMS on is ignored without CRTC.
> +		crtc_state->active = dpms_mode == DRM_MODE_DPMS_ON;
> +	}
> +
> +	ret = drm_atomic_commit(state);
> +out_state:
> +	if (ret == -EDEADLK)
> +		goto backoff;
> +
> +	drm_atomic_state_put(state);
> +out_ctx:
> +	drm_modeset_drop_locks(&ctx);
> +	drm_modeset_acquire_fini(&ctx);
> +
> +	return;
> +
> +backoff:
> +	drm_atomic_state_clear(state);
> +	drm_modeset_backoff(&ctx);
> +
> +	goto retry;
> +
> +}
> +
> +static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
> +{
> +	struct drm_fb_helper *fb_helper = info->par;
> +
> +	/*
> +	 * For each CRTC in this fb, turn the connectors on/off.
> +	 */
> +	mutex_lock(&fb_helper->lock);
> +	if (!drm_fb_helper_is_bound(fb_helper)) {
> +		mutex_unlock(&fb_helper->lock);
> +		return;
> +	}
> +
> +	if (drm_drv_uses_atomic_modeset(fb_helper->dev))
> +		dpms_atomic(fb_helper, dpms_mode);
> +	else
> +		dpms_legacy(fb_helper, dpms_mode);
>  	mutex_unlock(&fb_helper->lock);
>  }
>  
> @@ -2467,7 +2532,6 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>   */
>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
>  {
> -	struct drm_device *dev = fb_helper->dev;
>  	int err = 0;
>  
>  	if (!drm_fbdev_emulation)


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-06-29 10:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 14:59 [PATCH 00/13] fbdev locking rework and deferred setup, take 2 Daniel Vetter
2017-06-27 14:59 ` [PATCH 01/13] drm/fb-helper: Push down modeset lock into FB helpers Daniel Vetter
2017-06-29  9:10   ` Maarten Lankhorst
2017-06-29  9:23     ` Daniel Vetter
2017-06-29  9:33       ` Maarten Lankhorst
2017-06-29  9:44         ` Daniel Vetter
2017-06-29 11:13           ` Maarten Lankhorst
2017-06-29 12:38             ` Daniel Vetter
2017-06-27 14:59 ` [PATCH 02/13] drm/i915: Drop FBDEV #ifdev in mst code Daniel Vetter
2017-06-27 14:59 ` [PATCH 03/13] drm/fb-helper: Add top-level lock Daniel Vetter
2017-06-27 14:59 ` [PATCH 04/13] drm/fb-helper: Push locking in fb_is_bound Daniel Vetter
2017-06-27 14:59 ` [PATCH 05/13] drm/fb-helper: Drop locking from the vsync wait ioctl code Daniel Vetter
2017-06-27 14:59 ` [PATCH 06/13] drm/fb-helper: Push locking into pan_display_atomic|legacy Daniel Vetter
2017-06-27 14:59 ` [PATCH 07/13] drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy Daniel Vetter
2017-06-27 14:59 ` [PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals Daniel Vetter
2017-06-27 14:59 ` [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths Daniel Vetter
2017-06-29 10:22   ` Maarten Lankhorst [this message]
2017-06-29 10:31     ` Daniel Vetter
2017-06-29 10:58       ` Maarten Lankhorst
2017-06-29 11:00         ` Daniel Vetter
2017-06-29 11:23           ` Maarten Lankhorst
2017-06-27 14:59 ` [PATCH 10/13] drm/fb-helper: Support deferred setup Daniel Vetter
2017-06-28 11:32   ` [PATCH] " Daniel Vetter
2017-06-28 16:24     ` Liviu Dudau
2017-06-29 10:59     ` Maarten Lankhorst
2017-06-29 12:36       ` Daniel Vetter
2017-06-30 16:51     ` [PATCH] drm/fb-helper: Restore first connection behaviour on " Liviu Dudau
2017-06-30 18:13       ` Daniel Vetter
2017-07-03  8:44         ` Liviu Dudau
2017-07-03 16:33           ` Daniel Vetter
2017-06-27 14:59 ` [PATCH 11/13] drm/exynos: Remove custom FB helper " Daniel Vetter
2017-06-27 14:59 ` [PATCH 12/13] drm/hisilicon: " Daniel Vetter
2017-06-28  9:08   ` [PATCH] " Daniel Vetter
2017-06-27 14:59 ` [PATCH 13/13] drm/atomic-helper: Realign function parameters Daniel Vetter
2017-06-27 15:01   ` Deucher, Alexander
2017-06-27 15:42   ` Harry Wentland
2017-07-04 15:16     ` Daniel Vetter
2017-06-27 15:30 ` ✓ Fi.CI.BAT: success for fbdev locking rework and deferred setup, take 2 Patchwork
2017-06-27 23:02 ` [PATCH 00/13] " John Stultz
2017-06-28  7:36   ` Daniel Vetter
2017-06-28  9:28 ` ✓ Fi.CI.BAT: success for fbdev locking rework and deferred setup, take 2 (rev2) Patchwork
2017-06-28 12:28 ` ✓ Fi.CI.BAT: success for fbdev locking rework and deferred setup, take 2 (rev3) Patchwork
2017-07-04 15:18 [PATCH 00/13] fbdev locking + deferred setup take 3 Daniel Vetter
2017-07-04 15:18 ` [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths Daniel Vetter

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=28764010-74e0-5049-ee9c-9ddc944efb20@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=peda@axentia.se \
    --cc=treding@nvidia.com \
    --subject='Re: [PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths' \
    /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

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.