From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm: Make sure at least one plane supports the fb format
Date: Thu, 15 Mar 2018 20:48:17 +0200 [thread overview]
Message-ID: <20180315184817.GC5453@intel.com> (raw)
In-Reply-To: <20180315180344.GA5453@intel.com>
On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
> > > Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> > >
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > >
> > > > To make life easier for drivers, let's have the core check that the
> > > > requested pixel format is supported by at least one plane when creating
> > > > a new framebuffer.
> > > >
> > > > This eases the burden on drivers by making sure they'll never get
> > > > requests to create fbs with unsupported pixel formats. Thanks to the
> > > > new .fb_modifier() hook this check can now be done whether the request
> > > > specifies the modifier directly or driver has to deduce it from the
> > > > gem bo tiling (or via any other method really).
> > > >
> > > > v0: Accept anyformat if the driver doesn't do planes (Eric)
> > > > s/planes_have_format/any_plane_has_format/ (Eric)
> > > > Check the modifier as well since we already have a function
> > > > that does both
> > > > v3: Don't do the check in the core since we may not know the
> > > > modifier yet, instead export the function and let drivers
> > > > call it themselves
> > > > v4: Unexport the functiona and put the format_default check back
> > > > since this will again be called by the core, ie. undo v3 ;)
> > > >
> > > > Cc: Eric Anholt <eric@anholt.net>
> > > > Testcase: igt/kms_addfb_basic/expected-formats
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > > drivers/gpu/drm/drm_framebuffer.c | 30 ++++++++++++++++++++++++++++++
> > > > 1 file changed, 30 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c
> > > > index 21d3d51eb261..e618a6b728d4 100644
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -152,6 +152,26 @@ static int fb_plane_height(int height,
> > > > return DIV_ROUND_UP(height, format->vsub);
> > > > }
> > > >
> > > > +static bool any_plane_has_format(struct drm_device *dev,
> > > > + u32 format, u64 modifier)
> > > > +{
> > > > + struct drm_plane *plane;
> > > > +
> > > > + drm_for_each_plane(plane, dev) {
> > > > + /*
> > > > + * In case the driver doesn't really do
> > > > + * planes we have to accept any format here.
> > > > + */
> > > > + if (plane->format_default)
> > > > + return true;
> > > > +
> > > > + if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
> > > > + return true;
> > > > + }
> > > > +
> > > > + return false;
> > > > +}
> > >
> > > This drm_plane_check_pixel_format() will always fail for VC4's SAND
> > > modifiers or VC5's UIF modifiers, where we're using the middle 48 bits
> > > as a bit of metadata (like how we have horizontal stride passed outside
> > > of the modifier) and you can't list all of the possible values in an
> > > array on the plane.
> >
> > Hmm. drm_atomic_plane_check() etc. call this thing as well. How does
> > that manage to work currently?
>
> Maybe it doesn't. I added the modifier checks in
>
> commit 23163a7d4b032489d375099d56571371c0456980
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> AuthorDate: Fri Dec 22 21:22:30 2017 +0200
> Commit: Ville Syrjälä <ville.syrjala@linux.intel.com>
> CommitDate: Mon Feb 26 16:29:47 2018 +0200
>
> drm: Check that the plane supports the request format+modifier combo
>
> Maybe that broke vc4?
>
> Hmm. So either we need to stop checking against the modifiers array and
> rely purely or .format_mod_supported(), or we need to somehow get the
> driver to reduce the modifier to its base form. I guess we could make
> .fb_modifier() do that and call it also for addfb with modifiers. And
> I'd need to undo some of the modifier[0] vs. deduced modifier changes
> I did to framebuffer_check(), and we'd need to preserve the original
> modifier in the request for .fb_create(). Oh, but that wouldn't allow
> returning a non-base modifier from .fb_modifuer() for the !modifiers
> case. This is turning slightly more tricky than I had hoped...
>
> I guess relying on .format_mod_supported() might be what we need to
> do. Unfortunately it does mean that the .format_mod_supported()
> implementations must be prepared for modifiers that were not
> registered with the plane. Which does feel quite a bit more
> fragile.
And that last apporach would be annoying for i915. So I think the other
apporach is better.
Fortunately it seems your SAND modifiers aren't upstream yet so I didn't
break them :) I had a quick look at your github and it looks like the
first apporach would work.
Something like this is what I had in mind. Loosk like you could plug in
fourcc_mod_broadcom_mod() almost directly into .base_modifier().
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7e8a37..250f66d51c2c 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -552,6 +552,8 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
int drm_plane_check_pixel_format(struct drm_plane *plane,
u32 format, u64 modifier)
{
+ struct drm_device *dev = plane->dev;
+ u64 base_modifier;
unsigned int i;
for (i = 0; i < plane->format_count; i++) {
@@ -564,8 +566,13 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
if (!plane->modifier_count)
return 0;
+ if (dev->mode_config.funcs->base_modifier)
+ base_modifier = dev->mode_config.funcs->base_modifier(dev, modifier);
+ else
+ base_modifier = modifier;
+
for (i = 0; i < plane->modifier_count; i++) {
- if (modifier == plane->modifiers[i])
+ if (base_modifier == plane->modifiers[i])
break;
}
if (i == plane->modifier_count)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index c74aed292b58..2ff2438263ef 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -45,6 +45,19 @@ struct drm_display_mode;
* involve drivers.
*/
struct drm_mode_config_funcs {
+ /**
+ * @base_modifier:
+ *
+ * Reduce the passed in modifier to its base form. This optional
+ * hook needs to be provided by any driver that embeds extra
+ * metadata within the format modifier.
+ *
+ * RETURNS:
+ * The base form of the modifier with any extra metadata
+ * cleared out.
+ */
+ u64 (*base_modifier)(struct drm_device *dev, u64 modifier);
+
/**
* @fb_modifier:
*
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..5e26d2a5f6ab 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -489,8 +489,6 @@ enum drm_plane_type {
* @format_types: array of formats supported by this plane
* @format_count: number of formats supported
* @format_default: driver hasn't supplied supported formats for the plane
- * @modifiers: array of modifiers supported by this plane
- * @modifier_count: number of modifiers supported
* @old_fb: Temporary tracking of the old fb while a modeset is ongoing. Used by
* drm_mode_set_config_internal() to implement correct refcounting.
* @funcs: helper functions
@@ -524,7 +522,15 @@ struct drm_plane {
unsigned int format_count;
bool format_default;
+ /**
+ * @modifiers: Array of modifiers supported by this plane. If
+ * the driver embeds any extra metadata within modifiers these
+ * modifiers must be in their base form.
+ */
uint64_t *modifiers;
+ /**
+ * @modifier_count: number of modifiers supported
+ */
unsigned int modifier_count;
/**
--
2.16.1
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-03-15 18:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-12 20:40 [PATCH 1/3] drm: Add the optional .fb_modifier() hook Ville Syrjala
2018-03-12 20:40 ` [PATCH 2/3] drm: Make sure at least one plane supports the fb format Ville Syrjala
2018-03-15 17:42 ` Eric Anholt
2018-03-15 17:48 ` Ville Syrjälä
2018-03-15 18:03 ` Ville Syrjälä
2018-03-15 18:48 ` Ville Syrjälä [this message]
2018-03-16 22:07 ` Eric Anholt
2018-03-12 20:40 ` [PATCH 3/3] drm/i915: Eliminate the horrendous format check code Ville Syrjala
2018-03-12 21:44 ` ✗ Fi.CI.BAT: failure for series starting with [1/3] drm: Add the optional .fb_modifier() hook Patchwork
2018-03-13 14:28 ` [PATCH v2 1/3] " Ville Syrjala
2018-03-13 14:38 ` Michel Dänzer
2018-03-13 15:12 ` Ville Syrjälä
2018-03-13 15:18 ` Michel Dänzer
2018-03-13 15:20 ` Daniel Vetter
2018-03-13 15:35 ` Michel Dänzer
2018-03-13 15:46 ` Ville Syrjälä
2018-03-13 16:06 ` ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) Patchwork
2018-03-13 16:56 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-03-13 17:03 ` Ville Syrjälä
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=20180315184817.GC5453@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=intel-gfx@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.