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=-11.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 26740C4363A for ; Thu, 29 Oct 2020 13:35:12 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A42F52076E for ; Thu, 29 Oct 2020 13:35:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PPCEmHRY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A42F52076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FMaxiPwANUrlRaadiGKO4WAAtRCfOWoPU7W+aH9FOP8=; b=PPCEmHRY+FoC/QXyWv8ee0SDF 4CFq4swodWkoEB6csdVqMMzE6iaU3t0BK8BftngoBiFwaJWKYJDZ9+5D4xoDddsTUFrDdCohwmLcm XS0i5rqkP0842cRuZ9iifMMM1MsXI/xzSqSyiNS8DyOqTx2eW7WWUXliHANE60xI2X4jEgL3+6uiu 3dr+Yn5wikgxW6iv8gZhnlOpxsZ6zt/gCeBUqmcc0H6DL9M43n1nDnU/zR8hGNyAoy2SBrynsTEHh V84yQ/mqL5H+zhGhz1h3Sap7vsixRhSFcuXuUtaKyOWhrlfH0QN2CyRuqpTbfsWRItK7PLxZu+KSh NswJn+vvA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY83t-0005z2-Lc; Thu, 29 Oct 2020 13:33:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY83q-0005y4-BW for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 13:33:51 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BDEE9139F; Thu, 29 Oct 2020 06:33:47 -0700 (PDT) Received: from [10.57.13.20] (unknown [10.57.13.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0A0F23F719; Thu, 29 Oct 2020 06:33:44 -0700 (PDT) Subject: Re: [PATCH 1/4] dt-bindings: opp: Introduce opp-sustainable bindings To: Nishanth Menon References: <20201028140847.1018-1-lukasz.luba@arm.com> <20201028140847.1018-2-lukasz.luba@arm.com> <20201028214713.zttk47qtua5jhieo@pureness> <5b3a99a8-6972-5c60-6cc5-00ec84387b97@arm.com> <20201029125932.fvhaj6fsgt3qvmoc@gloomily> From: Lukasz Luba Message-ID: <792cce7c-a316-fee4-fbf6-3cfc688b7088@arm.com> Date: Thu, 29 Oct 2020 13:33:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20201029125932.fvhaj6fsgt3qvmoc@gloomily> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201029_093350_544356_AAC4BCC7 X-CRM114-Status: GOOD ( 29.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, daniel.lezcano@linaro.org, linux-pm@vger.kernel.org, sboyd@kernel.org, vireshk@kernel.org, rafael@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, sudeep.holla@arm.com, Dietmar.Eggemann@arm.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/29/20 12:59 PM, Nishanth Menon wrote: > On 10:04-20201029, Lukasz Luba wrote: >> >> >> On 10/28/20 9:47 PM, Nishanth Menon wrote: >>> On 14:08-20201028, Lukasz Luba wrote: >>>> Add opp-sustainable as an additional property in the OPP node to describe >>>> the sustainable performance level of the device. This will help to >>>> estimate the sustainable performance of the whole system. >>>> >>>> Signed-off-by: Lukasz Luba >>>> --- >>>> Documentation/devicetree/bindings/opp/opp.txt | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt >>>> index 9847dfeeffcb..cd01028de305 100644 >>>> --- a/Documentation/devicetree/bindings/opp/opp.txt >>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt >>>> @@ -154,6 +154,10 @@ Optional properties: >>>> - opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs >>>> in the table have this, the OPP with highest opp-hz will be used. >>>> +- opp-sustainable: Marks the OPP as sustainable. This property can be used for >>>> + estimating sustainable performance of the whole system. If multiple OPPs in >>>> + the table have this, the OPP with highest opp-hz will be used. >>> >>> >>> By "sustainable", do you mean sustainable across Process, Voltage and >>> Temperature corners upto the max rated operational Power-ON hours >>> without IDLE state being achieved on the processor? >> >> Yes, in case of CPU: running 100% without idle at that particular OPP. >> Running above that OPP would lead to cross control temperature. > > We need to tighten the definitions a lot more here and add that to the > binding. What we are stating, if I am not misunderstanding is an OPP > that is guaranteed by SoC vendor that across Process Voltage and > Temperature corners - aka across the entire production spectrum > for the part number, *all* devices will operate at this OPP for the > mandated power-on-hours rating without hitting IDLE. > > Example: So -40C to 125C, across the process (hot/cold/nominal), 100s of > thousands/millions of units can operate upto 125,0000 power-on-hours > while running a tight deadloop OR maybe high processing function or even > cpuburn[1]? I think I know what you mean. But this would lead to redefining a lot more that just this optional field. This wide range -40C to 125C is for automotive chips, then what about opp-suspend, when the device cannot even reach that OPP under some stress test e.g. outside temp ~100-110C... Or opp-turbo, shell all the OPPs have multidimensional table to reflect the temperature dependency for all affected optional fields? > > > Can you give me one SoC vendor and part that guarantees this? I am > wondering if this is all theoretical... There are tons of parameters > that come into play for "reliability" "sustainability" etc. Those are > tricky terminology that typically makes legal folks pretty happy to > debate for decades.. Yes, but the outside temperature is probably most important for this use case. > > just my 2 cents. >> >>> >>> OR do you mean to leave it up to interpretation? >> >> I can tell how I would use them. There is thermal governor IPA, which >> needs sustainable power either form DT or uses internal algorithm to >> estimate it based on lowest allowed freq OPPs. Then it estimated >> internal coefficients based on that value, which is not optimal >> for lowest OPPs. When some higher OPP could be marked as sustainable, >> it would lead to better estimation and better power budget split. > > Seeing your series, I got an idea about how you plan on using it, I > just think we need to be more precise in our definition.. Thank you for having a look on that and understanding the motivation behind this series. How about adding a description that this sustainable OPP is considered for normal room temp (20-25C)? BTW, in the Arm SCMI spec definition of that value (used in patch 4/4), there is no specific temperature for it, just: 'This is the maximum performance level that the platform can sustain under normal conditions. In exceptional circumstances, such as thermal runaway, the platform might not be be able to guarantee this level.' I can put this whole description into the DT binding, if you like. > > [1] https://patrickmn.com/projects/cpuburn/ > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel