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

[Eric Anholt]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20180530/3ae66ab3/attachment.sig>