Message ID | 20230113145859.82868-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp324698wrt; Fri, 13 Jan 2023 07:16:49 -0800 (PST) X-Google-Smtp-Source: AMrXdXsnNr9wIgP6QtfZ5cl0aGCvFUENXE0AcL3ejyf17c2g72VmC5DsEOyLK0s0gymEhhIPRuvH X-Received: by 2002:a05:6a00:248f:b0:581:4539:3992 with SMTP id c15-20020a056a00248f00b0058145393992mr83669228pfv.25.1673623007607; Fri, 13 Jan 2023 07:16:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673623007; cv=none; d=google.com; s=arc-20160816; b=RmW5sahC3CIF3WFtDD+QQxmHZoHZuPZJwDlDPl0OVgNsq3mPkuTdyYy6QE2wdr0VEb wwiI9dBzWbRwiIjkyx7GzDCd7bfmfCSdjitb6yLpo4UeE1sddbvsItUGk8Ux6TJcUqi6 fPYPOmnPE7KAAI5GAaASOAM0Ko9jlICEzSVzh0FLT4tKkJd15UPL43clvfl0qvBnnPil a3Y1NQt6yemR7uSSHflhS3wnte6Zw/0T6HDh6gL1b/f26c80F84JWRbD83sSHi9Iq685 05ZuYJDLvVOaOJWCOWvh16JqRX2rzHiUW3m35usySJIgrRpwmEHkV3nYyPidmJ4e8fYd +j6w== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=XU/dHO8DVmGPpqkb7r01X1pAdFG84fFdf1WtxGiiHvQ=; b=GRZDQjLvZMaKfH8NAoQesOuthqCcs8AaGLmcEyEj5eyc5DO1Xr8KgybpTdkzmyk3oh 9x4Wug4aCClRjHSd2PVzoWkJCl9EhU6KSG3SkmqdYbXGpoRxvs9ZEnegVg8fXqzLg0Y5 gnwBOY1CHScgDlUSCzt1m12PgPteX8IVI5gNnPHgKzIGxf6TbV420lYEfRR8YEgeEuio gnHCLCkMIaCF0iO+bYPwKilRDVA1wquZWY77TxzpuFgFMCUsodhpOeYA6TJ/fu7ntv0C SFCsMChaBTk8fmnLgBWiUpDmy+rzOePNdkd+fqDOi+KCTMSOU5M1VpIF+twDUkFN0aD6 +G2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ARnoDLge; 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=linaro.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r5-20020aa79885000000b0057f905fb1easi21072575pfl.335.2023.01.13.07.16.35; Fri, 13 Jan 2023 07:16:47 -0800 (PST) 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=@linaro.org header.s=google header.b=ARnoDLge; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229707AbjAMPJa (ORCPT <rfc822;callmefire3@gmail.com> + 99 others); Fri, 13 Jan 2023 10:09:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229823AbjAMPH5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 13 Jan 2023 10:07:57 -0500 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 9B671983CD for <linux-kernel@vger.kernel.org>; Fri, 13 Jan 2023 06:59:03 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id az20so33849241ejc.1 for <linux-kernel@vger.kernel.org>; Fri, 13 Jan 2023 06:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=XU/dHO8DVmGPpqkb7r01X1pAdFG84fFdf1WtxGiiHvQ=; b=ARnoDLgerC10W1udjRPEt/GqBBzqwMsZyw7cRxy9pAmrdaWhWipPNrxDp8DBWRpYG+ Iea+vxk4XoiUXFG//j9I13kfV+No6IlbMzurvbDOSa8gJIJ7jVIhkQwtRNZC2GtD/WQl 79tRkeKdEqvkoIvDjk7Eg6qqOwqxqDhh3dkJHf/2TMxpGesmbtrczYR68uFVNXqOd7Mg 9vvQ/zaF+WdZCC567si2DOhLTihqGrCKEIJ/GpoR+zyrxB4HLBzDz28JUWXMonFTufTi tzrEcMZoHzRylV3/dN2XRl+t+JSa6Mg/8+Cn18L2q7Lqr8VfmriCR0tI1KaRlhtW1+L0 nZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XU/dHO8DVmGPpqkb7r01X1pAdFG84fFdf1WtxGiiHvQ=; b=waseYF/EB2xNqDmL8DFPHAyxooogqEccENzJ70BYfNreYR6ocxGLp0qDlMmgwq/yqS KQu4GclKvUZWED/oH2rtjpoYVXx/LNWkDd7FeRSLuEijFYs/44mV9Edjnv9NAn7TDRKd iC60Y/W7jIEX7temC6Ka3dM3lCHOfW1o5c0+kfLoMu6SlC10mpN6SOvyRKHRO28qEPCw Ov4xwl4LcNcAKiciJLObgM6kiNNepbrtkYEqf8enOyFCb4tzep3bV0MsLAKmHLr0A1vj +Kp9hK3ogR6Cek0kLwRCxR93nvwQyqy2tAhB6LqWQmzZK5jXX6tD30bEg2pbXSponEZU 4nVw== X-Gm-Message-State: AFqh2kq43uz2pfkYxJ6BJVpfKECJFrbmjY1RZ6Nk81oIj2oScpa3dHLw +vDZv1pF8wMxHL1d2Fw11Vr5Lw== X-Received: by 2002:a17:906:2813:b0:7c0:f9ef:23a2 with SMTP id r19-20020a170906281300b007c0f9ef23a2mr84066794ejc.30.1673621942178; Fri, 13 Jan 2023 06:59:02 -0800 (PST) Received: from krzk-bin.. ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id f1-20020a17090631c100b007aea1dc1840sm8621468ejf.111.2023.01.13.06.59.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 06:59:01 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Bjorn Andersson <andersson@kernel.org>, Andy Gross <agross@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH] dt-bindings: clock: qcom,a53pll: drop operating-points-v2 Date: Fri, 13 Jan 2023 15:58:59 +0100 Message-Id: <20230113145859.82868-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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?1754920918561337242?= X-GMAIL-MSGID: =?utf-8?q?1754920918561337242?= |
Series |
dt-bindings: clock: qcom,a53pll: drop operating-points-v2
|
|
Commit Message
Krzysztof Kozlowski
Jan. 13, 2023, 2:58 p.m. UTC
The CPU PLL clock node does not use OPP tables (neither driver).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 2 --
1 file changed, 2 deletions(-)
Comments
Quoting Krzysztof Kozlowski (2023-01-13 06:58:59)
> The CPU PLL clock node does not use OPP tables (neither driver).
What device is qcom_a53pll_get_freq_tbl() operating on?
On 13/01/2023 21:28, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >> The CPU PLL clock node does not use OPP tables (neither driver). > > What device is qcom_a53pll_get_freq_tbl() operating on? On its own, internal table. While of course driver could be converted to operating-points-v2, no one did it within last 5 years, so why it should happen now? Best regards, Krzysztof
On Fri, 13 Jan 2023 15:58:59 +0100, Krzysztof Kozlowski wrote: > The CPU PLL clock node does not use OPP tables (neither driver). > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 2 -- > 1 file changed, 2 deletions(-) > Acked-by: Rob Herring <robh@kernel.org>
Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) > On 13/01/2023 21:28, Stephen Boyd wrote: > > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) > >> The CPU PLL clock node does not use OPP tables (neither driver). > > > > What device is qcom_a53pll_get_freq_tbl() operating on? > > On its own, internal table. While of course driver could be converted to > operating-points-v2, no one did it within last 5 years, so why it should > happen now? > The property was added mid 2021 by Shawn[1], that's not 5 years ago. I guess there were plans to add an OPP table that never happened[2]? Is Shawn still working on this? If not, we should revert the OPP code out of the driver. [1] https://lore.kernel.org/all/20210704024032.11559-4-shawn.guo@linaro.org/ [2] https://lore.kernel.org/all/20210709021334.GB11342@dragon/
On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) > > On 13/01/2023 21:28, Stephen Boyd wrote: > > > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) > > >> The CPU PLL clock node does not use OPP tables (neither driver). > > > > > > What device is qcom_a53pll_get_freq_tbl() operating on? > > > > On its own, internal table. While of course driver could be converted to > > operating-points-v2, no one did it within last 5 years, so why it should > > happen now? > > > > The property was added mid 2021 by Shawn[1], that's not 5 years ago. I > guess there were plans to add an OPP table that never happened[2]? Is > Shawn still working on this? If not, we should revert the OPP code out > of the driver. > @Bryan, what do you think about this? Thanks, Bjorn > [1] https://lore.kernel.org/all/20210704024032.11559-4-shawn.guo@linaro.org/ > [2] https://lore.kernel.org/all/20210709021334.GB11342@dragon/
On 19/01/2023 03:11, Bjorn Andersson wrote: > On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>> >>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>> >>> On its own, internal table. While of course driver could be converted to >>> operating-points-v2, no one did it within last 5 years, so why it should >>> happen now? >>> >> >> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >> guess there were plans to add an OPP table that never happened[2]? Is >> Shawn still working on this? If not, we should revert the OPP code out >> of the driver. >> > > @Bryan, what do you think about this? I'd be in favour of starting the CPR patchset instead, which depends on the opps. I think @Fabien has been waiting on the core 8939 dtsi, I also think the dtsi is close enough to merge that we could reasonably initiate the CPR stuff. --- bod
On 19/01/2023 11:55, Bryan O'Donoghue wrote: > On 19/01/2023 03:11, Bjorn Andersson wrote: >> On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >>> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>>> >>>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>>> >>>> On its own, internal table. While of course driver could be converted to >>>> operating-points-v2, no one did it within last 5 years, so why it should >>>> happen now? >>>> >>> >>> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >>> guess there were plans to add an OPP table that never happened[2]? Is >>> Shawn still working on this? If not, we should revert the OPP code out >>> of the driver. >>> >> >> @Bryan, what do you think about this? > > I'd be in favour of starting the CPR patchset instead, which depends on > the opps. > > I think @Fabien has been waiting on the core 8939 dtsi, I also think the > dtsi is close enough to merge that we could reasonably initiate the CPR > stuff. So you would make use of operating-points-v2 property? Then probably we also miss opp-table, but anyway this patch can be dropped then. Best regards, Krzysztof
On 19/01/2023 11:04, Krzysztof Kozlowski wrote: > On 19/01/2023 11:55, Bryan O'Donoghue wrote: >> On 19/01/2023 03:11, Bjorn Andersson wrote: >>> On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >>>> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>>>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>>>> >>>>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>>>> >>>>> On its own, internal table. While of course driver could be converted to >>>>> operating-points-v2, no one did it within last 5 years, so why it should >>>>> happen now? >>>>> >>>> >>>> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >>>> guess there were plans to add an OPP table that never happened[2]? Is >>>> Shawn still working on this? If not, we should revert the OPP code out >>>> of the driver. >>>> >>> >>> @Bryan, what do you think about this? >> >> I'd be in favour of starting the CPR patchset instead, which depends on >> the opps. >> >> I think @Fabien has been waiting on the core 8939 dtsi, I also think the >> dtsi is close enough to merge that we could reasonably initiate the CPR >> stuff. > > So you would make use of operating-points-v2 property? Then probably we > also miss opp-table, but anyway this patch can be dropped then. > > Best regards, > Krzysztof > Yep. Looks something like this. CPU2: cpu@102 { device_type = "cpu"; compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x102>; next-level-cache = <&L2_1>; enable-method = "qcom,kpss-acc-v2"; qcom,acc = <&acc2>; qcom,saw = <&saw2>; clocks = <&apcs1>; operating-points-v2 = <&cluster1_opp_table>; power-domains = <&cpr>; power-domain-names = "cpr"; #cooling-cells = <2>; capacity-dmips-mhz = <1024>; }; cluster1_opp_table: cluster1-opp-table { compatible = "operating-points-v2-qcom-cpu"; opp-shared; /* Used by qcom-cpufreq-nvmem.c */ nvmem-cells = <&cpr_efuse_speedbin_pvs>; nvmem-cell-names = "cpr_efuse_speedbin_pvs"; opp-200000000 { opp-hz = /bits/ 64 <200000000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; opp-345600000 { opp-hz = /bits/ 64 <345600000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; }; cpr_opp_table: cpr-opp-table { compatible = "operating-points-v2-qcom-level"; cpr_opp1: opp1 { opp-hz = /bits/ 64 <200000000>; opp-level = <1>; qcom,opp-fuse-level = <1>; }; cpr_opp2: opp2 { opp-hz = /bits/ 64 <345600000>; opp-level = <2>; qcom,opp-fuse-level = <1>; }; cpr_opp3: opp3 { opp-hz = /bits/ 64 <400000000>; opp-level = <3>; qcom,opp-fuse-level = <1>; }; }; /* etc */ }; --- bod
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index 525ebaa93c85..6bf70af948d7 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -35,8 +35,6 @@ properties: items: - const: xo - operating-points-v2: true - required: - compatible - reg