[PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

[Russell King - ARM Linux]

On Wed, Dec 13, 2017 at 03:41:49PM +0000, Daniel Stone wrote:
> Hi Russell,
> 
> On 8 December 2017 at 12:31, Russell King <rmk+kernel at armlinux.org.uk> wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion.  This is mutually
> > exclusive with the CSC_YUV CRTC property - the last property to be set
> > determines the resulting colorspace conversion.
> 
> I haven't seen this in other drivers - is it a 'defacto standard'?

As far as I know, nothing for this is standardised - when I implemented
this method, I did survey the drivers, and decided it was best to use
what existing implementations were already using.  I wrote this patch
back in February, so memory is now hazy, but iirc, it came from:

drivers/gpu/drm/nouveau/dispnv04/overlay.c

> I prefer VIlle's choice of an explicit 601/709 enum, since that's more
> easily expandable. I do worry about the interaction with the CTM
> properties, but I also don't have a good answer as to what that would
> look like. I also worry that implementing the 'last-property-set'
> semantics might be difficult to implement in an atomic driver.

Nothing really made use of the CRTC property, so its unlikely that
there'll be a conflict.  I suspect I could delete the CRTC property
when eventually switching to atomic modeset.

> 
> >  struct armada_ovl_plane {
> > @@ -252,6 +254,10 @@ armada_ovl_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
> >         if (!dcrtc->plane) {
> >                 dcrtc->plane = plane;
> >                 armada_ovl_update_attr(&dplane->prop, dcrtc);
> > +               if (dplane->prop.csc_set) {
> > +                       armada_drm_crtc_set_yuv_colorimetry(dcrtc, dplane->prop.csc);
> > +                       dplane->prop.csc_set = false;
> > +               }
> >         }
> 
> Just trying to understand this a little better: setting this property
> on a plane results in a CRTC change. This is only implemented for the
> overlay ('video') plane, but the primary ('graphics') plane also
> supports YUV formats. Does this mean that the two planes have to have
> the same configuration wrt 601/709 if both are YUV? That could again
> get painful to express.

The same is true of the saturation, brightness, contrast etc values.
There is only one set of YUV to RGB conversion in the hardware block
and its settings will be used for both.

However, practically I don't think YUV is ever used for the primary
plane, so I could just drop those from the list of primary plane
formats.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up