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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 7B98EC2D0A3 for ; Thu, 29 Oct 2020 09:56:49 +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 06BAE2076D for ; Thu, 29 Oct 2020 09:56:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3CbeoYmA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06BAE2076D 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=SW+LbP/CSjuEBPaluw1cHYDciSl79M5+Iu7uzY7abY8=; b=3CbeoYmAa8YZESayGP7KC7+Gg rovStpRaPyqZjUcKxxR3UpISRwz3WELrZDjwX420ayyz2wjj/onYlqW9nqbuqTl6TiF5ln7KestBg dI2+7MAQJchuVdludTiFRVxrWGefpCdrOU2jQEQqFvJm0iSpL9u3fjN0Miiyk8ZD+3NNFIGpHTYmh 7Y5EnHaB+se+QEgobxqcp7ZerZ/yu86A9OEUysWH8DKBo3nnPjE+9xyAPX4zKncn/a465zQmWFhDX yjHsm38Ny90iw5ne2vqeug1TfZZi6GaBavWOWGdpdpVlKCIu1Bll4LlmMssxOGbIxTm034UdOOyEG azlWwgh5Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kY4fL-0002T3-4s; Thu, 29 Oct 2020 09:56:19 +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 1kY4fI-0002S9-4p for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 09:56:17 +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 3BD84139F; Thu, 29 Oct 2020 02:56:12 -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 3AEB43F66E; Thu, 29 Oct 2020 02:56:08 -0700 (PDT) Subject: Re: [PATCH 0/4] Add sustainable OPP concept To: Viresh Kumar , vincent.guittot@linaro.org References: <20201028140847.1018-1-lukasz.luba@arm.com> <20201029074057.6ugmwyzna52x3oli@vireshk-i7> <20201029075356.rruej6jlerhfa4oy@vireshk-i7> From: Lukasz Luba Message-ID: <228fa1b3-bbd3-6941-fd4b-06581016d839@arm.com> Date: Thu, 29 Oct 2020 09:56:07 +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: <20201029075356.rruej6jlerhfa4oy@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201029_055616_262519_036654E3 X-CRM114-Status: GOOD ( 21.24 ) 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: nm@ti.com, 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 7:53 AM, Viresh Kumar wrote: > On 29-10-20, 13:10, Viresh Kumar wrote: >> On 28-10-20, 14:08, Lukasz Luba wrote: >>> Hi all, >>> >>> This patch set introduces a concept of sustainable OPP, which then can be used >>> by kernel frameworks or governors for estimating system sustainable system >>> state. This kind of estimation is done e.g. in thermal governor Intelligent >>> Power Allocation (IPA), which calculates sustainable power of the whole system >>> and then derives some coefficients for internal algorithm. >>> >>> The patch set introduces a new DT bindings 'opp-sustainable', with parsing >>> code. It also adds a function (in patch 3/4) which allows device drivers to set >>> directly the sustainable OPP. This is helpful when the device drivers populate >>> the OPP table by themself (example in patch 4/4). >>> >> >> Can we please have some more information about this ? What does the >> sustainable OPP mean ? How will platform guys know or learn about this >> ? How we are going to use it finally ? What does it have to do with >> temperature of the SoC or the thermal affects, etc. There were discussions about Energy Model (EM), scale of values (mW or abstract scale) and relation to EAS and IPA. You can find quite long discussion below v2 [1] (there is also v3 send after agreement [2]). We have in thermal DT binding: 'sustainable-power' expressed in mW, which is used by IPA, but it would not support bogoWatts. The sustainable power is used for estimation of internal coefficients (also for power budget), which I am trying to change to work with 'abstract scale' [3][4]. This would allow to estimate sustainable power of the system based on CPUs, GPU opp-sustainable points, where we don't have 'sustainable-power' or devices using bogoWatts. > > And that we need a real user of this first if it is ever going to be > merged. > IPA would be the first user of this in combination with scmi-cpufreq.c, which can feed 'abstract scale' in to EM. Currently IPA takes lowest allowed OPPs into account for this estimation which is not optimal. This marked OPPs would make estimation a lot better. Regards, Lukasz [1] https://lore.kernel.org/lkml/20201002114426.31277-1-lukasz.luba@arm.com/ [2] https://lore.kernel.org/lkml/20201019140601.3047-1-lukasz.luba@arm.com/ [3] https://lore.kernel.org/linux-pm/5f682bbb-b250-49e6-dbb7-aea522a58595@arm.com/ [4] https://lore.kernel.org/lkml/20201009135850.14727-1-lukasz.luba@arm.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel