From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F40B8C6377A for ; Wed, 21 Jul 2021 11:10:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18A7A60FF3 for ; Wed, 21 Jul 2021 11:10:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238692AbhGUK3T (ORCPT ); Wed, 21 Jul 2021 06:29:19 -0400 Received: from relay05.th.seeweb.it ([5.144.164.166]:39717 "EHLO relay05.th.seeweb.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239981AbhGUKIc (ORCPT ); Wed, 21 Jul 2021 06:08:32 -0400 Received: from IcarusMOD.eternityproject.eu (unknown [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r2.th.seeweb.it (Postfix) with ESMTPSA id 283833F74F; Wed, 21 Jul 2021 12:48:25 +0200 (CEST) Subject: Re: [PATCH v6 8/9] dt-bindings: cpufreq: qcom-hw: Add bindings for 8998 To: Rob Herring Cc: bjorn.andersson@linaro.org, viresh.kumar@linaro.org, agross@kernel.org, rjw@rjwysocki.net, devicetree@vger.kernel.org, amit.kucheria@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org, konrad.dybcio@somainline.org, marijn.suijten@somainline.org, martin.botka@somainline.org, jami.kettunen@somainline.org, paul.bouchara@somainline.org, ~postmarketos/upstreaming@lists.sr.ht, jeffrey.l.hugo@gmail.com References: <20210701105730.322718-1-angelogioacchino.delregno@somainline.org> <20210701105730.322718-9-angelogioacchino.delregno@somainline.org> <20210714213946.GA3568065@robh.at.kernel.org> From: AngeloGioacchino Del Regno Message-ID: <7d012e8c-4570-9d60-32c3-fb271ce636b8@somainline.org> Date: Wed, 21 Jul 2021 12:48:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210714213946.GA3568065@robh.at.kernel.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Il 14/07/21 23:39, Rob Herring ha scritto: > On Thu, Jul 01, 2021 at 12:57:29PM +0200, AngeloGioacchino Del Regno wrote: >> The OSM programming addition has been done under the >> qcom,cpufreq-hw-8998 compatible name: specify the requirement >> of two additional register spaces for this functionality. >> This implementation, with the same compatible, has been >> tested on MSM8998 and SDM630. > > Certainly we should be using the new binding for any new SoCs. > Yes that's totally true, I should've probably added the new bindings directly instead of making it implicit that the 8998 model is valid for the others. Adding more bindings will explicitly clarify that the support is extended to 630/660 so yeah, I agree. >> >> Signed-off-by: AngeloGioacchino Del Regno >> --- >> .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 67 ++++++++++++++----- >> 1 file changed, 52 insertions(+), 15 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> index bc81b6203e27..29b663321a0b 100644 >> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml >> @@ -18,6 +18,10 @@ description: | >> properties: >> compatible: >> oneOf: >> + - description: Non-secure v1 of CPUFREQ HW >> + items: >> + - const: qcom,cpufreq-hw-8998 >> + >> - description: v1 of CPUFREQ HW >> items: >> - const: qcom,cpufreq-hw >> @@ -28,21 +32,9 @@ properties: >> - qcom,sm8250-cpufreq-epss >> - const: qcom,cpufreq-epss >> >> - reg: >> - minItems: 2 >> - maxItems: 3 >> - items: >> - - description: Frequency domain 0 register region >> - - description: Frequency domain 1 register region >> - - description: Frequency domain 2 register region >> + reg: {} >> >> - reg-names: >> - minItems: 2 >> - maxItems: 3 >> - items: >> - - const: freq-domain0 >> - - const: freq-domain1 >> - - const: freq-domain2 >> + reg-names: {} >> >> clocks: >> items: >> @@ -57,10 +49,55 @@ properties: >> '#freq-domain-cells': >> const: 1 >> >> +if: >> + properties: >> + compatible: >> + contains: >> + const: qcom,cpufreq-hw-8998 >> +then: >> + properties: >> + reg: >> + minItems: 2 >> + maxItems: 6 >> + items: >> + - description: Frequency domain 0 register region >> + - description: Operating State Manager domain 0 register region >> + - description: Frequency domain 1 register region >> + - description: Operating State Manager domain 1 register region >> + - description: PLL ACD domain 0 register region (if ACD programming required) >> + - description: PLL ACD domain 1 register region (if ACD programming required) >> + >> + reg-names: >> + minItems: 2 >> + maxItems: 6 >> + items: >> + - const: "osm-domain0" >> + - const: "freq-domain0" >> + - const: "osm-domain1" >> + - const: "freq-domain1" >> + - const: "osm-acd0" >> + - const: "osm-acd1" > > This is different enough and there's not much else to this bindings, so > I think you should do a separate schema doc. > > BTW, Don't need quotes here. > If you think that this would be appropriate, then I guess it's trivial to do that and I will... though, I am 99% sure that these bindings will never get updated, as Qualcomm has shifted to do the programming in TZ and there surely will never be any new SoC requiring this kind of thing. The ones that do require this should be around 6, if my memory isn't failing... >> + >> +else: >> + properties: >> + reg: >> + minItems: 2 >> + maxItems: 3 >> + items: >> + - description: Frequency domain 0 register region >> + - description: Frequency domain 1 register region >> + - description: Frequency domain 2 register region >> + reg-names: >> + minItems: 2 >> + maxItems: 3 >> + items: >> + - const: "freq-domain0" >> + - const: "freq-domain1" >> + - const: "freq-domain2" >> + >> required: >> - compatible >> - reg >> - - reg-names >> - clocks >> - clock-names >> - '#freq-domain-cells' >> -- >> 2.32.0 >> >>