From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Engestrom <eric.engestrom@imgtec.com>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
dczaplejewicz@collabora.co.uk,
"Kristian Høgsberg" <hoegsberg@gmail.com>,
dri-devel@lists.freedesktop.org,
"Ben Widawsky" <benjamin.widawsky@intel.com>
Subject: Re: [RFC][PATCH] drm: Nuke modifier[1-3]
Date: Wed, 16 Nov 2016 14:33:09 +0200 [thread overview]
Message-ID: <20161116123309.GP31595@intel.com> (raw)
In-Reply-To: <20161116121042.GI1423@imgtec.com>
On Wed, Nov 16, 2016 at 12:10:42PM +0000, Eric Engestrom wrote:
> On Wednesday, 2016-11-16 13:33:16 +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > It has been suggested that having per-plane modifiers is making life
> > more difficult for userspace, so let's just retire modifier[1-3] and
> > use modifier[0] to apply to the entire framebuffer.
> >
> > Obviosuly this means that if individual planes need different tiling
> > layouts and whatnot we will need a new modifier for each combination
> > of planes with different tiling layouts.
> >
> > For a bit of extra backwards compatilbilty the kernel will allow
> > non-zero modifier[1+] but it require that they will match modifier[0].
> > This in case there's existing userspace out there that sets
> > modifier[1+] to something non-zero with planar formats.
> >
> > Mostly a cocci job, with a bit of manual stuff mixed in.
> >
> > @@
> > struct drm_framebuffer *fb;
> > expression E;
> > @@
> > - fb->modifier[E]
> > + fb->modifier
> >
> > @@
> > struct drm_framebuffer fb;
> > expression E;
> > @@
> > - fb.modifier[E]
> > + fb.modifier
> >
> > Cc: Kristian Høgsberg <hoegsberg@gmail.com>
> > Cc: Ben Widawsky <benjamin.widawsky@intel.com>
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>
> > Cc: dczaplejewicz@collabora.co.uk
> > Suggested-by: Kristian Høgsberg <hoegsberg@gmail.com>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 2 +-
> > drivers/gpu/drm/drm_framebuffer.c | 7 +++
> > drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +-
> > drivers/gpu/drm/i915/intel_display.c | 72 +++++++++++++++----------------
> > drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> > drivers/gpu/drm/i915/intel_pm.c | 22 +++++-----
> > drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 2 +-
> > include/drm/drm_framebuffer.h | 4 +-
> > include/uapi/drm/drm_mode.h | 13 +++---
> > 12 files changed, 79 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 57e0a6e96f6d..bfaa6e4a9989 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -922,12 +922,12 @@ static void drm_atomic_plane_print_state(struct drm_printer *p,
> >
> > drm_printf(p, "\t\tformat=%s\n",
> > drm_get_format_name(fb->pixel_format, &format_name));
> > + drm_printf(p, "\t\t\tmodifier=0x%llx\n", fb->modifier);
> > drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
> > drm_printf(p, "\t\tlayers:\n");
> > for (i = 0; i < n; i++) {
> > drm_printf(p, "\t\t\tpitch[%d]=%u\n", i, fb->pitches[i]);
> > drm_printf(p, "\t\t\toffset[%d]=%u\n", i, fb->offsets[i]);
> > - drm_printf(p, "\t\t\tmodifier[%d]=0x%llx\n", i, fb->modifier[i]);
> > }
> > }
> > drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG(&dest));
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > index 06ad3d1350c4..cbf0c893f426 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -177,6 +177,13 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
> > return -EINVAL;
> > }
> >
> > + if (r->flags & DRM_MODE_FB_MODIFIERS &&
>
> + r->modifier[i] &&
>
> Otherwise this forces the modifiers to be set for all planes, doesn't it?
All planes up to num_planes, which is exactly what we want.
>
> > + r->modifier[i] != r->modifier[0]) {
> > + DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
> > + r->modifier[i], i);
> > + return -EINVAL;
> > + }
> > +
> > /* modifier specific checks: */
> > switch (r->modifier[i]) {
> > case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-11-16 12:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 11:33 [RFC][PATCH] drm: Nuke modifier[1-3] ville.syrjala
2016-11-16 12:10 ` Eric Engestrom
2016-11-16 12:33 ` Ville Syrjälä [this message]
2016-11-16 13:04 ` Rob Clark
2016-11-16 14:43 ` Ville Syrjälä
2016-11-16 14:54 ` Daniel Vetter
2016-11-16 15:08 ` Rob Clark
2016-11-16 15:30 ` Ben Widawsky
2016-11-16 15:36 ` Daniel Stone
2016-11-17 10:59 ` 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=20161116123309.GP31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=benjamin.widawsky@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dczaplejewicz@collabora.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric.engestrom@imgtec.com \
--cc=hoegsberg@gmail.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).