[PATCH] drm/komeda: Adds output-color format/depth support

[Ville Syrjälä]

On Mon, Sep 23, 2019 at 12:16:12PM +0000, Brian Starkey wrote:
> Hi Lowry,
> 
> On Fri, Sep 20, 2019 at 09:43:47AM +0000, Lowry Li (Arm Technology China) wrote:
> > From: "Lowry Li (Arm Technology China)" <Lowry.Li at arm.com>
> > 
> > Sets color_depth according to connector->bpc.
> > Adds a new optional DT attribute "color-format" to represent a
> > preferred color formats for a specific pipeline, and the select order
> > is:
> > 	YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> > The color-format can be anyone of these 4 format, one color-format not
> > only represent one format, but also include the lower formats, like
> > 
> > color-format         preferred_color_formats
> > YCRCB420        YCRCB420 > YCRCB422 > YCRCB444 > RGB444
> > YCRCB422        YCRCB422 > YCRCB444 > RGB444
> > YCRCB444        YCRCB444 > RGB444
> > RGB444          RGB444
> > 
> > Then the final color_format is calculated by 3 steps:
> > 1. calculate HW available formats.
> >   avail_formats = connector_color_formats & improc->color_formats;
> > 2. filter out un-preferred format.
> >   avail_formats &= preferred_color_formats;
> > 3. select the final format according to the preferred order.
> >   color_format = BIT(__fls(aval_formats));
> 
> Is there a specific use-case for the DT property for selecting color
> format?
> 
> I think in general the color format should be determined according to
> the rules in the CEA spec. There's also the drm_mode_is_420_only()
> helper we can use to determine if YCBCR420 must be used. For the cases
> where it's optional, I think we can default to RGB444.

That is the policy we have in i915. We have a vague plan to add
a new property for the user to select the encoding explicitly
(which would also allow things like YCbCr 4:4:4), but IIRC no
one has actually sent a patch for that.

CTA-861 sort of seems to say that one should favor YCbCr over
RGB iff both sides support it, but I think RGB is probably the
better default because it means straight passthrough (minus the
annoying full->limit quantization range trickery).

-- 
Ville Syrjälä
Intel