All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH] drm/vmwgfx: Fix fbdev emulation using legacy functions
Date: Fri, 7 Apr 2017 10:31:29 +0200	[thread overview]
Message-ID: <8066e023-e77c-e618-8e78-3edf2565a44e@vmware.com> (raw)
In-Reply-To: <20170406200256.26040-1-daniel.vetter@ffwll.ch>

Hi, Daniel.

It appears to work fine. Thanks!

Do you want to take it through drm-misc or want me to take it throuch
vmwgfx-next?

Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
/Thomas



On 04/06/2017 10:02 PM, Daniel Vetter wrote:
> I've broken this by removing the backoff handling from the
> set_config2atomic helper in
>
> commit 38b6441e4e75c0b319cfe4d9364c1059fc1e3c2b
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Mar 22 22:50:58 2017 +0100
>
>     drm/atomic-helper: Remove the backoff hack from set_config
>
> Fixing this properly would mean we get to wire the acquire_ctx all the
> way through vmwgfx fbdev code, and doing the same was tricky for the
> shared fbdev layer. Probably much better to look into refactoring the
> entire code to use the helpers, but since that's not a viable
> long-term solution fix the issue by open-coding a vmwgfx version of
> set_config, that does the legacy backoff dance internally.
>
> Note: Just compile-tested. The idea is to take
> drm_mode_set_config_internal(), remove the "is this a legacy driver"
> check, and whack the drm_atomic_legacy_backoff trickery at the end.
> Since drm_atomic_legacy_backoff is for atomic commits only we need to
> open-code it.
>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 58 ++++++++++++++++++++++++++++++++++++--
>  1 file changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index 09e120d50e65..6f4cb4678cbc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -418,6 +418,60 @@ static int vmw_fb_compute_depth(struct fb_var_screeninfo *var,
>  	return 0;
>  }
>  
> +static int vmwgfx_set_config_internal(struct drm_mode_set *set)
> +{
> +	struct drm_crtc *crtc = set->crtc;
> +	struct drm_framebuffer *fb;
> +	struct drm_crtc *tmp;
> +	struct drm_modeset_acquire_ctx *ctx;
> +	struct drm_device *dev = set->crtc->dev;
> +	int ret;
> +
> +	ctx = dev->mode_config.acquire_ctx;
> +
> +restart:
> +	/*
> +	 * NOTE: ->set_config can also disable other crtcs (if we steal all
> +	 * connectors from it), hence we need to refcount the fbs across all
> +	 * crtcs. Atomic modeset will have saner semantics ...
> +	 */
> +	drm_for_each_crtc(tmp, dev)
> +		tmp->primary->old_fb = tmp->primary->fb;
> +
> +	fb = set->fb;
> +
> +	ret = crtc->funcs->set_config(set, ctx);
> +	if (ret == 0) {
> +		crtc->primary->crtc = crtc;
> +		crtc->primary->fb = fb;
> +	}
> +
> +	drm_for_each_crtc(tmp, dev) {
> +		if (tmp->primary->fb)
> +			drm_framebuffer_get(tmp->primary->fb);
> +		if (tmp->primary->old_fb)
> +			drm_framebuffer_put(tmp->primary->old_fb);
> +		tmp->primary->old_fb = NULL;
> +	}
> +
> +	if (ret == -EDEADLK) {
> +		dev->mode_config.acquire_ctx = NULL;
> +
> +retry_locking:
> +		drm_modeset_backoff(ctx);
> +
> +		ret = drm_modeset_lock_all_ctx(dev, ctx);
> +		if (ret)
> +			goto retry_locking;
> +
> +		dev->mode_config.acquire_ctx = ctx;
> +
> +		goto restart;
> +	}
> +
> +	return ret;
> +}
> +
>  static int vmw_fb_kms_detach(struct vmw_fb_par *par,
>  			     bool detach_bo,
>  			     bool unref_bo)
> @@ -436,7 +490,7 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
>  		set.fb = NULL;
>  		set.num_connectors = 0;
>  		set.connectors = &par->con;
> -		ret = drm_mode_set_config_internal(&set);
> +		ret = vmwgfx_set_config_internal(&set);
>  		if (ret) {
>  			DRM_ERROR("Could not unset a mode.\n");
>  			return ret;
> @@ -578,7 +632,7 @@ static int vmw_fb_set_par(struct fb_info *info)
>  	set.num_connectors = 1;
>  	set.connectors = &par->con;
>  
> -	ret = drm_mode_set_config_internal(&set);
> +	ret = vmwgfx_set_config_internal(&set);
>  	if (ret)
>  		goto out_unlock;
>  


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-04-07  8:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 20:02 [PATCH] drm/vmwgfx: Fix fbdev emulation using legacy functions Daniel Vetter
2017-04-07  8:31 ` Thomas Hellstrom [this message]
2017-04-07 14:54   ` Daniel Vetter
2017-04-07 17:34   ` Sean Paul
2017-06-21 13:30 ` Daniel Vetter
2017-06-26 12:25   ` Thomas Hellstrom

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=8066e023-e77c-e618-8e78-3edf2565a44e@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    /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.