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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6F84AC6FD1F for ; Wed, 20 Mar 2024 15:02:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=plVM5bsB8EZDPhkknL5jX0Kl4HmD20hp10T/tavg2JQ=; b=2yVrnKtlvwlAQH DtKlYvDQviZObjIEyaVL5a0KreKVwdVU0mQ+4EWH5xHA5p4YMWdrlqLaB0GZpm7JCk0gqFP3zArmZ XwdaxONdGzUXyXplx1uC0Gy9wLPUAQa9rAEZ3jwQ8vRdheUKzy6Os+9QWlung9c6A1u7HE8xGzxbi wjenAP9F7wZtPg1cdVsLQq8WNLBpZG7/7KKt4Hofa8Z3dd9S9SvYAb/0czdh8wHhWT+8UERRpAD76 jElVFuv08tid/cgEpQFFfmss/1Qk70BlbWDaerCSTgqHQkAjWansW4qopLnTbkfU1F0EoH3HeSeZf W8j7j9LMBhK2fZ5tC45Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmxSf-0000000Ha6y-1V6V; Wed, 20 Mar 2024 15:02:37 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rmxSb-0000000Ha6E-3UNO for linux-arm-kernel@lists.infradead.org; Wed, 20 Mar 2024 15:02:35 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 1ECA6CE112F; Wed, 20 Mar 2024 15:02:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2940CC433F1; Wed, 20 Mar 2024 15:02:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710946950; bh=xFMb9nTzM5f7GHI9kIML1UaEuYeBpsEmr2AAulx6QTA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GQEvxGcSs71CdTPbnVAjTm90KV5AD1t/DyVeasJUsZuRHpe4gewe2PNT7tkVc0Uig 4605Y6tjyjoIEv4ZgdkLLqC7jmSpII+mguL6LmhIeNiXCPH0ZeIgHFY+7S/HKC7sf7 tdIFQqdEU7uYtbe0zWirbZJxM7HR5erX2vgPWd9nAmnStC59uDcCKzRt+yQIj4pwDX D9v/VIFTXy20KzFYyzAntlkggsngEMkiEy3wb0rFJmdFywpsZK5W+XNZ0VKXkzTAOL RYHJDbf+Cx/ckZynxCOXYADcdWh4IBzzy9ojMhLFX17XUBkyN1gTsogzONWGTPef/O g0yV6A20oql7w== Date: Wed, 20 Mar 2024 10:02:28 -0500 From: Rob Herring To: Andre Przywara Cc: Yangtao Li , Viresh Kumar , Nishanth Menon , Stephen Boyd , Krzysztof Kozlowski , Conor Dooley , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , "Rafael J . Wysocki" , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Brandon Cheo Fusi , Martin Botka , Martin Botka Subject: Re: [PATCH v2 3/8] dt-bindings: opp: Describe H616 OPPs and opp-supported-hw Message-ID: <20240320150228.GA1705913-robh@kernel.org> References: <20240318011228.2626-1-andre.przywara@arm.com> <20240318011228.2626-4-andre.przywara@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240318011228.2626-4-andre.przywara@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240320_080234_596970_405CB499 X-CRM114-Status: GOOD ( 26.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 18, 2024 at 01:12:23AM +0000, Andre Przywara wrote: > From: Martin Botka > > The Allwinner H616 uses a similar NVMEM based mechanism to determine the > silicon revision, which is required to select the right frequency / > voltage pair for the OPPs. > However it limits the maximum frequency for some speedbins, which > requires to introduce the opp-supported-hw property. > > Add this property to the list of allowed properties, also drop the > requirement for the revision specific opp-microvolt properties, since > they won't be needed if using opp-supported-hw. When using this > property, we also might have multiple OPP nodes per frequency, so relax > the OPP node naming to allow a single letter suffix. > > Also use to opportunity to adjust some wording, and drop a sentence > referring to the Linux driver and the OPP subsystem. > > Shorten the existing example and add another example, showcasing the > opp-supported-hw property. > > Signed-off-by: Martin Botka > Signed-off-by: Andre Przywara > --- > .../allwinner,sun50i-h6-operating-points.yaml | 89 ++++++++++--------- > 1 file changed, 47 insertions(+), 42 deletions(-) > > diff --git a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml > index 51f62c3ae1947..d5439a3f696bc 100644 > --- a/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml > +++ b/Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml > @@ -13,25 +13,25 @@ maintainers: > description: | > For some SoCs, the CPU frequency subset and voltage value of each > OPP varies based on the silicon variant in use. Allwinner Process > - Voltage Scaling Tables defines the voltage and frequency value based > - on the speedbin blown in the efuse combination. The > - sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to > - provide the OPP framework with required information. > + Voltage Scaling Tables define the voltage and frequency values based > + on the speedbin blown in the efuse combination. > > allOf: > - $ref: opp-v2-base.yaml# > > properties: > compatible: > - const: allwinner,sun50i-h6-operating-points > + enum: > + - allwinner,sun50i-h6-operating-points > + - allwinner,sun50i-h616-operating-points > > nvmem-cells: > description: | > A phandle pointing to a nvmem-cells node representing the efuse > - registers that has information about the speedbin that is used > + register that has information about the speedbin that is used > to select the right frequency/voltage value pair. Please refer > - the for nvmem-cells bindings > - Documentation/devicetree/bindings/nvmem/nvmem.txt and also > + to the nvmem-cells bindings in > + Documentation/devicetree/bindings/nvmem/nvmem.yaml and also the > examples below. > > opp-shared: true > @@ -41,21 +41,23 @@ required: > - nvmem-cells > > patternProperties: > - "^opp-[0-9]+$": > + "^opp-[0-9]+(-[a-z])?$": > type: object > > properties: > opp-hz: true > clock-latency-ns: true > + opp-microvolt: true > + opp-supported-hw: > + description: | > + A single 32 bit bitmap value, representing compatible HW, one > + bit per speed bin index. > > patternProperties: > "^opp-microvolt-speed[0-9]$": true > > required: > - opp-hz > - - opp-microvolt-speed0 > - - opp-microvolt-speed1 > - - opp-microvolt-speed2 > > unevaluatedProperties: false > > @@ -77,58 +79,61 @@ examples: > opp-microvolt-speed2 = <800000>; > }; > > - opp-720000000 { > + opp-1080000000 { > clock-latency-ns = <244144>; /* 8 32k periods */ > - opp-hz = /bits/ 64 <720000000>; > + opp-hz = /bits/ 64 <1080000000>; > > - opp-microvolt-speed0 = <880000>; > - opp-microvolt-speed1 = <820000>; > - opp-microvolt-speed2 = <800000>; > + opp-microvolt-speed0 = <1060000>; > + opp-microvolt-speed1 = <880000>; > + opp-microvolt-speed2 = <840000>; > }; > > - opp-816000000 { > + opp-1488000000 { > clock-latency-ns = <244144>; /* 8 32k periods */ > - opp-hz = /bits/ 64 <816000000>; > + opp-hz = /bits/ 64 <1488000000>; > > - opp-microvolt-speed0 = <880000>; > - opp-microvolt-speed1 = <820000>; > - opp-microvolt-speed2 = <800000>; > + opp-microvolt-speed0 = <1160000>; > + opp-microvolt-speed1 = <1000000>; > + opp-microvolt-speed2 = <960000>; > }; > + }; > + > + - | > + opp-table { > + compatible = "allwinner,sun50i-h616-operating-points"; > + nvmem-cells = <&speedbin_efuse>; > + opp-shared; > > - opp-888000000 { > + opp-480000000 { > clock-latency-ns = <244144>; /* 8 32k periods */ > - opp-hz = /bits/ 64 <888000000>; > + opp-hz = /bits/ 64 <480000000>; > > - opp-microvolt-speed0 = <940000>; > - opp-microvolt-speed1 = <820000>; > - opp-microvolt-speed2 = <800000>; > + opp-microvolt = <900000>; > + opp-supported-hw = <0x1f>; > }; > > - opp-1080000000 { > + opp-792000000-l { > clock-latency-ns = <244144>; /* 8 32k periods */ > - opp-hz = /bits/ 64 <1080000000>; > + opp-hz = /bits/ 64 <792000000>; > > - opp-microvolt-speed0 = <1060000>; > - opp-microvolt-speed1 = <880000>; > - opp-microvolt-speed2 = <840000>; > + opp-microvolt = <900000>; > + opp-supported-hw = <0x02>; > }; > > - opp-1320000000 { > + opp-792000000-h { > clock-latency-ns = <244144>; /* 8 32k periods */ > - opp-hz = /bits/ 64 <1320000000>; > + opp-hz = /bits/ 64 <792000000>; > > - opp-microvolt-speed0 = <1160000>; > - opp-microvolt-speed1 = <940000>; > - opp-microvolt-speed2 = <900000>; > + opp-microvolt = <940000>; > + opp-supported-hw = <0x10>; So far, we've avoided multiple entries for a single frequency. I think it would be good to maintain that. Couldn't you just do: opp-supported-hw = <0>, <0x10>, <0x02>; Where the index corresponds to speed0, speed1, speed2. If not, then I don't understand how multiple entries of opp-supported-hw are supposed to work. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel