Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755630AbbHYOCm (ORCPT ); Tue, 25 Aug 2015 10:02:42 -0400 Received: from regular1.263xmail.com ([211.150.99.139]:52221 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755172AbbHYOCj (ORCPT ); Tue, 25 Aug 2015 10:02:39 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: ykk@rock-chips.com X-FST-TO: andy.yan@rock-chips.com X-SENDER-IP: 220.249.180.47 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: <823a2b6e5a38ea42be279f10b95de5f6> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v3 06/14] Documentation: drm/bridge: add document for analogix_dp To: Thierry Reding References: <1439995728-18046-1-git-send-email-ykk@rock-chips.com> <1439995834-18363-1-git-send-email-ykk@rock-chips.com> <20150824125758.GA7557@n2100.arm.linux.org.uk> <20150825091246.GA14034@ulmo.nvidia.com> <55DC383F.4000103@rock-chips.com> <20150825100628.GD14034@ulmo.nvidia.com> Cc: Rob Herring , Russell King - ARM Linux , Heiko Stuebner , Jingoo Han , Fabio Estevam , Inki Dae , Joe Perches , Sean Paul , Takashi Iwai , dri-devel , Andrzej Hajda , Gustavo Padovan , "linux-samsung-soc@vger.kernel.org" , Vincent Palatin , linux-rockchip@lists.infradead.org, Kishon Vijay Abraham I , David Airlie , "devicetree@vger.kernel.org" , Pawel Moll , Ian Campbell , Doug Anderson , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Mark Yao , "linux-kernel@vger.kernel.org" , Kyungmin Park , Daniel Kurtz , Philipp Zabel , Kumar Gala , Ajay kumar , Andy Yan From: Yakir Yang Message-ID: <55DC7571.6000204@rock-chips.com> Date: Tue, 25 Aug 2015 22:02:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150825100628.GD14034@ulmo.nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3800 Lines: 91 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 >>>> 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 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/