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@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:
- 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).