[v10,2/6] dt-bindings: opp: v2-qcom-level: Document CPR3 open/closed loop volt adjustment
Message ID | 20230217-topic-cpr3h-v10-2-67aed8fdfa61@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp827839wrn; Fri, 17 Feb 2023 03:16:10 -0800 (PST) X-Google-Smtp-Source: AK7set941TM7SRi4H5BUmhUmxKwoT5AXOszT/pnahr9UmybVJ3xugqIl7PKHpjWDGwy1GkqPU9ZB X-Received: by 2002:a17:903:1111:b0:19a:9880:1750 with SMTP id n17-20020a170903111100b0019a98801750mr792684plh.53.1676632569811; Fri, 17 Feb 2023 03:16:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676632569; cv=none; d=google.com; s=arc-20160816; b=XTGATb1bosGt79MLHx5AjxWpwuUOG8bUeCHrSt68qqOYKvEybOyDveTxQd2zOb+wwX 9UrfMR20jVFNbuUae/7DQZTpGdbL5fusN0gIDmTMyAzJv+Jka8L9tjemspRL/5LU3Y9V 4YTErQmxm3FAQUiNlD14Qheu/zCHDbL+R4UMPkeWvQdFxf/nExd09h95mnVMfZlvNLY0 QQpiDGOhh7gmFmWJ1J20WecqeiFnKooxhuNlylfmeql+13GIt9sI9AsGSbRxDL7Qh8wf H/UKuEnWk4KOkDsVUs6xNYPrxTOMSxYGZ+j/XT6D0xn94pifEbYAiWVckEJ7uft4AFMY tACA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=JoW4ktb7yfQrVNdteP+d/T//uPLuGe0EFh4utClSrWM=; b=uml5V5a2hwSrrnQgHClDZSv7L70TNzA7B0DBEuRkI/K5d/K/PAVtb0fIeVwKzVOxQw hWDy0Uw3WG+1YhuW/LIpyN6aFRIt3VG9lm3gsx7s/SMXgVXtFo+75iTmQRWZDqMNdhAD 5a8hzNtz7036wcEUe5fXptO4wZtRTUAzxY5kWfl1CQXhFI8bZ5pSpT30+/ct3eWbm3Wk 6/S9ZcMhwZmI8GJTk2pgpqjjEZ3K/qvSCnsMiew+gTN4rpGoBFDbNlQyDIT0PV0uOgMG 0GGqxx4Er7lJLbUDDAV8D6seWdr0BFCaImpl8kn14kDSqxj2XMq7JD+j5hmBB5HoOy4F BBOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XxbXWZ9f; 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 b9-20020a170902d40900b0019a7ef5e99bsi3982880ple.311.2023.02.17.03.15.55; Fri, 17 Feb 2023 03:16:09 -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=XxbXWZ9f; 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 S229950AbjBQLJ3 (ORCPT <rfc822;aimixsaka@gmail.com> + 99 others); Fri, 17 Feb 2023 06:09:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230028AbjBQLJA (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Feb 2023 06:09:00 -0500 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77B8066656 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 03:08:30 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id o3so1207689lfo.3 for <linux-kernel@vger.kernel.org>; Fri, 17 Feb 2023 03:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=JoW4ktb7yfQrVNdteP+d/T//uPLuGe0EFh4utClSrWM=; b=XxbXWZ9faszV4z77drGKZ9RfYtLI6Jv463K74P/SIrZG9W5ySH4389O5cGssLv5OAh MIAdilPPHymeNn8PWuUJAv156JinemijPiD9zlhnNIjehLVP686O093WFAD1vtgaeTwD 1rApIEc3xnYyFzQ69HUryVfmGEssFFDjiIEdX3gMF8OipBGCV3DOactcOvttUlJ6i7Dv z6biLLFoaHBY/Kn/Dt5aAv0LGbc8EeK1csDDwMLD1m/7QK3xntqaErbcaxt8b/dG/BVE ROM7EFwarFMXH2iULJJQ4ht+R1O9RfM386qvcbfFXX7DvdWCrK/B+/zOytbVsBfPA68r MPtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JoW4ktb7yfQrVNdteP+d/T//uPLuGe0EFh4utClSrWM=; b=ZxKNgmmMQnSRI3EVShg5Q+2iOLHNGuzaOuDbrMt4jRgoLwXTPTFGZQBwVq6WLRtUVt g38gSSBmlSbesQZ9FyIGDGvbKhzdITWNs2FJRmV75XaMe8ghPDN/NoQFP1H/gpB6r+dM LN7fDUMDVEwiOwgT3AgZMbFk6DDCyH451mxg1DIxdjYy8nu0gHQHeTef1cMlQ8OkUefk 4q9+9AzK0tFz/GA4VLQvStcZqRqut9e6d0yqUJ+ntqdVVcUlPnXb1eH1Y7S3xsTaLxTP iSZ4/ToCi/Ynx+VH4wT4aJzMTvgAPliCuum8KK4sinJ/wMcB/c8kA7Zt5PKT+9UhxmQ1 4gOg== X-Gm-Message-State: AO0yUKVpeZ1Rv3HX6lHYfOFJDf7g6861lf15h6C7RVL/uorFsew0/YlR Fz2+a5byYvozb7MQ0lwUBvaDZA== X-Received: by 2002:ac2:5453:0:b0:4b4:e4a1:2fc6 with SMTP id d19-20020ac25453000000b004b4e4a12fc6mr191778lfn.68.1676632108762; Fri, 17 Feb 2023 03:08:28 -0800 (PST) Received: from [192.168.1.101] (abxh117.neoplus.adsl.tpnet.pl. [83.9.1.117]) by smtp.gmail.com with ESMTPSA id a12-20020a056512020c00b004b57162edfasm640162lfo.117.2023.02.17.03.08.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Feb 2023 03:08:28 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Fri, 17 Feb 2023 12:08:25 +0100 Subject: [PATCH v10 2/6] dt-bindings: opp: v2-qcom-level: Document CPR3 open/closed loop volt adjustment MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230217-topic-cpr3h-v10-2-67aed8fdfa61@linaro.org> References: <20230217-topic-cpr3h-v10-0-67aed8fdfa61@linaro.org> In-Reply-To: <20230217-topic-cpr3h-v10-0-67aed8fdfa61@linaro.org> To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>, Niklas Cassel <nks@flawful.org>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org> Cc: Robert Marko <robimarko@gmail.com>, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, Konrad Dybcio <konrad.dybcio@linaro.org> X-Mailer: b4 0.12.1 X-Developer-Signature: v=1; a=ed25519-sha256; t=1676632104; l=1379; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=cFLhE91kk6nAFRpw11bXMz02kwYFI7RIwXU7++yrFKw=; b=RJQ0C3ZbWrh50VeKzPj1kBZUKeSDywTiIYAFKtz+vPHz6ZkLEISUpm/siTIu+Ms9G8Y31zQ/TFMm pytESZ62CC2hUlsdVHptVYx61ZSUWcOuPME38gmY+fLx9Q5Wq99G X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= 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=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?1758076673530524738?= X-GMAIL-MSGID: =?utf-8?q?1758076673530524738?= |
Series |
Add support for Core Power Reduction v3, v4 and Hardened
|
|
Commit Message
Konrad Dybcio
Feb. 17, 2023, 11:08 a.m. UTC
CPR3 and newer can be fed per-OPP voltage adjustment values for both
open- and closed-loop paths to make better decisions about settling
on the final voltage offset target. Document these properties.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
.../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Comments
On Fri, Feb 17, 2023 at 12:08:25PM +0100, Konrad Dybcio wrote: > CPR3 and newer can be fed per-OPP voltage adjustment values for both > open- and closed-loop paths to make better decisions about settling > on the final voltage offset target. Document these properties. > > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> > --- > .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml > index a30ef93213c0..93cc88434dfe 100644 > --- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml > +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml > @@ -34,6 +34,20 @@ patternProperties: > minItems: 1 > maxItems: 2 > > + qcom,opp-cloop-vadj: > + description: | > + A value representing the closed-loop voltage adjustment value A value? > + associated with this OPP node. > + $ref: /schemas/types.yaml#/definitions/int32-array > + maxItems: 2 Or 2 values? > + > + qcom,opp-oloop-vadj: > + description: | > + A value representing the open-loop voltage adjustment value > + associated with this OPP node. > + $ref: /schemas/types.yaml#/definitions/int32-array > + maxItems: 2 > + > required: > - opp-level > - qcom,opp-fuse-level > > -- > 2.39.1 >
On 18.02.2023 00:13, Rob Herring wrote: > On Fri, Feb 17, 2023 at 12:08:25PM +0100, Konrad Dybcio wrote: >> CPR3 and newer can be fed per-OPP voltage adjustment values for both >> open- and closed-loop paths to make better decisions about settling >> on the final voltage offset target. Document these properties. >> >> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> --- >> .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >> index a30ef93213c0..93cc88434dfe 100644 >> --- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >> +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >> @@ -34,6 +34,20 @@ patternProperties: >> minItems: 1 >> maxItems: 2 >> >> + qcom,opp-cloop-vadj: >> + description: | >> + A value representing the closed-loop voltage adjustment value > > A value? > >> + associated with this OPP node. >> + $ref: /schemas/types.yaml#/definitions/int32-array >> + maxItems: 2 > > Or 2 values? Right, this description doesn't make any sense if you're just looking at the documentation without looking at the driver.. Generally, each CPR3 instance can have multiple "threads" (each one of which regulates voltage for some on-SoC IP or part of it). The nth entry in the qcom,opp-[co]loop-vadj array corresponds to a voltage offset for the nth thread. If the nth entry in the array is missing, the driver assumes the arr[0] one is "global" to this CPR3 instance at this OPP level and applies it to all threads. ...and looking at it again, this is sorta just bad design, especially if you take into account that there's no known user of CPR3 that employs more than 2 threads. I'll remove that from the driver and make the description clearer. Also, only noticed now.. "qcom,sdm630-cprh" was not documented, so that's to be fixed for the next submission as well! Konrad > >> + >> + qcom,opp-oloop-vadj: >> + description: | >> + A value representing the open-loop voltage adjustment value >> + associated with this OPP node. >> + $ref: /schemas/types.yaml#/definitions/int32-array >> + maxItems: 2 >> + >> required: >> - opp-level >> - qcom,opp-fuse-level >> >> -- >> 2.39.1 >>
Il 18/02/23 01:26, Konrad Dybcio ha scritto: > > > On 18.02.2023 00:13, Rob Herring wrote: >> On Fri, Feb 17, 2023 at 12:08:25PM +0100, Konrad Dybcio wrote: >>> CPR3 and newer can be fed per-OPP voltage adjustment values for both >>> open- and closed-loop paths to make better decisions about settling >>> on the final voltage offset target. Document these properties. >>> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>> --- >>> .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>> index a30ef93213c0..93cc88434dfe 100644 >>> --- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>> @@ -34,6 +34,20 @@ patternProperties: >>> minItems: 1 >>> maxItems: 2 >>> >>> + qcom,opp-cloop-vadj: >>> + description: | >>> + A value representing the closed-loop voltage adjustment value >> >> A value? >> >>> + associated with this OPP node. >>> + $ref: /schemas/types.yaml#/definitions/int32-array >>> + maxItems: 2 >> >> Or 2 values? > Right, this description doesn't make any sense if you're just > looking at the documentation without looking at the driver.. > > Generally, each CPR3 instance can have multiple "threads" > (each one of which regulates voltage for some on-SoC IP or > part of it). The nth entry in the qcom,opp-[co]loop-vadj > array corresponds to a voltage offset for the nth thread. > > If the nth entry in the array is missing, the driver assumes > the arr[0] one is "global" to this CPR3 instance at this OPP > level and applies it to all threads. ...and looking at it > again, this is sorta just bad design, especially if you > take into account that there's no known user of CPR3 that > employs more than 2 threads. > > I'll remove that from the driver and make the description clearer. > description: Represents the closed-loop voltage adjustment associated with this OPP node. P.S.: Drop '|' here and on oloop! This binding is intended to support either single or multiple CPR threads; the driver's behavior is unimportant as bindings describe the hardware, not the driver. Regards, Angelo > > Also, only noticed now.. "qcom,sdm630-cprh" was not documented, > so that's to be fixed for the next submission as well! > > > Konrad >> >>> + >>> + qcom,opp-oloop-vadj: >>> + description: | >>> + A value representing the open-loop voltage adjustment value >>> + associated with this OPP node. >>> + $ref: /schemas/types.yaml#/definitions/int32-array >>> + maxItems: 2 >>> + >>> required: >>> - opp-level >>> - qcom,opp-fuse-level >>> >>> -- >>> 2.39.1 >>>
On 20.02.2023 12:27, AngeloGioacchino Del Regno wrote: > Il 18/02/23 01:26, Konrad Dybcio ha scritto: >> >> >> On 18.02.2023 00:13, Rob Herring wrote: >>> On Fri, Feb 17, 2023 at 12:08:25PM +0100, Konrad Dybcio wrote: >>>> CPR3 and newer can be fed per-OPP voltage adjustment values for both >>>> open- and closed-loop paths to make better decisions about settling >>>> on the final voltage offset target. Document these properties. >>>> >>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> >>>> --- >>>> .../devicetree/bindings/opp/opp-v2-qcom-level.yaml | 14 ++++++++++++++ >>>> 1 file changed, 14 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>>> index a30ef93213c0..93cc88434dfe 100644 >>>> --- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml >>>> @@ -34,6 +34,20 @@ patternProperties: >>>> minItems: 1 >>>> maxItems: 2 >>>> + qcom,opp-cloop-vadj: >>>> + description: | >>>> + A value representing the closed-loop voltage adjustment value >>> >>> A value? >>> >>>> + associated with this OPP node. >>>> + $ref: /schemas/types.yaml#/definitions/int32-array >>>> + maxItems: 2 >>> >>> Or 2 values? >> Right, this description doesn't make any sense if you're just >> looking at the documentation without looking at the driver.. >> >> Generally, each CPR3 instance can have multiple "threads" >> (each one of which regulates voltage for some on-SoC IP or >> part of it). The nth entry in the qcom,opp-[co]loop-vadj >> array corresponds to a voltage offset for the nth thread. >> >> If the nth entry in the array is missing, the driver assumes >> the arr[0] one is "global" to this CPR3 instance at this OPP >> level and applies it to all threads. ...and looking at it >> again, this is sorta just bad design, especially if you >> take into account that there's no known user of CPR3 that >> employs more than 2 threads. >> >> I'll remove that from the driver and make the description clearer. >> > > description: > Represents the closed-loop voltage adjustment associated with > this OPP node. > > P.S.: Drop '|' here and on oloop! > > This binding is intended to support either single or multiple CPR threads; > the driver's behavior is unimportant as bindings describe the hardware, > not the driver. Correct, but specifying just one value regardless of the number of threads is not in the spirit of representing things clearly. These properties do not describe the hardware. They let us pass configuration values that are specific to the SoC hosting the CPR, not to the CPR itself. Konrad > > Regards, > Angelo > >> >> Also, only noticed now.. "qcom,sdm630-cprh" was not documented, >> so that's to be fixed for the next submission as well! >> >> >> Konrad >>> >>>> + >>>> + qcom,opp-oloop-vadj: >>>> + description: | >>>> + A value representing the open-loop voltage adjustment value >>>> + associated with this OPP node. >>>> + $ref: /schemas/types.yaml#/definitions/int32-array >>>> + maxItems: 2 >>>> + >>>> required: >>>> - opp-level >>>> - qcom,opp-fuse-level >>>> >>>> -- >>>> 2.39.1 >>>> > > >
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml index a30ef93213c0..93cc88434dfe 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml @@ -34,6 +34,20 @@ patternProperties: minItems: 1 maxItems: 2 + qcom,opp-cloop-vadj: + description: | + A value representing the closed-loop voltage adjustment value + associated with this OPP node. + $ref: /schemas/types.yaml#/definitions/int32-array + maxItems: 2 + + qcom,opp-oloop-vadj: + description: | + A value representing the open-loop voltage adjustment value + associated with this OPP node. + $ref: /schemas/types.yaml#/definitions/int32-array + maxItems: 2 + required: - opp-level - qcom,opp-fuse-level