[PATCH] drm/fourcc: add Vivante TS modifiers

[Daniel Vetter]

On Mon, Mar 22, 2021 at 10:20:45AM +0100, Lucas Stach wrote:
> Hi Christian,
> 
> Am Montag, dem 22.03.2021 um 09:54 +0100 schrieb Christian Gmeiner:
> > Am Sa., 20. März 2021 um 20:11 Uhr schrieb Daniel Vetter <daniel at ffwll.ch>:
> > > 
> > > On Sat, Mar 20, 2021 at 10:28 AM Christian Gmeiner
> > > <christian.gmeiner at gmail.com> wrote:
> > > > 
> > > > Hi Lucas
> > > > 
> > > > Am Fr., 19. März 2021 um 20:06 Uhr schrieb Lucas Stach <l.stach at pengutronix.de>:
> > > > > 
> > > > > Vivante TS (tile-status) buffer modifiers. They can be combined with all of
> > > > > the Vivante color buffer tiling modifiers, so they are kind of a modifier
> > > > > modifier. If a TS modifier is present we have a additional plane for the
> > > > > TS buffer and the modifier defines the layout of this TS buffer.
> > > > > 
> > > > 
> > > > I am unsure why you want to have the TS modifiers in drm_fourcc.h. Can
> > > > you share some insight on this?
> > > 
> > > It's the official registry for drm_fourcc codes and drm modifiers.
> > > Whether the kernel ever uses it or not doesn't matter.
> > 
> > Fair point.. but I do not see any usage of these TS modifiers in mesa
> > - that's why I am asking.
> 
> I have a Mesa series using those modifiers, which I'm currently
> rebasing and will be posted shortly. However, the way things work is:
> first get the modifier into drm_fourcc.h, then merge any code using the
> new modifiers, so I figured it would be fair game to post this patch
> before I fully finished reworking the Mesa series.

Generally post poth sides, and then _merge_ them in the order you
described. Christian has a good point that generally for modifiers that
mesa is expected to use, we want to have the mesa code as demonstration
that they work. Especially for r/e'ed drivers where there's not
authoritative spec.

I was just assuming that this has happened already.
-Daniel

PS: Since this comes up all the time, relevant part of the upstream docs:

"The kernel patch can only be merged after all the above requirements are
met, but it must be merged to either drm-next or drm-misc-next before the
userspace patches land. uAPI always flows from the kernel, doing things
the other way round risks divergence of the uAPI definitions and header
files."

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch