Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp780820rdh; Thu, 23 Nov 2023 19:18:16 -0800 (PST) X-Google-Smtp-Source: AGHT+IGOeF6frRKST51gEwd5PspQjIGgjUuNuXbtHck+sTdTrkwj/EvFRBOyKf19vBZf/+0tFqDG X-Received: by 2002:a17:902:c086:b0:1cd:fbff:211f with SMTP id j6-20020a170902c08600b001cdfbff211fmr1254688pld.66.1700795896177; Thu, 23 Nov 2023 19:18:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700795896; cv=none; d=google.com; s=arc-20160816; b=JLuLNCYXuHGzpaJ8LhYMPeo5oAU6NI3zYoJkvenpyOryUsdpMzGceKEx22bzN7c5AL aQ7AxVcQqaCss/YwDtlE5X2WpRgnjeMah9jdI/2Ku/AXydxz/uP4bU2p7B30m1pwSW8j cochmwyURu6YobUEC5asFiAX5Rr3nwd79oMncDM0OyIPM48TMBL+81Gvw31/cy0UTDZR lGJsvfxaTCCKTQC/XmQ6F71euKALk7ih6eUsXwyfFBrY6XDrwv+3fJvKnQQqVSD8iNhU s9dXaLC3K3P2Cn649IaJKqwd/2jj4lqoy5jo3zJJOIVANhOslLzrxgljJeDe7alnB1aw /pwA== 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:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=E1uwfkSjmCfXCZeYRdm+oiAgspLZgUeCqcA2/4m3/ts=; fh=5NoL9MblDMHcPXBgMcKp30yW+j4MEs5ZlOQ+0lqA0l8=; b=0bUBdmC3jIfY7MGVSR10ZmEKyS+QxcsO8tIFFCMwtnapY8M22LGKY50ffrkZJOq5H+ Ic82+mA4VOOEZGFJrXCJBDYSnaFjoexHYr6bGl1vnw5dKxvf+Tf6yBHSDKyxYOfC+lJk MNVA3yoRVlr3ImP+KkVrwLOAVAfhkjErUOOlVc9JVa0gXWZ5io6SXWeUCHFmg05cAzXd r0KaWM6VA8hx48KF+AjNh+j2MWQzfoGkz5zUizuE4mUmZsPAIAETvCSATdm0joM6VnMw V37IqqP6wApuG75HYDTK9jemVkOFJeXkpP6C8TjzCfs0i5xgqd7YqXa9wtavP3b8V/m4 AzeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rock-chips.com header.s=default header.b=TvyncbnD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=rock-chips.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id q16-20020a170902eb9000b001bdd58f685fsi2564076plg.85.2023.11.23.19.18.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 19:18:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@rock-chips.com header.s=default header.b=TvyncbnD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=rock-chips.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 6CAAE80AEB17; Thu, 23 Nov 2023 19:17:59 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230194AbjKXDRr (ORCPT + 99 others); Thu, 23 Nov 2023 22:17:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbjKXDRq (ORCPT ); Thu, 23 Nov 2023 22:17:46 -0500 Received: from mail-m17233.xmail.ntesmail.com (mail-m17233.xmail.ntesmail.com [45.195.17.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B41E6D5A for ; Thu, 23 Nov 2023 19:17:50 -0800 (PST) DKIM-Signature: a=rsa-sha256; b=TvyncbnD1BwJI/4WtgnViRmweaDkV2vAM3/hFiAU4Nyt29+2TQeCfuqnf4N8HNV2sO5Ne3GPGjJKeztV6pJAZYWQ2Ab38CxnMMWC5h3pJbJvcEL3P/cgTqejznrLaC0MKMdbGtMlcDqx2lIp2XlW+tMnSG2AoGrtx1b+TpjBMzg=; c=relaxed/relaxed; s=default; d=rock-chips.com; v=1; bh=E1uwfkSjmCfXCZeYRdm+oiAgspLZgUeCqcA2/4m3/ts=; h=date:mime-version:subject:message-id:from; Received: from [172.16.12.141] (unknown [58.22.7.114]) by mail-m12762.qiye.163.com (Hmail) with ESMTPA id B16C75C0408; Fri, 24 Nov 2023 11:17:24 +0800 (CST) Message-ID: Date: Fri, 24 Nov 2023 11:17:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format Content-Language: en-US To: Johan Jonker , Heiko Stuebner , hjc@rock-chips.com 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: <4308014.ejJDZkT8p0@phil> From: Andy Yan In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFDSUNOT01LS0k3V1ktWUFJV1kPCRoVCBIfWUFZGk5KSVZIGkseSxkaQksYSxhVEwETFh oSFyQUDg9ZV1kYEgtZQVlOQ1VJSVVMVUpKT1lXWRYaDxIVHRRZQVlPS0hVSk1PSUxOVUpLS1VKQk tLWQY+ X-HM-Tid: 0a8bff55093fb229kuuub16c75c0408 X-HM-MType: 1 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PRw6KTo5ETw6LC8YMQs1EUoW ISxPFCNVSlVKTEtLTEJOQ09OQ01KVTMWGhIXVRoVHwJVAhoVOwkUGBBWGBMSCwhVGBQWRVlXWRIL WUFZTkNVSUlVTFVKSk9ZV1kIAVlBQ0tMSzcG X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED,URI_DOTEDU autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 23 Nov 2023 19:17:59 -0800 (PST) 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 >> 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