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 D4BF9C4363A for ; Fri, 30 Oct 2020 10:57:15 +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 55E1D206B2 for ; Fri, 30 Oct 2020 10:57:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RM3dg0DC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55E1D206B2 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=f+ll28ViM1G0nHxMmBC9EWAYfmpv0rAfOnEXZAEWm8c=; b=RM3dg0DCAEVx2BEzyFoPHJH0F tIDIe3f2Evqi6Gz4t2YfG7iWNMEhqbPkywDANaHHCEb/0oHHN+zrMwKbKyMCXJBMHhdF09UExaIKk jdHc+SiR7U7JTjMqV0VTa8Wy/kajw7cYWC7GitCth4gcrG9gyLYlyaEEIQI6MjaR71YRc5CEbYi/Q jPrtt9eoK4gY1JCHKt+ySxAfKrWJ70Bm5rdCE+XCUNDL4bln7mLDcfijGUQPbLtIV02Bc3pKkSJV9 Y5OXRtzRbXmRs+FjZSOdD/G5VfF4jyDoApCqaVFYj2PtVU7nq/U0wn8y7TNfxYsyWNXK43mO+uRRM MPJRdVwxA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kYS5N-0003L8-3U; Fri, 30 Oct 2020 10:56:45 +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 1kYS5G-0003Ig-AX for linux-arm-kernel@lists.infradead.org; Fri, 30 Oct 2020 10:56:39 +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 62A87139F; Fri, 30 Oct 2020 03:56:35 -0700 (PDT) Received: from [10.57.13.192] (unknown [10.57.13.192]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A0EC3F719; Fri, 30 Oct 2020 03:56:32 -0700 (PDT) Subject: Re: [PATCH 0/4] Add sustainable OPP concept To: Viresh Kumar References: <20201028140847.1018-1-lukasz.luba@arm.com> <20201029074057.6ugmwyzna52x3oli@vireshk-i7> <20201029075356.rruej6jlerhfa4oy@vireshk-i7> <228fa1b3-bbd3-6941-fd4b-06581016d839@arm.com> <20201030082937.xgjmko2ohwhkt6f5@vireshk-i7> <20201030095248.abej6h5wphud2ihb@vireshk-i7> From: Lukasz Luba Message-ID: <757fe3b1-745f-2656-fe21-c7b39f123a25@arm.com> Date: Fri, 30 Oct 2020 10:56:30 +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: <20201030095248.abej6h5wphud2ihb@vireshk-i7> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201030_065638_506097_326C23A3 X-CRM114-Status: GOOD ( 31.47 ) 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, vincent.guittot@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/30/20 9:52 AM, Viresh Kumar wrote: > On 30-10-20, 09:19, Lukasz Luba wrote: >> How about dropping the DT binding, but just adding this new field into >> dev_pm_opp? There will be no DT parsing code, just the get/set >> functions, which will be used in SCMI patch 4/4 and in IPA? >> That would not require to change any DT bindings. > >> I see. Just for your information SCMI supports 'Sustained Performance' >> expressed in kHz. > > Even that doesn't sound great (but then I don't have any background of > why that was added there). The problem is not about how do we get this > data into the kernel (from DT or firmware), but why is it even > required. I really feel that software can find the sustainable OPP by > itself (which can keep changing). IPA tries to do that, even dynamically when e.g. GPU is supper busy in 3D games (~2000W) or almost idle showing 2D home screen. It tries to find highest 'sustainable' frequencies for the devices, at that various workloads and temp. But it needs some coefficients to start, which have big impact on the algorithm. It could slow down IPA a lot, when those coefficients are calculated based on lowest OPPs. > > About moving it into the OPP core, I am open to getting something > added there if it is really useful and if the OPP core is the best > suited place to keep such data. Though I am not sure of that for this > field right now. > > Is it ever going to be used by anyone else apart from IPA ? If not, > what about adding a helper in IPA to set sustainable-freq for a device > ? My backup plan was to add a flag into EM em_perf_state, extend SCMI perf exposing the 'sustained_freq_khz' to scmi-cpufreq, which would set that field after registering EM. IPA depends on EM, so should be OK. > > So only SCMI based platforms will be able to use this stuff ? That's I don't know who would also use it in future. I just presented you current user of this, as you asked. > very limited, isn't it ? I think we should still try to make it better > for everyone by making the software smarter. It has so much data, the > OPPs, the power it will consume (based on microvolt property?), the > heat we produce from that (from thermal framework), etc. Perhaps > building this information continuously at runtime based on when and > how we hit the trip points ? So we know which is the right frequency > where we can refrain from hitting the trip points. IPA works in this way. > > But may be I am asking too much :( > When you asked for user of this, I gave you instantly. This is one is more difficult. I am still not there with IPA tests in LISA. I have some out-of-tree kernel driver for testing, which also need polishing before can be used with LISA. Then proper workloads with results processing. EM for devfreq cooling devices. Then decent 'hot' board running preferably mainline kernel. What you requested is on my list, but it needs more work, which won't be ready over night. Regards, Lukasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel