Message ID | bb5cac77-a705-738e-13ae-667ea87f1cb1@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp362532vqu; Thu, 2 Nov 2023 06:43:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGlxWsGfmqsm8qZixTbj+bpgAIqWEJVhi2tFZM/Ez3vr+zif5hdSGkoPeB7MVBRmM3KRpwP X-Received: by 2002:a17:90b:1909:b0:280:a69e:45ec with SMTP id mp9-20020a17090b190900b00280a69e45ecmr9911775pjb.5.1698932586379; Thu, 02 Nov 2023 06:43:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698932586; cv=none; d=google.com; s=arc-20160816; b=kB6CogbfeDmfNYuoje+KyeBnH3gRcfWXQDBdUmEkyIuyCRlHerQqXsG+3bbUN4kRxI rIoi1qbwF/Xe+wLhDVAbgep2MGlkFUYCNnt6L+2gGHHgbLI26B33GjOZnvLHdvLHTMY/ ryv1xfvI5pf6Tl7osc1R/if1AdIgjJJe6Wv9y8xhtfasGzaUrH177pxELKcfGuM4yk5O v+ijHR+r59n6AWw8DITrvs8E56wLlS9OJCRxaUWu6IVNLbmFbswCddkhxoQZ+9/cAkIM JoK5sla/BZ/sMoGUAw5JIctY+SQTt4CHUxZFH9/eX/EuiSKmSOWmD2QN24KB3ShT6xqp VVYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:dkim-signature; bh=5ij4W2R7Rk89TAWTRo2Z11H1sJFKrF9K18A1hdSCONQ=; fh=v9EK/ZpF7mC7HytCEN1dwHNmJmndcYWW0//5MYgVSx0=; b=Jk8KRwdJ5JotzWGl4EsbM4Br9vuLhvC8szFkV0HUn8UHqZ3kAy895iuyAbpG7mSJXC jiQwnNFZMRISLBfqI/m+g5r+t0QwvJqGNxP7yVCi9qIsduRf3iqOWfGHUZOAsN//++5H qgvOQCKf7fNRltOQR2uqAx5qATH3yG3DQjq9YXN7I6jXcgM+1vRDuTk1/CTcbx8XJKh6 CPkcVJ1A6wC6uDeMdyZEXwPS1BL1JPlwegW/8rBD9C3Oo5psT7cEhknRGUA99l/9AP+d KHNqJMhgmk1tL5M3SEh7llz5AZcMpLB+AAIx/xHzh+ViOUIPslzdTdKXa7CTtZeMA4hL i+/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fvelpO8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id kk15-20020a17090b4a0f00b002805dcadebasi3163405pjb.115.2023.11.02.06.42.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 06:43:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fvelpO8V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 798F48069F9F; Thu, 2 Nov 2023 06:42:41 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376655AbjKBNm2 (ORCPT <rfc822;lhua1029@gmail.com> + 36 others); Thu, 2 Nov 2023 09:42:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376646AbjKBNm1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Nov 2023 09:42:27 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28EF0197 for <linux-kernel@vger.kernel.org>; Thu, 2 Nov 2023 06:42:22 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-9d274222b5dso152100766b.3 for <linux-kernel@vger.kernel.org>; Thu, 02 Nov 2023 06:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698932540; x=1699537340; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=5ij4W2R7Rk89TAWTRo2Z11H1sJFKrF9K18A1hdSCONQ=; b=fvelpO8V8Ce+Mv5BzLn5w/uMDmuAJBXgew3vs3uqw2uVNDpcV+PhUXg10eZEfD1CWA wu4AQg3IIoqU1riYwu1+R7waP6vrNFjDy3X7arws6xSUcQyao35psA0hWWG6X+Q8xFAm G/y/97Z+f1M3ya6Wi9chCm9mR9IfoR6f2uNYlGSrpf3unVPO6jKcf/B+mCCN2TjMB5UB EBXv1vciDRWygrhgfgS/o6GK+iqT5Pnb1wSnLoitk0pRwjcl4b1S2Q0GOhdquVgfBWuV BLsmkNLw1nTPnVnVYvoKd8PBKabBrjD4AxSNrpQnEEtIygb2GhIifLViKA4U15O1o0oF gzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698932540; x=1699537340; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5ij4W2R7Rk89TAWTRo2Z11H1sJFKrF9K18A1hdSCONQ=; b=p/6UV4A5KBf72EAhohWm1ub89V86inE+Yqdobcq7Z7uotFGb8HGWCiwh29zikcKyff IzoOiz4RN6Sq65vTkSfhN6ghEwEhtE4QZvdE+NLDXjby+mKL9bTj67gpQPnv+jJ0Ql23 tcNxNYU/u9oz8QzIwvcBlKbcPshYAICP4QFjZG5Qt7cy6QpZmVVSM6W7EQXiP5S+hNR+ 5ysA/yOiNOSkH1rZ6ID+hX3YrZ0ArtXWeFwIpvAX10c7JeSjCcx1aZRP1Jn06cP7R2T3 TBS3t+wMo5JLpAWFea9Vt1Q27pYLhT7HpwadeZyZr+IxtsLLhHMnEZjykNBF72oSWSvh 4/NQ== X-Gm-Message-State: AOJu0YzPyiCmT5suV3zm660rqVclnBdkz5ynGlQ26DCP4lnxQxLFANsN gDbNt1lri5Qjgdwrg4OJ7+Q= X-Received: by 2002:a17:907:60ca:b0:9c7:4d51:af08 with SMTP id hv10-20020a17090760ca00b009c74d51af08mr4508255ejc.43.1698932540595; Thu, 02 Nov 2023 06:42:20 -0700 (PDT) Received: from [192.168.2.1] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id j8-20020a170906278800b009be14e5cd54sm1153220ejc.57.2023.11.02.06.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Nov 2023 06:42:20 -0700 (PDT) Message-ID: <bb5cac77-a705-738e-13ae-667ea87f1cb1@gmail.com> Date: Thu, 2 Nov 2023 14:42:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 From: Johan Jonker <jbx6244@gmail.com> Subject: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format To: hjc@rock-chips.com, heiko@sntech.de Cc: airlied@gmail.com, daniel@ffwll.ch, dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org References: <cda574be-4f33-b66d-eb14-92c2b31d241e@gmail.com> Content-Language: en-US In-Reply-To: <cda574be-4f33-b66d-eb14-92c2b31d241e@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 02 Nov 2023 06:42:41 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781459935326322613 X-GMAIL-MSGID: 1781459935326322613 |
Series |
Rockchip rk3066_hdmi update
|
|
Commit Message
Johan Jonker
Nov. 2, 2023, 1:42 p.m. UTC
The Rk3066 hdmi output format is hard coded to RGB. Remove
all useless code related to colorimetry and enc_out_format.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
--
2.39.2
Comments
Hi Johan, Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker: > The Rk3066 hdmi output format is hard coded to RGB. Remove > all useless code related to colorimetry and enc_out_format. > > Signed-off-by: Johan Jonker <jbx6244@gmail.com> I guess my first question is, is the hardcoding happening just because of missing functionality in the driver, or does the hardware only support RGB? > --- > drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +------------------- > 1 file changed, 1 insertion(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c > index 0e7aae341960..f2b1b2faa096 100644 > --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c > +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c > @@ -23,8 +23,6 @@ > > struct hdmi_data_info { > int vic; /* The CEA Video ID (VIC) of the current drm display mode. */ > - unsigned int enc_out_format; > - unsigned int colorimetry; > }; > > struct rk3066_hdmi_i2c { > @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi, > rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, > &hdmi->connector, mode); > > - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444) > - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; > - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422) > - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; > - else > - frame.avi.colorspace = HDMI_COLORSPACE_RGB; > - > - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry; > + frame.avi.colorspace = HDMI_COLORSPACE_RGB; > frame.avi.scan_mode = HDMI_SCAN_MODE_NONE; > > return rk3066_hdmi_upload_frame(hdmi, rc, &frame, > @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi, > struct drm_display_info *display = &hdmi->connector.display_info; > > hdmi->hdmi_data.vic = drm_match_cea_mode(mode); > - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB; > - > - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 || > - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 || > - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 || > - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18) > - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601; > - else > - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709; while I can understand the RGB output format, why does the colorimetry also get removed? This looks like it is dependent on the mode itself and not the output format? Thanks Heiko
On 11/20/23 18:06, Heiko Stuebner wrote: > Hi Johan, > > Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker: >> The Rk3066 hdmi output format is hard coded to RGB. Remove >> all useless code related to colorimetry and enc_out_format. >> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com> > > I guess my first question is, is the hardcoding happening just because > of missing functionality in the driver, or does the hardware only > support RGB? This driver can do so much more..., but is crippled by various causes. If in need for a full functional rk3066 driver a little bit help/advise/action from other people is needed. 1: Missing rk3066 TRM HDMI register info. Could Rockchip (= Sandy Huang) disclose this info to the open source community? As a way around we can look at older driver code and port to mainline. More info gives better results. rk30_hdmi_config_csc() function: https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L315 2: Could DRM people show us examples for: - How to advertise to the VOP driver what data formats (RGB, YCBCR) it can send to the HDMI driver or any other Rockchip DRM sub driver other then RGB. - Advertise EDID data monitor modes RGB444, YCBCR444 and YCBCR422 to the HDMI driver. https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/rk_hdmi_edid.c#L217C1-L218C41 3: Advise when what Infoframe is needed for only RGB vs. the rest according to the specification. https://engineering.purdue.edu/ece477/Archive/2012/Spring/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf rk3066 currently only sends avi info. Does it need vsi as well? Can anyone give some clarity here? inno_hdime sends avi and vsi info. 4: rk3066_hdmi and inno_hdmi are HDMI 1.4a drivers for DVI and HDMI. Validated by drm_match_cea_mode() this function only gives us both HDMI + HDMI2 focus, but nothing for old DVI monitors. How to improve? 5: Sound support was submitted: Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver https://lore.kernel.org/linux-rockchip/48dbe9b7-0aa0-f459-301f-f380e2b7f2f8@gmail.com/ No reply was given (by Heiko or others) on why it wasn't applied or what needs to be improved. Without reply no improvement. Johan > > >> --- >> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +------------------- >> 1 file changed, 1 insertion(+), 19 deletions(-) >> >> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c >> index 0e7aae341960..f2b1b2faa096 100644 >> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c >> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c >> @@ -23,8 +23,6 @@ >> >> struct hdmi_data_info { >> int vic; /* The CEA Video ID (VIC) of the current drm display mode. */ >> - unsigned int enc_out_format; >> - unsigned int colorimetry; >> }; >> >> struct rk3066_hdmi_i2c { >> @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi, >> rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, >> &hdmi->connector, mode); >> >> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444) >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; >> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422) >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; >> - else >> - frame.avi.colorspace = HDMI_COLORSPACE_RGB; >> - >> - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry; >> + frame.avi.colorspace = HDMI_COLORSPACE_RGB; >> frame.avi.scan_mode = HDMI_SCAN_MODE_NONE; >> >> return rk3066_hdmi_upload_frame(hdmi, rc, &frame, >> @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi, >> struct drm_display_info *display = &hdmi->connector.display_info; >> >> hdmi->hdmi_data.vic = drm_match_cea_mode(mode); >> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB; >> - >> - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 || >> - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 || >> - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 || >> - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18) >> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601; >> - else >> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709; > > while I can understand the RGB output format, why does the colorimetry > also get removed? This looks like it is dependent on the mode itself > and not the output format? From the old driver these conditions apply whether csc is needed. https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L320C1-L324C3 if( ((vpara->input_color == VIDEO_INPUT_COLOR_RGB) && (vpara->output_color == VIDEO_OUTPUT_RGB444)) || ((vpara->input_color == VIDEO_INPUT_COLOR_YCBCR) && (vpara->output_color != VIDEO_OUTPUT_RGB444) )) { return; } > > Thanks > Heiko > >
Hi Johan: some information bellow hope can help a bit. On 11/23/23 20:54, Johan Jonker wrote: > > On 11/20/23 18:06, Heiko Stuebner wrote: >> Hi Johan, >> >> Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker: >>> The Rk3066 hdmi output format is hard coded to RGB. Remove >>> all useless code related to colorimetry and enc_out_format. >>> >>> Signed-off-by: Johan Jonker <jbx6244@gmail.com> >> I guess my first question is, is the hardcoding happening just because >> of missing functionality in the driver, or does the hardware only >> support RGB? > This driver can do so much more..., but is crippled by various causes. > If in need for a full functional rk3066 driver a little bit help/advise/action from other people is needed. > > 1: > Missing rk3066 TRM HDMI register info. > Could Rockchip (= Sandy Huang) disclose this info to the open source community? The HDMI on rk3066 is from a IP vendor, so the detail of this IP are not even include in the TRM. As it is a chip which is more than 10 yeas old, I contacted the author of the bsp driver, got some information bellow: This IP is almost the same with sh_mobile_hdmi, unfortunately, SH-Mobile HDMI drivers is removed out of mainline in 2015[0], but with a quick look at it, the register definition is the same as rk3066 hdmi and with more detail description. [0]https://lkml.kernel.org/stable/20191122100825.930987859@linuxfoundation.org/ > > As a way around we can look at older driver code and port to mainline. > More info gives better results. > rk30_hdmi_config_csc() function: > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L315 > > 2: > Could DRM people show us examples for: > - How to advertise to the VOP driver what data formats (RGB, YCBCR) it can send to the HDMI driver or any other Rockchip DRM sub driver other then RGB. > - Advertise EDID data monitor modes RGB444, YCBCR444 and YCBCR422 to the HDMI driver. > > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/rk_hdmi_edid.c#L217C1-L218C41 RK3066 vop can only output RGB full range to HDMI, so the full to limit rgb to yuv conversion is done by rk30_hdmi_config_csc. > > 3: > Advise when what Infoframe is needed for only RGB vs. the rest according to the specification. > https://engineering.purdue.edu/ece477/Archive/2012/Spring/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf > > rk3066 currently only sends avi info. Does it need vsi as well? Can anyone give some clarity here? > inno_hdime sends avi and vsi info. vsi is used for 3d and hdmi 1.4 format(4K24/25/30, not support by rk3066), or vendor specific data like timecode, dolby, so as a basic function, we don't need it. > > 4: > rk3066_hdmi and inno_hdmi are HDMI 1.4a drivers for DVI and HDMI. > Validated by drm_match_cea_mode() this function only gives us both HDMI + HDMI2 focus, but nothing for old DVI monitors. > How to improve? > > 5: > Sound support was submitted: > Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver > https://lore.kernel.org/linux-rockchip/48dbe9b7-0aa0-f459-301f-f380e2b7f2f8@gmail.com/ > > No reply was given (by Heiko or others) on why it wasn't applied or what needs to be improved. > > Without reply no improvement. > > Johan > > >> >>> --- >>> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +------------------- >>> 1 file changed, 1 insertion(+), 19 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c >>> index 0e7aae341960..f2b1b2faa096 100644 >>> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c >>> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c >>> @@ -23,8 +23,6 @@ >>> >>> struct hdmi_data_info { >>> int vic; /* The CEA Video ID (VIC) of the current drm display mode. */ >>> - unsigned int enc_out_format; >>> - unsigned int colorimetry; >>> }; >>> >>> struct rk3066_hdmi_i2c { >>> @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi, >>> rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, >>> &hdmi->connector, mode); >>> >>> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444) >>> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; >>> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422) >>> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; >>> - else >>> - frame.avi.colorspace = HDMI_COLORSPACE_RGB; >>> - >>> - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry; >>> + frame.avi.colorspace = HDMI_COLORSPACE_RGB; >>> frame.avi.scan_mode = HDMI_SCAN_MODE_NONE; >>> >>> return rk3066_hdmi_upload_frame(hdmi, rc, &frame, >>> @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi, >>> struct drm_display_info *display = &hdmi->connector.display_info; >>> >>> hdmi->hdmi_data.vic = drm_match_cea_mode(mode); >>> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB; >>> - >>> - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 || >>> - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 || >>> - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 || >>> - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18) >>> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601; >>> - else >>> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709; >> while I can understand the RGB output format, why does the colorimetry >> also get removed? This looks like it is dependent on the mode itself >> and not the output format? > >From the old driver these conditions apply whether csc is needed. > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L320C1-L324C3 > > if( ((vpara->input_color == VIDEO_INPUT_COLOR_RGB) && (vpara->output_color == VIDEO_OUTPUT_RGB444)) || > ((vpara->input_color == VIDEO_INPUT_COLOR_YCBCR) && (vpara->output_color != VIDEO_OUTPUT_RGB444) )) > { > return; > } > >> Thanks >> Heiko >> >> > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Johan, Am Donnerstag, 23. November 2023, 13:54:28 CET schrieb Johan Jonker: > > On 11/20/23 18:06, Heiko Stuebner wrote: > > Hi Johan, > > > > Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker: > >> The Rk3066 hdmi output format is hard coded to RGB. Remove > >> all useless code related to colorimetry and enc_out_format. > >> > >> Signed-off-by: Johan Jonker <jbx6244@gmail.com> > > > > > I guess my first question is, is the hardcoding happening just because > > of missing functionality in the driver, or does the hardware only > > support RGB? > > This driver can do so much more..., but is crippled by various causes. > If in need for a full functional rk3066 driver a little bit help/advise/action from other people is needed. Part of me wants to have fully working drivers, but on the other hand, both the rk3066-hdmi and also the inno-hdmi drivers are sort of one-off drivers used by rk3066 and rk3036 (inno-hdmi) and most likely won't see new SoCs using them in the future. So I guess after thinking more about this, I should probably just apply your patch to simplify the code and if by some magical happenings in future someone really wants to spend time on either one of these drivers they can always use "git revert" to bring back the old code? Heiko > 1: > Missing rk3066 TRM HDMI register info. > Could Rockchip (= Sandy Huang) disclose this info to the open source community? > > As a way around we can look at older driver code and port to mainline. > More info gives better results. > rk30_hdmi_config_csc() function: > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L315 > > 2: > Could DRM people show us examples for: > - How to advertise to the VOP driver what data formats (RGB, YCBCR) it can send to the HDMI driver or any other Rockchip DRM sub driver other then RGB. > - Advertise EDID data monitor modes RGB444, YCBCR444 and YCBCR422 to the HDMI driver. > > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/rk_hdmi_edid.c#L217C1-L218C41 > > 3: > Advise when what Infoframe is needed for only RGB vs. the rest according to the specification. > https://engineering.purdue.edu/ece477/Archive/2012/Spring/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf > > rk3066 currently only sends avi info. Does it need vsi as well? Can anyone give some clarity here? > inno_hdime sends avi and vsi info. > > 4: > rk3066_hdmi and inno_hdmi are HDMI 1.4a drivers for DVI and HDMI. > Validated by drm_match_cea_mode() this function only gives us both HDMI + HDMI2 focus, but nothing for old DVI monitors. > How to improve? > > 5: > Sound support was submitted: > Re: [PATCH v6 2/5] drm: rockchip: add sound support to rk3066 hdmi driver > https://lore.kernel.org/linux-rockchip/48dbe9b7-0aa0-f459-301f-f380e2b7f2f8@gmail.com/ > > No reply was given (by Heiko or others) on why it wasn't applied or what needs to be improved. > > Without reply no improvement. > > Johan > > > > > > > >> --- > >> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 20 +------------------- > >> 1 file changed, 1 insertion(+), 19 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c > >> index 0e7aae341960..f2b1b2faa096 100644 > >> --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c > >> +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c > >> @@ -23,8 +23,6 @@ > >> > >> struct hdmi_data_info { > >> int vic; /* The CEA Video ID (VIC) of the current drm display mode. */ > >> - unsigned int enc_out_format; > >> - unsigned int colorimetry; > >> }; > >> > >> struct rk3066_hdmi_i2c { > >> @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi, > >> rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, > >> &hdmi->connector, mode); > >> > >> - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444) > >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; > >> - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422) > >> - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; > >> - else > >> - frame.avi.colorspace = HDMI_COLORSPACE_RGB; > >> - > >> - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry; > >> + frame.avi.colorspace = HDMI_COLORSPACE_RGB; > >> frame.avi.scan_mode = HDMI_SCAN_MODE_NONE; > >> > >> return rk3066_hdmi_upload_frame(hdmi, rc, &frame, > >> @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi, > >> struct drm_display_info *display = &hdmi->connector.display_info; > >> > >> hdmi->hdmi_data.vic = drm_match_cea_mode(mode); > >> - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB; > >> - > >> - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 || > >> - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 || > >> - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 || > >> - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18) > >> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601; > >> - else > >> - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709; > > > > > while I can understand the RGB output format, why does the colorimetry > > also get removed? This looks like it is dependent on the mode itself > > and not the output format? > > From the old driver these conditions apply whether csc is needed. > https://github.com/RockchipOpensourceCommunity/px2-android-kernel-3.0/blob/master/drivers/video/rockchip/hdmi/chips/rkpx2/rkpx2_hdmi_hw.c#L320C1-L324C3 > > if( ((vpara->input_color == VIDEO_INPUT_COLOR_RGB) && (vpara->output_color == VIDEO_OUTPUT_RGB444)) || > ((vpara->input_color == VIDEO_INPUT_COLOR_YCBCR) && (vpara->output_color != VIDEO_OUTPUT_RGB444) )) > { > return; > } > > > > > Thanks > > Heiko > > > > >
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c index 0e7aae341960..f2b1b2faa096 100644 --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c @@ -23,8 +23,6 @@ struct hdmi_data_info { int vic; /* The CEA Video ID (VIC) of the current drm display mode. */ - unsigned int enc_out_format; - unsigned int colorimetry; }; struct rk3066_hdmi_i2c { @@ -200,14 +198,7 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi, rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, &hdmi->connector, mode); - if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444) - frame.avi.colorspace = HDMI_COLORSPACE_YUV444; - else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422) - frame.avi.colorspace = HDMI_COLORSPACE_YUV422; - else - frame.avi.colorspace = HDMI_COLORSPACE_RGB; - - frame.avi.colorimetry = hdmi->hdmi_data.colorimetry; + frame.avi.colorspace = HDMI_COLORSPACE_RGB; frame.avi.scan_mode = HDMI_SCAN_MODE_NONE; return rk3066_hdmi_upload_frame(hdmi, rc, &frame, @@ -329,15 +320,6 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi, struct drm_display_info *display = &hdmi->connector.display_info; hdmi->hdmi_data.vic = drm_match_cea_mode(mode); - hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB; - - if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 || - hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22 || - hdmi->hdmi_data.vic == 2 || hdmi->hdmi_data.vic == 3 || - hdmi->hdmi_data.vic == 17 || hdmi->hdmi_data.vic == 18) - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601; - else - hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709; hdmi->tmdsclk = mode->clock * 1000;