Message ID | 20231213195125.212923-2-knaerzche@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp8030249dys; Wed, 13 Dec 2023 11:51:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IEyL6Rs3CvXAxI0nvOut3gY0SdD1OnifdxIluc6/7rcBw43viL3KO4DKwO0vhiB7sQISlcP X-Received: by 2002:a17:902:ab16:b0:1d3:6238:a527 with SMTP id ik22-20020a170902ab1600b001d36238a527mr540827plb.5.1702497096467; Wed, 13 Dec 2023 11:51:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702497096; cv=none; d=google.com; s=arc-20160816; b=gFeeqGIBqpSBfc6n0bY5tzJh9rPK1TDZVjcr00in59AjdQqVSupYWWnJi7ucvQi9Ht WcbKPucbhjgHzwaEQYULOSEaOIYvUXne7wYVdi21fhT12UaVzd1YKkPa3SQ894QLLcXo TA8amUZi65R43CbN7lhCLhP/mIJ41BLejAFl33+wxYJucrDCduQOtUeXraR4nImnCFqV 6qQpvEcFSFlvk0ffszZVgaR4+DbGTtNAJsVfYSa4QINrDlP1MWh8YlMf7CsE8EtGlZsD UVoMxHrOg1iJI7ZCmdOcDxd+t4Vz3v1kalZrsxpbnwUAtT6SBHajEj7aUSAzVRZgI9AW Pt4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ERQju2Bh+K8GCwYjh7yY4rIstgFgSHVz3s7kTSLi67E=; fh=nzMX5Jolb3GculGR3f1Z1ReHOqdNjcdazDY5R3X+7M0=; b=mzI24DZ9NRZcwi16RrttF/OItSa7jy7ZmA7IHqKmLINoBcehRD9O4m8wyl0sLlZjlJ h2xh143I6DETRHLQIS/XA5O2qS+3lV+g3aQ7k1Rn84FlRnMlIGc/yMWvb4/hu5seZnlj WC+OFkxbTLp0S4JfCyVJVJA8pY+b2Ahnsa7USaEdLGuUNexrbhzoGs0YFET0VP2rr7n0 G9DLYw7ybsQwuiphX0xpCKC9yjK4m8rl7jXwHuv8MuvX+tXNeUX99pcY0XRD2AV78Y0H qV8UXrjxQqqpNuYO7h0Y2Udub9GiRX5lksim9U7Tmmz42ITKvTi4cA+qp7kDquw8JxLz b1pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PxZpM4Vq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 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. [23.128.96.35]) by mx.google.com with ESMTPS id l4-20020a170903244400b001d09278b856si10326400pls.347.2023.12.13.11.51.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 11:51:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=PxZpM4Vq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 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 3AFEE80CFD08; Wed, 13 Dec 2023 11:51:32 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233726AbjLMTvX (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 13 Dec 2023 14:51:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233170AbjLMTvW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Dec 2023 14:51:22 -0500 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 26D88D0; Wed, 13 Dec 2023 11:51:29 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40c580ba223so17946695e9.3; Wed, 13 Dec 2023 11:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702497087; x=1703101887; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ERQju2Bh+K8GCwYjh7yY4rIstgFgSHVz3s7kTSLi67E=; b=PxZpM4VqAjX3hh3w7KfL7gHasGC60x2FIBV0oJfRcWeCf730qRvLCvHEv4cbtm4f9w H64G85TBhH4YvcQaScyCHw3FpcTADlrtONEAaXTVVMQu9TLJ19BbvRtZaZlokbjkc8hJ yWLvUthOomVkZM2wr7Bgbr8uvyRUHwJFW77Y5PIL1twF2TYLkUhxx3A+RspE82hdSMUf JbWUnMMpp8sfQkTpc/BKk86R1r8Xf5jKCAArMXJf+ARu2hMxw0mM7A9cxmkvNMs3Ma2m 0lG8WQY116WdWGTDkhZKuHuVwqfYGRdG5y4Ctjh1UovgRYySbtkVKETXxCI/babj0X7O wIzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702497087; x=1703101887; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ERQju2Bh+K8GCwYjh7yY4rIstgFgSHVz3s7kTSLi67E=; b=blNblyK/bKxDkfKd4vmOx30ygSiKC9vU6brHtyV9JDFPEpjpl7nopnNmOmWYEShuZh EuRST/QEUaaOJARtktpcob5zDQHNSZ3xcAHLnxnVXmFT8FIBF/cTVY4Wb2Yun8bMVPsR zOrPOKRQH5HGIK4LA9bZbIhnieQU9k9nhO3ZmC9u4dieF0QA6OfkUHbke5F0/xdoZNnI HEMc5669MmrBtglMSOnPyslvcTh9ShokI9/yRX0RBay83NacixGayNuLEbYQd9iHJwFa +oVKfhMV8bO9ZwFL8Z0h6Q4GG4hNLQWJWPGww73zd8ePp752gMAJKAv0aZnHLkBUDmiy l8Og== X-Gm-Message-State: AOJu0YxU43Ff2dCXKCTEDVHJKPTEXe1b70xTznpIMsNIBdSLW5tfb8ij C7rE/mYvyQ1I82Lb2iSsUQ== X-Received: by 2002:a05:600c:54f1:b0:40b:5e21:dd2a with SMTP id jb17-20020a05600c54f100b0040b5e21dd2amr4691135wmb.88.1702497087589; Wed, 13 Dec 2023 11:51:27 -0800 (PST) Received: from U4.lan ([2a02:810b:f40:4300:92dc:8b1c:e01c:b93c]) by smtp.gmail.com with ESMTPSA id fm14-20020a05600c0c0e00b00407b93d8085sm24050698wmb.27.2023.12.13.11.51.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 11:51:27 -0800 (PST) From: Alex Bee <knaerzche@gmail.com> To: Sandy Huang <hjc@rock-chips.com>, =?utf-8?q?Heiko_St=C3=BCbner?= <heiko@sntech.de>, Andy Yan <andyshrk@163.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Alex Bee <knaerzche@gmail.com> Subject: [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible Date: Wed, 13 Dec 2023 20:51:15 +0100 Message-ID: <20231213195125.212923-2-knaerzche@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231213195125.212923-1-knaerzche@gmail.com> References: <20231213195125.212923-1-knaerzche@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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]); Wed, 13 Dec 2023 11:51:32 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785197595291785959 X-GMAIL-MSGID: 1785197595291785959 |
Series |
Add HDMI support for RK3128
|
|
Commit Message
Alex Bee
Dec. 13, 2023, 7:51 p.m. UTC
Document the compatible for RK3128's HDMI controller block.
The integration for this SoC is somewhat different here: It needs the PHY's
reference clock rate to calculate the ddc bus frequency correctly. This
clock is part of a power-domain (PD_VIO), so this gets added as an optional
property too.
Signed-off-by: Alex Bee <knaerzche@gmail.com>
---
.../display/rockchip/rockchip,inno-hdmi.yaml | 30 +++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
Comments
On 13/12/2023 20:51, Alex Bee wrote: > Document the compatible for RK3128's HDMI controller block. > The integration for this SoC is somewhat different here: It needs the PHY's Please wrap commit message according to Linux coding style / submission process (neither too early nor over the limit): https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 > reference clock rate to calculate the ddc bus frequency correctly. This > clock is part of a power-domain (PD_VIO), so this gets added as an optional > property too. If clock is part of power domain, then the power domain must be in the clock controller, not here. So either you put power domain in wrong place or you used incorrect reason for a change. > > Signed-off-by: Alex Bee <knaerzche@gmail.com> > --- > .../display/rockchip/rockchip,inno-hdmi.yaml | 30 +++++++++++++++++-- > 1 file changed, 28 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > index 96889c86849a..9f00abcbfb38 100644 > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml > @@ -14,6 +14,7 @@ properties: > compatible: > enum: > - rockchip,rk3036-inno-hdmi > + - rockchip,rk3128-inno-hdmi > > reg: > maxItems: 1 > @@ -22,10 +23,21 @@ properties: > maxItems: 1 > > clocks: > - maxItems: 1 > + minItems: 1 > + items: > + - description: The HDMI controller main clock > + - description: The HDMI PHY reference clock > > clock-names: > - const: pclk > + minItems: 1 > + items: > + - const: pclk > + - enum: > + - pclk > + - ref That's way overcomplicated. Just items listing the names and minItems: 1. See other bindings how this is done. > + > + power-domains: > + maxItems: 1 Is it relevant to existing device? > > ports: > $ref: /schemas/graph.yaml#/properties/ports > @@ -55,6 +67,20 @@ required: > - pinctrl-names > - ports Best regards, Krzysztof
Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski: > On 13/12/2023 20:51, Alex Bee wrote: >> Document the compatible for RK3128's HDMI controller block. >> The integration for this SoC is somewhat different here: It needs the PHY's > Please wrap commit message according to Linux coding style / submission > process (neither too early nor over the limit): > https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 OK. Not sure why checkpatch --strict didn't tell me that I'm over the limit here. > >> reference clock rate to calculate the ddc bus frequency correctly. This >> clock is part of a power-domain (PD_VIO), so this gets added as an optional >> property too. > If clock is part of power domain, then the power domain must be in the > clock controller, not here. So either you put power domain in wrong > place or you used incorrect reason for a change. Rockchip defines it's powerdomains per clock and I was little to much in that world when writing this. Actually the controller itself is part of the powerdomain. Will rephrase. >> Signed-off-by: Alex Bee <knaerzche@gmail.com> >> --- >> .../display/rockchip/rockchip,inno-hdmi.yaml | 30 +++++++++++++++++-- >> 1 file changed, 28 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >> index 96889c86849a..9f00abcbfb38 100644 >> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >> @@ -14,6 +14,7 @@ properties: >> compatible: >> enum: >> - rockchip,rk3036-inno-hdmi >> + - rockchip,rk3128-inno-hdmi >> >> reg: >> maxItems: 1 >> @@ -22,10 +23,21 @@ properties: >> maxItems: 1 >> >> clocks: >> - maxItems: 1 >> + minItems: 1 >> + items: >> + - description: The HDMI controller main clock >> + - description: The HDMI PHY reference clock >> >> clock-names: >> - const: pclk >> + minItems: 1 >> + items: >> + - const: pclk >> + - enum: >> + - pclk >> + - ref > That's way overcomplicated. Just items listing the names and minItems: > 1. See other bindings how this is done. OK. >> + >> + power-domains: >> + maxItems: 1 > Is it relevant to existing device? Will move to new variant only. Alex >> >> ports: >> $ref: /schemas/graph.yaml#/properties/ports >> @@ -55,6 +67,20 @@ required: >> - pinctrl-names >> - ports > > Best regards, > Krzysztof >
On 14/12/2023 16:22, Alex Bee wrote: > > Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski: >> On 13/12/2023 20:51, Alex Bee wrote: >>> Document the compatible for RK3128's HDMI controller block. >>> The integration for this SoC is somewhat different here: It needs the PHY's >> Please wrap commit message according to Linux coding style / submission >> process (neither too early nor over the limit): >> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 > OK. Not sure why checkpatch --strict didn't tell me that I'm over the > limit here. >> >>> reference clock rate to calculate the ddc bus frequency correctly. This >>> clock is part of a power-domain (PD_VIO), so this gets added as an optional >>> property too. >> If clock is part of power domain, then the power domain must be in the >> clock controller, not here. So either you put power domain in wrong >> place or you used incorrect reason for a change. > Rockchip defines it's powerdomains per clock and I was little to much > in that world when writing this. Actually the controller itself is part > of the powerdomain. Will rephrase. Does it mean you have like 200 different power domains in one SoC? Then how are they different than clock if there is one-to-one mapping? >>> Signed-off-by: Alex Bee <knaerzche@gmail.com> >>> --- >>> .../display/rockchip/rockchip,inno-hdmi.yaml | 30 +++++++++++++++++-- >>> 1 file changed, 28 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >>> index 96889c86849a..9f00abcbfb38 100644 >>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml >>> @@ -14,6 +14,7 @@ properties: >>> compatible: >>> enum: >>> - rockchip,rk3036-inno-hdmi >>> + - rockchip,rk3128-inno-hdmi >>> >>> reg: >>> maxItems: 1 >>> @@ -22,10 +23,21 @@ properties: >>> maxItems: 1 >>> >>> clocks: >>> - maxItems: 1 >>> + minItems: 1 >>> + items: >>> + - description: The HDMI controller main clock >>> + - description: The HDMI PHY reference clock >>> >>> clock-names: >>> - const: pclk >>> + minItems: 1 >>> + items: >>> + - const: pclk >>> + - enum: >>> + - pclk >>> + - ref >> That's way overcomplicated. Just items listing the names and minItems: >> 1. See other bindings how this is done. > OK. >>> + >>> + power-domains: >>> + maxItems: 1 >> Is it relevant to existing device? > > Will move to new variant only. > Definition should be here, but in if:then: it should be disallowed (:false) for other variants. Best regards, Krzysztof
Am Donnerstag, 14. Dezember 2023, 17:07:27 CET schrieb Krzysztof Kozlowski: > On 14/12/2023 16:22, Alex Bee wrote: > > > > Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski: > >> On 13/12/2023 20:51, Alex Bee wrote: > >>> Document the compatible for RK3128's HDMI controller block. > >>> The integration for this SoC is somewhat different here: It needs the PHY's > >> Please wrap commit message according to Linux coding style / submission > >> process (neither too early nor over the limit): > >> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 > > OK. Not sure why checkpatch --strict didn't tell me that I'm over the > > limit here. > >> > >>> reference clock rate to calculate the ddc bus frequency correctly. This > >>> clock is part of a power-domain (PD_VIO), so this gets added as an optional > >>> property too. > >> If clock is part of power domain, then the power domain must be in the > >> clock controller, not here. So either you put power domain in wrong > >> place or you used incorrect reason for a change. > > Rockchip defines it's powerdomains per clock and I was little to much > > in that world when writing this. Actually the controller itself is part > > of the powerdomain. Will rephrase. > > Does it mean you have like 200 different power domains in one SoC? Then > how are they different than clock if there is one-to-one mapping? It's more like the other way around. Controllers and their clocks belong to specific power-domains. So there are of course more clocks than domains.
On 14/12/2023 17:20, Heiko Stübner wrote: > Am Donnerstag, 14. Dezember 2023, 17:07:27 CET schrieb Krzysztof Kozlowski: >> On 14/12/2023 16:22, Alex Bee wrote: >>> >>> Am 14.12.23 um 08:53 schrieb Krzysztof Kozlowski: >>>> On 13/12/2023 20:51, Alex Bee wrote: >>>>> Document the compatible for RK3128's HDMI controller block. >>>>> The integration for this SoC is somewhat different here: It needs the PHY's >>>> Please wrap commit message according to Linux coding style / submission >>>> process (neither too early nor over the limit): >>>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597 >>> OK. Not sure why checkpatch --strict didn't tell me that I'm over the >>> limit here. >>>> >>>>> reference clock rate to calculate the ddc bus frequency correctly. This >>>>> clock is part of a power-domain (PD_VIO), so this gets added as an optional >>>>> property too. >>>> If clock is part of power domain, then the power domain must be in the >>>> clock controller, not here. So either you put power domain in wrong >>>> place or you used incorrect reason for a change. >>> Rockchip defines it's powerdomains per clock and I was little to much >>> in that world when writing this. Actually the controller itself is part >>> of the powerdomain. Will rephrase. >> >> Does it mean you have like 200 different power domains in one SoC? Then >> how are they different than clock if there is one-to-one mapping? > > It's more like the other way around. Controllers and their clocks belong > to specific power-domains. So there are of course more clocks than domains. That's fine and expected. Here the comment was suggested that you need to add power-domain because clock is in power-domain. That would be clearly wrong and instead the clock controller should model the power domain relationship. > > > > Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml index 96889c86849a..9f00abcbfb38 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,inno-hdmi.yaml @@ -14,6 +14,7 @@ properties: compatible: enum: - rockchip,rk3036-inno-hdmi + - rockchip,rk3128-inno-hdmi reg: maxItems: 1 @@ -22,10 +23,21 @@ properties: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + items: + - description: The HDMI controller main clock + - description: The HDMI PHY reference clock clock-names: - const: pclk + minItems: 1 + items: + - const: pclk + - enum: + - pclk + - ref + + power-domains: + maxItems: 1 ports: $ref: /schemas/graph.yaml#/properties/ports @@ -55,6 +67,20 @@ required: - pinctrl-names - ports +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3128-inno-hdmi + + then: + properties: + clocks: + minItems: 2 + clock-names: + minItems: 2 + additionalProperties: false examples: