Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> writes: > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote: >> Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx> writes: >> >> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> > >> > 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@xxxxxxxxxx> > > 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
