From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 7/7] drm: Resurrect atomic rmfb code
Date: Mon, 12 Dec 2016 10:23:08 +0100 [thread overview]
Message-ID: <20161212092308.nd2mzlgszk2jhtcn@phenom.ffwll.local> (raw)
In-Reply-To: <cf6b933e-dd9d-76b2-394b-ba9ba37ae3e5@linux.intel.com>
On Mon, Dec 12, 2016 at 09:46:59AM +0100, Maarten Lankhorst wrote:
> Op 09-12-16 om 21:59 schreef Daniel Vetter:
> > On Fri, Dec 09, 2016 at 03:19:44PM +0100, Daniel Vetter wrote:
> >> 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.
> >>
> >> FIXME: This seems to break audio rpm refcounting somehow! See:
> >>
> >> commit 0dcac5008fcf57cce66ef091204efbde86956c7a
> >> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> Date: Thu Jul 14 15:16:34 2016 +0200
> >>
> >> Revert "drm: Resurrect atomic rmfb code"
> >>
> >> v2: Use new atomic state refcounting.
> >>
> >> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> Link: http://patchwork.freedesktop.org/patch/msgid/1465388359-8070-24-git-send-email-daniel.vetter@ffwll.ch
> > intel-gfx CI told me this breaks the world. I guess back to the drawing
> > board.
> What happens when we add an argument to __drm_framebuffer_remove whether
> crtc has to be disabled or not, and make drm_framebuffer_remove always
> say it has to disable crtc, while being called from rmfb_work_fn tries
> to keep crtc enabled?
tbh I'm not sure what the regression this time around was. But I guess
long-term we want some kind of atomic rmfb, since iirc it blocks the
re-adding of ww_acquire_done? I've thrown this patch out of my pile for
now, got burned too often ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-12-12 9:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 14:19 [PATCH 1/7] drm/hisilicon: Don't set drm_device->platformdev Daniel Vetter
2016-12-09 14:19 ` [PATCH 2/7] drm: Protect master->unique with dev->master_mutex Daniel Vetter
2016-12-09 14:54 ` Emil Velikov
2016-12-09 15:31 ` Daniel Vetter
2016-12-09 14:19 ` [PATCH 3/7] drm: setclientcap doesn't need the drm BKL Daniel Vetter
2016-12-09 14:19 ` [PATCH 4/7] drm: Enforce BKL-less ioctls for modern drivers Daniel Vetter
2016-12-09 14:19 ` [PATCH 5/7] drm: Don't compute obj counts expensively in get_resources Daniel Vetter
2016-12-09 21:47 ` Chris Wilson
2016-12-09 22:25 ` Daniel Vetter
2016-12-09 14:19 ` [PATCH 6/7] drm: Don't walk fb list twice in getresources Daniel Vetter
2016-12-09 21:57 ` Chris Wilson
2016-12-10 21:30 ` [Intel-gfx] " Daniel Vetter
2016-12-09 14:19 ` [PATCH 7/7] drm: Resurrect atomic rmfb code Daniel Vetter
2016-12-09 20:59 ` Daniel Vetter
2016-12-12 8:46 ` Maarten Lankhorst
2016-12-12 9:23 ` Daniel Vetter [this message]
2016-12-09 15:27 ` ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/hisilicon: Don't set drm_device->platformdev Patchwork
2016-12-09 20:59 ` Daniel Vetter
2016-12-09 18:04 ` [PATCH 1/7] " Sean Paul
2016-12-13 9:20 ` 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=20161212092308.nd2mzlgszk2jhtcn@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.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 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.