[Intel-gfx] [PATCH v2] drm/i915: Promote .format_mod_supported() to the lead role

[Ville Syrjälä]

On Wed, May 30, 2018 at 11:30:26AM -0700, Eric Anholt wrote:
> Ville Syrjälä <ville.syrjala at linux.intel.com> writes:
> 
> > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote:
> >> Ville Syrjala <ville.syrjala at linux.intel.com> writes:
> >> 
> >> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >> >
> >> > Up to now we've used the plane's modifier list as the primary
> >> > source of information for which modifiers are supported by a
> >> > given plane. In order to allow auxiliary metadata to be embedded
> >> > within the bits of the modifier we need to stop doing that.
> >> >
> >> > Thus we have to make .format_mod_supported() aware of the plane's
> >> > capabilities and gracefully deal with any modifier being passed
> >> > in directly from userspace.
> >> 
> >> This seems like it would be a lot shorter if you just had a helper to
> >> check if your format and modifier was in drm_plane->format_types and
> >> drm_plane->modifiers, since then you wouldn't be duplicating your tables
> >> and you wouldn't need has_ccs either.
> >
> > I suppose. And I guess that's where I started originally :/
> >
> > But I'm not sure if it's better go that route or the other route of
> > reducing the arrays to some simple supersets and also utilize
> > .format_mod_supported() in plane init to filter out the unsupported
> > formats when populating the plane's format list. Probably best not
> > dwell on this too much for now so that we can at least make some
> > progress :)
> >
> >> 
> >> However, it's not my driver and it unblocks vc4's patch, so:
> >> 
> >> Reviewed-by: Eric Anholt <eric at anholt.net>
> >
> > Thanks. I'm guessing we should push this into drm-misc-next so
> > that you can pile your core/sand bits on top?
> 
> That would be wonderful.

Now pushed. Had to resolve a few nv12 conflicts each way. I guess
someone else will get to deal with that same fun at some point

-- 
Ville Syrjälä
Intel