| Message ID | 20221014221121.7497-2-quic_molvera@quicinc.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp403124wrs;
Fri, 14 Oct 2022 15:31:43 -0700 (PDT)
X-Google-Smtp-Source:
AMsMyM4rdJY8M2WGia9lulGXQxMLX+Kw0YKPBkN02DqrtPWD8+AUpJOO3Ctjoe5WuPhnCMTmZAUx
X-Received: by 2002:a17:907:6ea1:b0:783:cc69:342 with SMTP id
sh33-20020a1709076ea100b00783cc690342mr112818ejc.97.1665786702983;
Fri, 14 Oct 2022 15:31:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1665786702; cv=none;
d=google.com; s=arc-20160816;
b=tWdp+pEbd1Bf3v5iJ0kEt3lUy/yd+mowgmiVjCwgqtXXk7NdYaS2yoJv4zHCgJYWEz
Veo7Wh9iJIpDZdCZ3MUswiuuYmF0sLtV5oIIRiC9Djt1cDyq/3tsjc8gATQR9LnVAwug
zZQWuZUJ/kgHeyurh5sPn+6CmHkdLez0B4yUl90h2ba3SZuw+ktmPxy4XYxvzL/pviyZ
CtUE8TR5WBuCNhkuY3Lxo4QAFPQ7SEQceMKmpqcFTVzN7wBzfLNdXbxLd8Ejwbd9Fts6
jTZgGwgItRBdx//THo00tRb6EB+RZKZBsV7iFJN6qgwQaGJ7DMmPCT5xpGBGEWUWUPZo
p+Vw==
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=3+JzfZN351f5CPgINbyI8EkYTpUxj/3CJwM0A6tPQbY=;
b=d552EjLtw5J674DJRRcLVNO5fXltvXC76vlRLY21Fs8uNpTgiEWQOz4gHj3gN6BIh2
i73tydDncTmpp4dUemF20btqkkNWtq1VorX4alfDqmGjRnnyGfyRCZEILF6DleOP9SQk
3h859Rbw1LHuM8GZijlED6D+6R5Dkgo191/beaXEDNfdWoWtrGudVD+RxdAOLh108v5b
dm5mIIXtuDsNfmK2mNP3FFw96f7b2HLWyxb3cHRqrqtOYD9Jb1qC9504yG6KurrNxENg
/+yXDYp3qnYgp1opw+15Lj80zR6v0Gc2VuLVIZ9K7wh5XkbXJL83RqXKc8/SOLCpp8Uy
y6tw==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=bD200Upd;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
sh40-20020a1709076ea800b0078d288c1047si3518969ejc.841.2022.10.14.15.31.04;
Fri, 14 Oct 2022 15:31:42 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=bD200Upd;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S230100AbiJNWNe (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others);
Fri, 14 Oct 2022 18:13:34 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45936 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S229892AbiJNWMj (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 14 Oct 2022 18:12:39 -0400
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com
[199.106.114.39])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61C7B1D2992;
Fri, 14 Oct 2022 15:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim;
t=1665785539; x=1697321539;
h=from:to:cc:subject:date:message-id:in-reply-to:
references:mime-version:content-transfer-encoding;
bh=3+JzfZN351f5CPgINbyI8EkYTpUxj/3CJwM0A6tPQbY=;
b=bD200UpdzrQMBLvVTcuqy9904QmKqcTXSL1KXPY+EddRfucNiGyYwOr4
tTJY+PFm6MxvGlUBa1r0/uo3pqacNpKu2Fkc4AkG0s2Fasofo5SO/xwBw
AO+Ci+d9YOBC5EBR9D9TKgAJX4NnhKJU541XLjMkbwIPC0HbCdgnYdchT
c=;
Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30])
by alexa-out-sd-02.qualcomm.com with ESMTP; 14 Oct 2022 15:11:52 -0700
X-QCInternal: smtphost
Received: from nasanex01b.na.qualcomm.com ([10.46.141.250])
by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
14 Oct 2022 15:11:52 -0700
Received: from hu-molvera-sd.qualcomm.com (10.80.80.8) by
nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.2.986.29; Fri, 14 Oct 2022 15:11:37 -0700
From: Melody Olvera <quic_molvera@quicinc.com>
To: Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
CC: Robert Marko <robimarko@gmail.com>,
Guru Das Srinagesh <quic_gurus@quicinc.com>,
<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Melody Olvera <quic_molvera@quicinc.com>
Subject: [PATCH v2 1/4] dt-bindings: firmware: scm: Add QDU1000/QRU1000
compatibles
Date: Fri, 14 Oct 2022 15:11:18 -0700
Message-ID: <20221014221121.7497-2-quic_molvera@quicinc.com>
X-Mailer: git-send-email 2.38.0
In-Reply-To: <20221014221121.7497-1-quic_molvera@quicinc.com>
References: <20221014221121.7497-1-quic_molvera@quicinc.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To
nasanex01b.na.qualcomm.com (10.46.141.250)
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,
SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?=
X-GMAIL-THRID: =?utf-8?q?1746703958160060883?=
X-GMAIL-MSGID: =?utf-8?q?1746703958160060883?=
|
| Series |
Add misc support for QDU1000/QRU1000 SoCs
|
|
Commit Message
Melody Olvera
Oct. 14, 2022, 10:11 p.m. UTC
Add compatibles for scm driver for QDU1000 and QRU1000 platforms.
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
---
.../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
On 14/10/2022 18:11, Melody Olvera wrote: > Add compatibles for scm driver for QDU1000 and QRU1000 platforms. > > Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> > --- > .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml > index c5b76c9f7ad0..47083f47f109 100644 > --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml > +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml > @@ -38,6 +38,8 @@ properties: > - qcom,scm-msm8994 > - qcom,scm-msm8996 > - qcom,scm-msm8998 > + - qcom,scm-qdu1000 > + - qcom,scm-qru1000 Why exactly we are no using qdu1000 as fallback? That was the recommendation in previous discussion. Patch is still incomplete - you still do no have proper changes in allOf for the clocks. If you want to say that this SoC does not take any clocks as input, then they should not be allowed. Best regards, Krzysztof
On 10/15/2022 6:34 AM, Krzysztof Kozlowski wrote: > On 14/10/2022 18:11, Melody Olvera wrote: >> Add compatibles for scm driver for QDU1000 and QRU1000 platforms. >> >> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >> --- >> .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >> index c5b76c9f7ad0..47083f47f109 100644 >> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >> @@ -38,6 +38,8 @@ properties: >> - qcom,scm-msm8994 >> - qcom,scm-msm8996 >> - qcom,scm-msm8998 >> + - qcom,scm-qdu1000 >> + - qcom,scm-qru1000 > Why exactly we are no using qdu1000 as fallback? That was the > recommendation in previous discussion. Will use only qdu; I think I misunderstood the outcome of that discussion. > > Patch is still incomplete - you still do no have proper changes in allOf > for the clocks. If you want to say that this SoC does not take any > clocks as input, then they should not be allowed. That is what I'm trying to say; it seems most of our most recent SoCs (sm8*) don't have any clocks associated with the scm. Does it make sense to remove the minItems earlier in the binding, or is there something else that would communicate this in allOf better? Thanks, Melody
On 19/10/2022 14:08, Melody Olvera wrote: > > > On 10/15/2022 6:34 AM, Krzysztof Kozlowski wrote: >> On 14/10/2022 18:11, Melody Olvera wrote: >>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms. >>> >>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>> --- >>> .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>> index c5b76c9f7ad0..47083f47f109 100644 >>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>> @@ -38,6 +38,8 @@ properties: >>> - qcom,scm-msm8994 >>> - qcom,scm-msm8996 >>> - qcom,scm-msm8998 >>> + - qcom,scm-qdu1000 >>> + - qcom,scm-qru1000 >> Why exactly we are no using qdu1000 as fallback? That was the >> recommendation in previous discussion. > Will use only qdu; I think I misunderstood the outcome of that discussion. Actually, I think I commented about this in wrong patch. I think the outcome was to use two compatibles for most of the cases, but as a fallback, so: QDU: "qcom,qdu1000-rpmhpd" QRU: "qcom,qru1000-rpmhpd", "qcom,qdu1000-rpmhpd" (or skip entirely second if you do not customize QRU in DTSI) However here we already have a fallback, so these are fine: "qcom,scm-qdu1000", "qcom,scm" "qcom,scm-qru1000", "qcom,scm" Still assuming you customize them in DTSI... which does not seem the case, right? >> >> Patch is still incomplete - you still do no have proper changes in allOf >> for the clocks. If you want to say that this SoC does not take any >> clocks as input, then they should not be allowed. > That is what I'm trying to say; it seems most of our most recent SoCs (sm8*) don't have any > clocks associated with the scm. Does it make sense to remove the minItems earlier > in the binding, or is there something else that would communicate this in allOf better? > Then disallow clocks for your variant: - if: .... then: ... clocks: false clock-names: false Best regards, Krzysztof
On 10/20/2022 5:35 AM, Krzysztof Kozlowski wrote: > On 19/10/2022 14:08, Melody Olvera wrote: >> >> On 10/15/2022 6:34 AM, Krzysztof Kozlowski wrote: >>> On 14/10/2022 18:11, Melody Olvera wrote: >>>> Add compatibles for scm driver for QDU1000 and QRU1000 platforms. >>>> >>>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>>> --- >>>> .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++ >>>> 1 file changed, 16 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>> index c5b76c9f7ad0..47083f47f109 100644 >>>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml >>>> @@ -38,6 +38,8 @@ properties: >>>> - qcom,scm-msm8994 >>>> - qcom,scm-msm8996 >>>> - qcom,scm-msm8998 >>>> + - qcom,scm-qdu1000 >>>> + - qcom,scm-qru1000 >>> Why exactly we are no using qdu1000 as fallback? That was the >>> recommendation in previous discussion. >> Will use only qdu; I think I misunderstood the outcome of that discussion. > Actually, I think I commented about this in wrong patch. I think the > outcome was to use two compatibles for most of the cases, but as a > fallback, so: > > QDU: "qcom,qdu1000-rpmhpd" > QRU: "qcom,qru1000-rpmhpd", "qcom,qdu1000-rpmhpd" > (or skip entirely second if you do not customize QRU in DTSI) > > However here we already have a fallback, so these are fine: > > "qcom,scm-qdu1000", "qcom,scm" > "qcom,scm-qru1000", "qcom,scm" > > Still assuming you customize them in DTSI... which does not seem the > case, right? Yeah dtsi is largely shared between RU and DU. It probably makes more sense to drop RU compat string all together unless there is a significant difference. >>> Patch is still incomplete - you still do no have proper changes in allOf >>> for the clocks. If you want to say that this SoC does not take any >>> clocks as input, then they should not be allowed. >> That is what I'm trying to say; it seems most of our most recent SoCs (sm8*) don't have any >> clocks associated with the scm. Does it make sense to remove the minItems earlier >> in the binding, or is there something else that would communicate this in allOf better? >> > > Then disallow clocks for your variant: > > - if: > .... > then: > ... > clocks: false > clock-names: false Got it; thanks. Thanks, Melody
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index c5b76c9f7ad0..47083f47f109 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -38,6 +38,8 @@ properties: - qcom,scm-msm8994 - qcom,scm-msm8996 - qcom,scm-msm8998 + - qcom,scm-qdu1000 + - qcom,scm-qru1000 - qcom,scm-sc7180 - qcom,scm-sc7280 - qcom,scm-sc8280xp @@ -80,6 +82,20 @@ properties: description: TCSR hardware block allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,scm-qdu1000 + - qcom,scm-qru1000 + then: + properties: + '#reset-cells': + maxItems: 1 + + required: + - '#reset-cells' - if: properties: compatible: