linux-kernel - Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 25 Aug 2015 22:02:25 +0800
From:	Yakir Yang <ykk@...k-chips.com>
To:	Thierry Reding <treding@...dia.com>
Cc:	Rob Herring <robherring2@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Heiko Stuebner <heiko@...ech.de>,
	Jingoo Han <jingoohan1@...il.com>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	Inki Dae <inki.dae@...sung.com>, Joe Perches <joe@...ches.com>,
	Sean Paul <seanpaul@...gle.com>, Takashi Iwai <tiwai@...e.de>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Andrzej Hajda <a.hajda@...sung.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	linux-rockchip@...ts.infradead.org,
	Kishon Vijay Abraham I <kishon@...com>,
	David Airlie <airlied@...ux.ie>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Doug Anderson <dianders@...gle.com>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mark Yao <mark.yao@...k-chips.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Daniel Kurtz <djkurtz@...gle.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Kumar Gala <galak@...eaurora.org>,
	Ajay kumar <ajaynumb@...il.com>,
	Andy Yan <andy.yan@...k-chips.com>
Subject: Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for
 analogix_dp

Hi Thierry,

在 2015/8/25 18:06, Thierry Reding 写道:
> On Tue, Aug 25, 2015 at 05:41:19PM +0800, Yakir Yang wrote:
>> Hi Thierry,
>>
>> 在 2015/8/25 17:12, Thierry Reding 写道:
>>> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
>>>> On Mon, Aug 24, 2015 at 7:57 AM, Russell King - ARM Linux
>>>> <linux@....linux.org.uk> wrote:
>>>>> On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
>>>>>> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang <ykk@...k-chips.com> wrote:
>>>>>>> +       -analogix,color-depth:
>>>>>>> +               number of bits per colour component.
>>>>>>> +                       COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
>>>>>> This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
>>>>>> drop the vendor prefix.
>>>>> Please think about this some more.  What does "color-depth" mean?  Does it
>>>>> mean the number of bits per colour _component_, or does it mean the total
>>>>> number of bits to represent a particular colour.  It's confusing as it
>>>>> stands.
>>>> Then "component-color-bpp" perhaps?
>>> There should be no need to have this in DT at all. The BPC is a property
>>> of the attached panel and it should come from the panel (either the
>>> panel driver or parsed from EDID if available).
>> Actually I have send an email about this one to you in version 2, just past
>> from that email:
>>
>> "samsung,color_space" and "samsung,color-depth"
>>
>> The drm_display_info's color_formats and bpc indicate the monitor display
>> ability, but
>> the edp driver could not take it as input video format directly.
>>
>> For example, with my DP TV I would found "RGB444 & YCRCB422 & & YCRCB444"
>> support in drm_display_info.color_formats and 16bit bpc support, but RK3288
>> crtc
>> driver could only output RGB & ITU formats, so finally analogix_dp-rockchip
>> driver
>> config crtc to RGBaaa 10bpc mode.
>>
>> In this sutiation, the analogix_dp core driver would pazzled by the
>> drm_display_info,
>> can't chose the right color_space and bpc.
>>
>> And this is the place that confused me, wish you could give some ideas about
>> this one :-)
> Your display driver should choose whatever it is capable of outputting.
> If the display reports that it can do 16 bits-per-color, but your
> display driver can't do it, then it should choose a configuration that
> it supports. Similarily for the color encodings. If you can't generate
> YCrCb444 with your hardware, then it's the driver's job to know about
> that and select the next appropriate configuration.
>
> But hard-coding this is not the right solution because the value in DT
> may end up conflicting with what the display reports.

Yeah, thanks for your explain, you are right. It's the best way to get 
"color-depth"
and "color-space" from display driver, not to hard-code in DT prop.

But if the common analogix-dp driver want to get those values, then 
those values
should come from the common drm struct data. Personally I think "struct 
drm_crtc"
is the best place that should indicate the output ability of SoC vop/lcdc.

But I haven't find out there are some place to store those message for 
now (I don't
think it's good to modify the original color-space and color-bpc which 
parsed from
monitor edid).

So could you share sme ideas about this, and I would rather to talk with 
Mark (Author
of rockchip drm driver) to find out the better way to fix this one.

Besides, I would appreciate very much if you can share some ideas about 
how Exynos
handler with this problem ;)

Thanks,
- Yakir
> Thierry


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/