Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
> > > From: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > > 
> > > This was somehow lost between v3 and the merged version in Maarten's
> > > patch merged as:
> > > 
> > > commit f2d580b9a8149735cbc4b59c4a8df60173658140
> > > Author: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> > > Date:   Wed May 4 14:38:26 2016 +0200
> > > 
> > >     drm/core: Do not preserve framebuffer on rmfb, v4.
> > > 
> > > Actual code copied from Maarten's patch, but with the slight change to
> > > just use dev->mode_config.funcs->atomic_commit to decide whether to
> > > use the atomic path or not.
> > > 
> > > v2:
> > > - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> > > - Add WARN_ON when atomic_remove_fb fails.
> > > - Always call drm_atomic_state_put.
> > > 
> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> > 
> > Would be great if someone else could r-b this, I've proven pretty well
> > that I don't understand the complexity here :(
> > -Daniel
> 
> It looks like this will change the behavior slightly in that rmfb will
> cause primary planes to be disabled, but no longer cause the entire CRTC
> to be turned off.  You'll probably want to note that in the commit
> message, along with the justification on why this is okay ABI-wise.
> 
> I know that 13803132818c ("drm/core: Preserve the framebuffer after
> removing it.") was initially trying to not only leave the CRTC on, but
> also preserve the framebuffer and leave the planes on; that wound up
> causing some kind of regression for vmwgfx, but I'm unclear on the
> details there.  I'd suggest getting an Ack from one of the vmware guys
> to ensure that the less drastic change in behavior here won't cause them
> any problems.

Hm, this is a good point since with some atomic drivers (the ones using
the simple pipe helpers at least) disabling the primary plane alone
doesn't work. We might need a fallback path if the atomic_commit fails,
which also disables the crtc on top. I guess that needs to be address?

> Your code looks correct to me, so with an expanded commit message,
> 
> Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
> 
> General observation; we specifically test for the presence of
> mode_config->funcs.atomic_commit here rather than DRIVER_ATOMIC because
> we care about a driver's internal atomic plumbing rather than whether it
> exposes atomic to userspace or not.  I can see that causing confusion in
> the future, so I wonder if adding macros like
> DRM_SUPPORTS_ATOMIC_INTERNAL(dev) vs DRM_SUPPORTS_ATOMIC_USERSPACE(dev)
> might help overclarify exactly what/why we're testing in various places
> in the driver.

This already exists and is called drm_drv_uses_atomic_modeset(). Maarten,
can you pls update the patch?
-Daniel

> 
> 
> Matt
> 
> > 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c        | 64 +++++++++++++++++++++++++++++++++++++
> > >  drivers/gpu/drm/drm_crtc_internal.h |  1 +
> > >  drivers/gpu/drm/drm_framebuffer.c   |  7 ++++
> > >  3 files changed, 72 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index d1d252261bf1..23a3845542e1 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -2059,6 +2059,70 @@ static void complete_crtc_signaling(struct drm_device *dev,
> > >  	kfree(fence_state);
> > >  }
> > >  
> > > +int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> > > +{
> > > +	struct drm_modeset_acquire_ctx ctx;
> > > +	struct drm_device *dev = fb->dev;
> > > +	struct drm_atomic_state *state;
> > > +	struct drm_plane *plane;
> > > +	int ret = 0;
> > > +	unsigned plane_mask;
> > > +
> > > +	state = drm_atomic_state_alloc(dev);
> > > +	if (!state)
> > > +		return -ENOMEM;
> > > +
> > > +	drm_modeset_acquire_init(&ctx, 0);
> > > +	state->acquire_ctx = &ctx;
> > > +
> > > +retry:
> > > +	plane_mask = 0;
> > > +	ret = drm_modeset_lock_all_ctx(dev, &ctx);
> > > +	if (ret)
> > > +		goto unlock;
> > > +
> > > +	drm_for_each_plane(plane, dev) {
> > > +		struct drm_plane_state *plane_state;
> > > +
> > > +		if (plane->state->fb != fb)
> > > +			continue;
> > > +
> > > +		plane_state = drm_atomic_get_plane_state(state, plane);
> > > +		if (IS_ERR(plane_state)) {
> > > +			ret = PTR_ERR(plane_state);
> > > +			goto unlock;
> > > +		}
> > > +
> > > +		drm_atomic_set_fb_for_plane(plane_state, NULL);
> > > +		ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> > > +		if (ret)
> > > +			goto unlock;
> > > +
> > > +		plane_mask |= BIT(drm_plane_index(plane));
> > > +
> > > +		plane->old_fb = plane->fb;
> > > +	}
> > > +
> > > +	if (plane_mask)
> > > +		ret = drm_atomic_commit(state);
> > > +
> > > +unlock:
> > > +	if (plane_mask)
> > > +		drm_atomic_clean_old_fb(dev, plane_mask, ret);
> > > +
> > > +	if (ret == -EDEADLK) {
> > > +		drm_modeset_backoff(&ctx);
> > > +		goto retry;
> > > +	}
> > > +
> > > +	drm_atomic_state_put(state);
> > > +
> > > +	drm_modeset_drop_locks(&ctx);
> > > +	drm_modeset_acquire_fini(&ctx);
> > > +
> > > +	return ret;
> > > +}
> > > +
> > >  int drm_mode_atomic_ioctl(struct drm_device *dev,
> > >  			  void *data, struct drm_file *file_priv)
> > >  {
> > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h b/drivers/gpu/drm/drm_crtc_internal.h
> > > index cdf6860c9d22..121e250853d2 100644
> > > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > > @@ -178,6 +178,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
> > >  			    struct drm_property *property, uint64_t *val);
> > >  int drm_mode_atomic_ioctl(struct drm_device *dev,
> > >  			  void *data, struct drm_file *file_priv);
> > > +int drm_atomic_remove_fb(struct drm_framebuffer *fb);
> > >  
> > >  
> > >  /* drm_plane.c */
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > > index cbf0c893f426..c358bf8280a8 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -770,6 +770,12 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
> > >  	 * in this manner.
> > >  	 */
> > >  	if (drm_framebuffer_read_refcount(fb) > 1) {
> > > +		if (dev->mode_config.funcs->atomic_commit) {
> > > +			int ret = drm_atomic_remove_fb(fb);
> > > +			WARN(ret, "atomic remove_fb failed with %i\n", ret);
> > > +			goto out;
> > > +		}
> > > +
> > >  		drm_modeset_lock_all(dev);
> > >  		/* remove from any CRTC */
> > >  		drm_for_each_crtc(crtc, dev) {
> > > @@ -787,6 +793,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
> > >  		drm_modeset_unlock_all(dev);
> > >  	}
> > >  
> > > +out:
> > >  	drm_framebuffer_unreference(fb);
> > >  }
> > >  EXPORT_SYMBOL(drm_framebuffer_remove);
> > > -- 
> > > 2.7.4
> > > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux