Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 23 Sep 2019 15:50:59 +0300
From:   Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
To:     Brian Starkey <Brian.Starkey@arm.com>
Cc:     "Lowry Li (Arm Technology China)" <Lowry.Li@arm.com>,
        nd <nd@arm.com>, Ayan Halder <Ayan.Halder@arm.com>,
        "airlied@linux.ie" <airlied@linux.ie>,
        Liviu Dudau <Liviu.Dudau@arm.com>,
        "Jonathan Chai (Arm Technology China)" <Jonathan.Chai@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        "Julien Yin (Arm Technology China)" <Julien.Yin@arm.com>,
        "james qian wang (Arm Technology China)" <james.qian.wang@arm.com>,
        "seanpaul@chromium.org" <seanpaul@chromium.org>,
        Mihail Atanassov <Mihail.Atanassov@arm.com>
Subject: Re: [PATCH] drm/komeda: Adds output-color format/depth support
Message-ID: <20190923125059.GI1208@intel.com>
References: <20190920094329.17513-1-lowry.li@arm.com>
 <20190923121604.jqi6ewln27yvdajw@DESKTOP-E1NTVVP.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190923121604.jqi6ewln27yvdajw@DESKTOP-E1NTVVP.localdomain>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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:
> > 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