From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2
Date: Tue, 24 Jan 2017 13:44:54 -0800 [thread overview]
Message-ID: <20170124214454.GJ15212@intel.com> (raw)
In-Reply-To: <20170111161547.lfbt7e6kybimy625@phenom.ffwll.local>
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@ffwll.ch>
> >
> > This was somehow lost between v3 and the merged version in Maarten's
> > patch merged as:
> >
> > commit f2d580b9a8149735cbc4b59c4a8df60173658140
> > Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > 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@intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>
> 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.
Your code looks correct to me, so with an expanded commit message,
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
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.
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-01-24 21:44 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-15 14:29 [PATCH 0/4] drm: Resurrect atomic rmfb code Maarten Lankhorst
2016-12-15 14:29 ` [PATCH 1/4] drm/atomic: Delete wrong comment Maarten Lankhorst
2016-12-15 15:19 ` [Intel-gfx] " Daniel Vetter
2017-01-04 11:15 ` [PATCH] drm/atomic: Fix outdated comment Maarten Lankhorst
2017-01-04 11:22 ` Chris Wilson
2017-01-04 11:28 ` Daniel Vetter
2017-01-04 11:34 ` [PATCH v2] " Maarten Lankhorst
2017-01-04 15:41 ` Daniel Vetter
2016-12-15 14:29 ` [PATCH 2/4] drm/i915: Fix POWER_DOMAIN_AUDIO refcounting Maarten Lankhorst
2017-01-11 16:13 ` Daniel Vetter
2017-01-16 11:00 ` Maarten Lankhorst
2017-01-23 7:43 ` [Intel-gfx] " Daniel Vetter
2016-12-15 14:29 ` [PATCH 3/4] drm/i915: Disable all crtcs during driver unload Maarten Lankhorst
2017-01-11 16:15 ` Daniel Vetter
2016-12-15 14:29 ` [PATCH 4/4] drm: Resurrect atomic rmfb code, v2 Maarten Lankhorst
2017-01-11 16:15 ` Daniel Vetter
2017-01-24 21:44 ` Matt Roper [this message]
2017-01-25 4:54 ` Daniel Vetter
2017-01-25 8:09 ` Thomas Hellstrom
2017-01-25 8:36 ` Maarten Lankhorst
2017-01-25 18:05 ` Sinclair Yeh
2017-01-26 9:55 ` Maarten Lankhorst
2017-01-26 18:39 ` Sinclair Yeh
2017-02-09 12:29 ` Maarten Lankhorst
2017-02-09 15:58 ` Sinclair Yeh
2017-01-25 11:30 ` [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3 Maarten Lankhorst
2017-02-15 13:56 ` Jani Nikula
2017-02-15 16:28 ` [Intel-gfx] " Sinclair Yeh
2017-02-16 9:45 ` Jani Nikula
2017-02-16 11:00 ` [Intel-gfx] " Maarten Lankhorst
2016-12-15 16:23 ` ✗ Fi.CI.BAT: warning for drm: Resurrect atomic rmfb code Patchwork
2016-12-15 16:25 ` Maarten Lankhorst
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=20170124214454.GJ15212@intel.com \
--to=matthew.d.roper@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thellstrom@vmware.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;
as well as URLs for NNTP newsgroup(s).