Message ID | 20230121000146.7809-2-ansuelsmth@gmail.com |
---|---|
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 s9csp493331wrn; Fri, 20 Jan 2023 16:09:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXvROH6k1Gnqun4wIUezHltp4XNWWkjPhTpGojft8SCiM18VhKMreW39KxoWInp6ZVYVBK6h X-Received: by 2002:a17:906:3783:b0:86f:e116:295 with SMTP id n3-20020a170906378300b0086fe1160295mr21278941ejc.4.1674259772703; Fri, 20 Jan 2023 16:09:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674259772; cv=none; d=google.com; s=arc-20160816; b=Ya5WIJz38tFA+SIcIHr1Y8oLcoWINn51DMM6kQFgrEed8c5OURwsCkecdJkjfBg/XA ijA7d4x7mQQpO1dMnDdxAUtWhV+OZ0pA8PnM07YKJHw0Nlu2IqTCSeEq61vgA9enIjL5 hufYpicxkbGcVxr8DmwghD4T6K4dZx395EMEjB5WnXOLEViz1nMvJQWt+GjtQ1zM1KU5 Bjrvi0Qb/g3PriCeIyOTAzWadapO2it9SRp5Uyqk0QGIdBg5wOkr8a1+2Ee52V7xgwsn NMW1QCJhTPgMg1J0WWwlAgr3B7yngvEOJ5WUClWiANAqYxEXJ4KimA1sWdZnb7qCyxQL CzSw== 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=zd8X1w31p03LQ0JCvCdaSsk+BBXGwn/BPzQzqQpcm5U=; b=TiTuJW8K6+n6RFiqfcFnprI1pHLRuJVN8sZwDUKJ7owvGXVncrPxQtNsXiNlv6tD9z IWiKovqPypQQZCixKXsB3pUAOwm4A4wunQ7Pw5nE/+dbDkyWNU92J67xbdwNv2bNkQAv B9X+cpIBN4QJJPBl1KfxVO1ZZOIMisaAgCtcmcE++ys+VBgyMOZVy/ztt89ggYD5NvNG 9bwDz+7SUObWXfxDgxPQrngB2kAHcU4VfFZ3QLJj46WuCeopIkh6VbxrAKt5IM+733eN 3/iawdetMxSaqUxUwiel/tiOpfaup3MmRmIwDjIL9M4Sg3R/aJIDp3MlZkQ2EqJoUTYh Upuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="M6mW/VOy"; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hp15-20020a1709073e0f00b008722ef50e4fsi99849ejc.140.2023.01.20.16.09.09; Fri, 20 Jan 2023 16:09:32 -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=@gmail.com header.s=20210112 header.b="M6mW/VOy"; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229897AbjAUAB7 (ORCPT <rfc822;forouhar.linux@gmail.com> + 99 others); Fri, 20 Jan 2023 19:01:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbjAUAB4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Jan 2023 19:01:56 -0500 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDD6E8B745; Fri, 20 Jan 2023 16:01:55 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id l8so5218199wms.3; Fri, 20 Jan 2023 16:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=zd8X1w31p03LQ0JCvCdaSsk+BBXGwn/BPzQzqQpcm5U=; b=M6mW/VOyceIQU6kCUiqbPhsj390voQEygv7Xj7G/EX8aHytisKgnuyyHVCcMAEhl2c qvFRTzkHmqwxGaUbuggPsI2qm985n8Mm+y2XeAlof1TyLCDIWTYJFxdvD+QhVV+HfiEz Xb2emrjNNYupzLmYVcp4zOU/v6Jipdi20YSqkfu/P6IOQc/eDL6ecGiWabGMRuI6Nx6g DZWLwR76BATF8xH5vFmiqgm11Jd/VCRt+HIiJWo/6drEroHVQ8eGoN2P6jIMu4qeQhde 3zNZ9Vh1ukdMJ8F1tDsXj4A3GK2Lljn5bZ7GAdDZo0J31UvON2W28p+p7eYjOEfOdUek c4Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=zd8X1w31p03LQ0JCvCdaSsk+BBXGwn/BPzQzqQpcm5U=; b=Kw0jhchT7cC2GzjBeYRtc06UQvnZqI8ZNtHvMfawXcPr0fpW4zjyhu2YWyXQHB+hZP X3ukiFyjB0NHae9eudfPEa589g94I8ooat0KLc7J7nWFCs11GWQL4Hq1BHzJ8I8UHY1V x6Ozz11BK6HNaZelmARer1mN9yi5uHPrnJurZCNzKTSF6zNfchuMFdjN+XIjQlfcHmot OZRdYgBT9kS1HEvtsB46FSOO2x3SijxSfWtTLgZgA/CDtPj1XhILOERQn1O/M++ZSuCL bLLzpTxzLPjhhYTG7/eK72EVK8EclJK2EYh3uX7296/xs2Sgnldgmnkf51m95jnIar1R 0Gew== X-Gm-Message-State: AFqh2kpib5I2oXFz6gE+n1s7lelXIG2CPtjELIBTkGt2zuNj8a+m/W9G nfNzHe/W+9+0UVavh6r1Yt0D4NkIZ9E= X-Received: by 2002:a05:600c:4a27:b0:3da:fae5:7e2f with SMTP id c39-20020a05600c4a2700b003dafae57e2fmr16019245wmp.3.1674259314228; Fri, 20 Jan 2023 16:01:54 -0800 (PST) Received: from localhost.localdomain (93-34-92-88.ip49.fastwebnet.it. [93.34.92.88]) by smtp.googlemail.com with ESMTPSA id h11-20020a05600c314b00b003db2e3f2c7csm5284292wmo.0.2023.01.20.16.01.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jan 2023 16:01:53 -0800 (PST) From: Christian Marangi <ansuelsmth@gmail.com> To: Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Ilia Lin <ilia.lin@kernel.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Viresh Kumar <viresh.kumar@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Nishanth Menon <nm@ti.com>, Stephen Boyd <sboyd@kernel.org>, Yassine Oudjana <y.oudjana@protonmail.com>, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Christian Marangi <ansuelsmth@gmail.com> Subject: [PATCH 2/3] dt-bindings: opp: opp-v2-kryo-cpu: add opp-microvolt nvmem based Date: Sat, 21 Jan 2023 01:01:45 +0100 Message-Id: <20230121000146.7809-2-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230121000146.7809-1-ansuelsmth@gmail.com> References: <20230121000146.7809-1-ansuelsmth@gmail.com> 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,FREEMAIL_FROM, 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?1755588615531769058?= X-GMAIL-MSGID: =?utf-8?q?1755588615531769058?= |
Series |
[1/3] dt-bindings: cpufreq: qcom-cpufreq-nvmem: make cpr bindings optional
|
|
Commit Message
Christian Marangi
Jan. 21, 2023, 12:01 a.m. UTC
The operating-points-v2-kryo-cpu driver supports defining multiple
opp-microvolt based on the blown efuses in the soc. It consist of 3
values that are parsed: speedbin, psv and version. They are all
appended to the opp-microvolt name and selected by the nvmem driver and
loaded dynamically at runtime.
Example:
opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>;
opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>;
opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>;
opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>;
Add support for this and reject these special binding if we don't have a
nvmem-cell to read data from.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
On 21/01/2023 01:01, Christian Marangi wrote: > The operating-points-v2-kryo-cpu driver supports defining multiple > opp-microvolt based on the blown efuses in the soc. It consist of 3 > values that are parsed: speedbin, psv and version. They are all > appended to the opp-microvolt name and selected by the nvmem driver and > loaded dynamically at runtime. > > Example: > > opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; > opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; > opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; > opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; > > Add support for this and reject these special binding if we don't have a > nvmem-cell to read data from. > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > --- > .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > index b4947b326773..cea932339faf 100644 > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > @@ -61,6 +61,17 @@ patternProperties: > > required-opps: true > > + patternProperties: > + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': This does not end with correct unit suffix. Should be opp-speed-.....-microvolt > + description: | > + Assign a microvolt value to the opp hz based on the efuses value from > + speedbin, pvs and vers Where is the DTS change? Best regards, Krzysztof
On Sun, Jan 22, 2023 at 03:00:22PM +0100, Krzysztof Kozlowski wrote: > On 21/01/2023 01:01, Christian Marangi wrote: > > The operating-points-v2-kryo-cpu driver supports defining multiple > > opp-microvolt based on the blown efuses in the soc. It consist of 3 > > values that are parsed: speedbin, psv and version. They are all > > appended to the opp-microvolt name and selected by the nvmem driver and > > loaded dynamically at runtime. > > > > Example: > > > > opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; > > opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; > > opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; > > opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; > > > > Add support for this and reject these special binding if we don't have a > > nvmem-cell to read data from. > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > > --- > > .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > index b4947b326773..cea932339faf 100644 > > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > > @@ -61,6 +61,17 @@ patternProperties: > > > > required-opps: true > > > > + patternProperties: > > + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': > > This does not end with correct unit suffix. Should be > opp-speed-.....-microvolt > I think I didn't understand this? From opp-v2-base and from what we are using downstream, the named opp-micrvolt works correctly. (speed[0-9]-pvs[0-9]-v[0-9] is the entire name of the named opp-microvolt- binding) This is the reference I always used for the pattern. [1] Here the pattern used by the driver. [2] [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/opp-v2-base.yaml#L209 [2] https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/qcom-cpufreq-nvmem.c#L238 > > + description: | > > + Assign a microvolt value to the opp hz based on the efuses value from > > + speedbin, pvs and vers > > Where is the DTS change? You mean an additional example that use this additional binding? This may be difficult to add since the current example in this schema is a root one and I can't put multiple root example. Is it acceptable to add a dummy opp table with some comments explaining the dummy node is not supported in the current compatible? (apq8096) > > Best regards, > Krzysztof >
On 22/01/2023 15:15, Christian Marangi wrote: > On Sun, Jan 22, 2023 at 03:00:22PM +0100, Krzysztof Kozlowski wrote: >> On 21/01/2023 01:01, Christian Marangi wrote: >>> The operating-points-v2-kryo-cpu driver supports defining multiple >>> opp-microvolt based on the blown efuses in the soc. It consist of 3 >>> values that are parsed: speedbin, psv and version. They are all >>> appended to the opp-microvolt name and selected by the nvmem driver and >>> loaded dynamically at runtime. >>> >>> Example: >>> >>> opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; >>> opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; >>> opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; >>> opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; >>> >>> Add support for this and reject these special binding if we don't have a >>> nvmem-cell to read data from. >>> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> >>> --- >>> .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>> index b4947b326773..cea932339faf 100644 >>> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>> @@ -61,6 +61,17 @@ patternProperties: >>> >>> required-opps: true >>> >>> + patternProperties: >>> + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': >> >> This does not end with correct unit suffix. Should be >> opp-speed-.....-microvolt >> > > I think I didn't understand this? > > From opp-v2-base and from what we are using downstream, the named > opp-micrvolt works correctly. > > (speed[0-9]-pvs[0-9]-v[0-9] is the entire name of the named > opp-microvolt- binding) > > This is the reference I always used for the pattern. [1] > Here the pattern used by the driver. [2] > > [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/opp-v2-base.yaml#L209 > [2] https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/qcom-cpufreq-nvmem.c#L238 Are you documenting existing property or adding new? Commit msg suggests you add new property, so what do you reference here? How is it related? > >>> + description: | >>> + Assign a microvolt value to the opp hz based on the efuses value from >>> + speedbin, pvs and vers >> >> Where is the DTS change? > > You mean an additional example that use this additional binding? This > may be difficult to add since the current example in this schema is a > root one and I can't put multiple root example. No, I mean, you DTS using it. We do not want empty (unused) bindings... Best regards, Krzysztof
On Sun, Jan 22, 2023 at 03:17:54PM +0100, Krzysztof Kozlowski wrote: > On 22/01/2023 15:15, Christian Marangi wrote: > > On Sun, Jan 22, 2023 at 03:00:22PM +0100, Krzysztof Kozlowski wrote: > >> On 21/01/2023 01:01, Christian Marangi wrote: > >>> The operating-points-v2-kryo-cpu driver supports defining multiple > >>> opp-microvolt based on the blown efuses in the soc. It consist of 3 > >>> values that are parsed: speedbin, psv and version. They are all > >>> appended to the opp-microvolt name and selected by the nvmem driver and > >>> loaded dynamically at runtime. > >>> > >>> Example: > >>> > >>> opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; > >>> opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; > >>> opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; > >>> opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; > >>> > >>> Add support for this and reject these special binding if we don't have a > >>> nvmem-cell to read data from. > >>> > >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > >>> --- > >>> .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ > >>> 1 file changed, 16 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>> index b4947b326773..cea932339faf 100644 > >>> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>> @@ -61,6 +61,17 @@ patternProperties: > >>> > >>> required-opps: true > >>> > >>> + patternProperties: > >>> + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': > >> > >> This does not end with correct unit suffix. Should be > >> opp-speed-.....-microvolt > >> > > > > I think I didn't understand this? > > > > From opp-v2-base and from what we are using downstream, the named > > opp-micrvolt works correctly. > > > > (speed[0-9]-pvs[0-9]-v[0-9] is the entire name of the named > > opp-microvolt- binding) > > > > This is the reference I always used for the pattern. [1] > > Here the pattern used by the driver. [2] > > > > [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/opp-v2-base.yaml#L209 > > [2] https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/qcom-cpufreq-nvmem.c#L238 > > Are you documenting existing property or adding new? Commit msg suggests > you add new property, so what do you reference here? How is it related? > It should have been added from the start when the schema was submitted but I get what you mean with the other question. > > > >>> + description: | > >>> + Assign a microvolt value to the opp hz based on the efuses value from > >>> + speedbin, pvs and vers > >> > >> Where is the DTS change? > > > > You mean an additional example that use this additional binding? This > > may be difficult to add since the current example in this schema is a > > root one and I can't put multiple root example. > > No, I mean, you DTS using it. We do not want empty (unused) bindings... > Ok, will drop this and make it part of the ipq8064 opp series that will use this binding.
On 22/01/2023 15:21, Christian Marangi wrote: > On Sun, Jan 22, 2023 at 03:17:54PM +0100, Krzysztof Kozlowski wrote: >> On 22/01/2023 15:15, Christian Marangi wrote: >>> On Sun, Jan 22, 2023 at 03:00:22PM +0100, Krzysztof Kozlowski wrote: >>>> On 21/01/2023 01:01, Christian Marangi wrote: >>>>> The operating-points-v2-kryo-cpu driver supports defining multiple >>>>> opp-microvolt based on the blown efuses in the soc. It consist of 3 >>>>> values that are parsed: speedbin, psv and version. They are all >>>>> appended to the opp-microvolt name and selected by the nvmem driver and >>>>> loaded dynamically at runtime. >>>>> >>>>> Example: >>>>> >>>>> opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; >>>>> opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; >>>>> opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; >>>>> opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; >>>>> >>>>> Add support for this and reject these special binding if we don't have a >>>>> nvmem-cell to read data from. >>>>> >>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> >>>>> --- >>>>> .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ >>>>> 1 file changed, 16 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>>>> index b4947b326773..cea932339faf 100644 >>>>> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>>>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml >>>>> @@ -61,6 +61,17 @@ patternProperties: >>>>> >>>>> required-opps: true >>>>> >>>>> + patternProperties: >>>>> + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': >>>> >>>> This does not end with correct unit suffix. Should be >>>> opp-speed-.....-microvolt >>>> >>> >>> I think I didn't understand this? >>> >>> From opp-v2-base and from what we are using downstream, the named >>> opp-micrvolt works correctly. >>> >>> (speed[0-9]-pvs[0-9]-v[0-9] is the entire name of the named >>> opp-microvolt- binding) >>> >>> This is the reference I always used for the pattern. [1] >>> Here the pattern used by the driver. [2] >>> >>> [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/opp-v2-base.yaml#L209 >>> [2] https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/qcom-cpufreq-nvmem.c#L238 >> >> Are you documenting existing property or adding new? Commit msg suggests >> you add new property, so what do you reference here? How is it related? >> > > It should have been added from the start when the schema was submitted > but I get what you mean with the other question. > >>> >>>>> + description: | >>>>> + Assign a microvolt value to the opp hz based on the efuses value from >>>>> + speedbin, pvs and vers >>>> >>>> Where is the DTS change? >>> >>> You mean an additional example that use this additional binding? This >>> may be difficult to add since the current example in this schema is a >>> root one and I can't put multiple root example. >> >> No, I mean, you DTS using it. We do not want empty (unused) bindings... >> > > Ok, will drop this and make it part of the ipq8064 opp series that will use > this binding. You can also link the DTS changes, it's also fine. Best regards, Krzysztof
On Sun, Jan 22, 2023 at 03:31:14PM +0100, Krzysztof Kozlowski wrote: > On 22/01/2023 15:21, Christian Marangi wrote: > > On Sun, Jan 22, 2023 at 03:17:54PM +0100, Krzysztof Kozlowski wrote: > >> On 22/01/2023 15:15, Christian Marangi wrote: > >>> On Sun, Jan 22, 2023 at 03:00:22PM +0100, Krzysztof Kozlowski wrote: > >>>> On 21/01/2023 01:01, Christian Marangi wrote: > >>>>> The operating-points-v2-kryo-cpu driver supports defining multiple > >>>>> opp-microvolt based on the blown efuses in the soc. It consist of 3 > >>>>> values that are parsed: speedbin, psv and version. They are all > >>>>> appended to the opp-microvolt name and selected by the nvmem driver and > >>>>> loaded dynamically at runtime. > >>>>> > >>>>> Example: > >>>>> > >>>>> opp-microvolt-speed0-pvs0-v0 = <1050000 997500 1102500>; > >>>>> opp-microvolt-speed0-pvs1-v0 = <975000 926250 1023750>; > >>>>> opp-microvolt-speed0-pvs2-v0 = <925000 878750 971250>; > >>>>> opp-microvolt-speed0-pvs3-v0 = <850000 807500 892500>; > >>>>> > >>>>> Add support for this and reject these special binding if we don't have a > >>>>> nvmem-cell to read data from. > >>>>> > >>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> > >>>>> --- > >>>>> .../devicetree/bindings/opp/opp-v2-kryo-cpu.yaml | 16 ++++++++++++++++ > >>>>> 1 file changed, 16 insertions(+) > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>>>> index b4947b326773..cea932339faf 100644 > >>>>> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>>>> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml > >>>>> @@ -61,6 +61,17 @@ patternProperties: > >>>>> > >>>>> required-opps: true > >>>>> > >>>>> + patternProperties: > >>>>> + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': > >>>> > >>>> This does not end with correct unit suffix. Should be > >>>> opp-speed-.....-microvolt > >>>> > >>> > >>> I think I didn't understand this? > >>> > >>> From opp-v2-base and from what we are using downstream, the named > >>> opp-micrvolt works correctly. > >>> > >>> (speed[0-9]-pvs[0-9]-v[0-9] is the entire name of the named > >>> opp-microvolt- binding) > >>> > >>> This is the reference I always used for the pattern. [1] > >>> Here the pattern used by the driver. [2] > >>> > >>> [1] https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/opp/opp-v2-base.yaml#L209 > >>> [2] https://elixir.bootlin.com/linux/latest/source/drivers/cpufreq/qcom-cpufreq-nvmem.c#L238 > >> > >> Are you documenting existing property or adding new? Commit msg suggests > >> you add new property, so what do you reference here? How is it related? > >> > > > > It should have been added from the start when the schema was submitted > > but I get what you mean with the other question. > > > >>> > >>>>> + description: | > >>>>> + Assign a microvolt value to the opp hz based on the efuses value from > >>>>> + speedbin, pvs and vers > >>>> > >>>> Where is the DTS change? > >>> > >>> You mean an additional example that use this additional binding? This > >>> may be difficult to add since the current example in this schema is a > >>> root one and I can't put multiple root example. > >> > >> No, I mean, you DTS using it. We do not want empty (unused) bindings... > >> > > > > Ok, will drop this and make it part of the ipq8064 opp series that will use > > this binding. > > You can also link the DTS changes, it's also fine. > There are some required changes to do on the driver so the opp series still have to be submitted so I guess dropping this is the only way currently. But it's not a problem the real important patch in the series is the first one.
diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index b4947b326773..cea932339faf 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -61,6 +61,17 @@ patternProperties: required-opps: true + patternProperties: + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': + description: | + Assign a microvolt value to the opp hz based on the efuses value from + speedbin, pvs and version value read from the provided nvmem cell. + minItems: 1 + maxItems: 8 # Should be enough regulators + items: + minItems: 1 + maxItems: 3 + required: - opp-hz @@ -75,6 +86,11 @@ then: '^opp-?[0-9]+$': required: - opp-supported-hw +else: + patternProperties: + '^opp-?[0-9]+$': + patternProperties: + '^opp-microvolt-speed[0-9]-pvs[0-9]-v[0-9]$': false additionalProperties: false