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 28286C4345F for ; Mon, 22 Apr 2024 13:55:53 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=p64galKnVa1vbu/EsFWZdD6kcP0iuId61eQaIJ14Pw0=; b=G8Uyk6lvfTxLIe rU+RFWmjaP7Gutk/EOqkD8hkCdZq8fyQcxZtUOufg8tuQPydsL4rJDlpxgMM4LPXQiX1gNZbD9Pdw 6aSC82UaEQFOI5nQ0YmfF8wTQ2IpymOCQlM6OwPlsJkayvo5C6UdqibMj++q6MBkvCv5flUvk2RRJ PO6Xo6yXYy2M5LZXin422k8fckp1kyu64fjnX8Tw2L5O9/pGSAVx15t8RyQ6a5q6PNizOdJZbRfXI IdwXCekrfrqaGrr7WVbz005MgBCguq3+MP/aGfM8QzKHX9ZL1oUast3wZa4TX22iTjw3oQoLjmxhO eERXw7b3fwuhYYWLDZSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryu8z-0000000Dq80-2y3F; Mon, 22 Apr 2024 13:55:41 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ryu8w-0000000Dq6w-1bkO for linux-arm-kernel@lists.infradead.org; Mon, 22 Apr 2024 13:55:40 +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 98FE0339; Mon, 22 Apr 2024 06:56:04 -0700 (PDT) Received: from [10.57.75.149] (unknown [10.57.75.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B0FCC3F73F; Mon, 22 Apr 2024 06:55:34 -0700 (PDT) Message-ID: <2aba29c3-2519-4709-9f83-4a74cbfea263@arm.com> Date: Mon, 22 Apr 2024 14:55:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] cpufreq: scmi: Update Energy Model with allowed performance limits To: Dietmar Eggemann Cc: linux-arm-kernel@lists.infradead.org, sudeep.holla@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, cristian.marussi@arm.com, linux-samsung-soc@vger.kernel.org, rafael@kernel.org, viresh.kumar@linaro.org, quic_sibis@quicinc.com References: <20240403162315.1458337-1-lukasz.luba@arm.com> <20240403162315.1458337-3-lukasz.luba@arm.com> <780caf10-964c-4a5b-8333-b448e9cbab4b@arm.com> Content-Language: en-US From: Lukasz Luba In-Reply-To: <780caf10-964c-4a5b-8333-b448e9cbab4b@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240422_065538_681197_BB36F9D6 X-CRM114-Status: GOOD ( 19.56 ) 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-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 4/22/24 14:11, Dietmar Eggemann wrote: > On 03/04/2024 18:23, Lukasz Luba wrote: >> The Energy Model (EM) supports performance limits updates. Use the SCMI >> notifications to get information from FW about allowed frequency scope for >> the CPUs. > > I'm slightly confused here. IMHO this doesn't seem to be related to the > "HW dependency between 'little CPUs & L3 $ in DSU' or similar" usecase. > > I assumed that this usecase is rather handled via an additional > out-of-tree driver, potentially the same which updates the EM because of > temperature change (em_dev_compute_costs(), em_dev_update_perf_domain()) > or chip binning (em_dev_update_chip_binning()). This patch allows to handle relatively simple and straight forward use case for updating the perf limits in the EM. The one that you mention, which would probably always live out-of-tree, is more complex and focused on leakage estimation in different conditions. I see those two drivers separate. We have the DSU+Littles dependency always, because it's HW dependency, while the leakage issue can happen in some scenarios like gaming and needs more dedicated driver to handle it (or rely on FW, but that's another story, orthogonal as well) and more information to do it properly. > > What about other CPUFreq drivers registering an EM via > em_dev_register_perf_domain() or 'cpufreq_register_em_with_opp() -> > dev_pm_opp_of_register_em()'? Or is this 'limit notification' an SCMI FW > only thing? Other platforms which use different drivers for CPUfreq will have to develop their own code. Although, when we merge this upstream, they could follow this pattern as a reference design. In our SCMI cpufreq and our SCP firmware we have this situation: 1. Sending CPUfreq request from Big CPU to SCP e.g. via fast-channel & it's done from sched-util w/o sugov kthread & it has to be super fast, we don't check any other dependency CPU for Littles or something like that. 2. The SCP firmware receives the frequency request for Big CPU & it checks internal dependencies for other components e.g. L3 cache min speed (DSU+Littles domian frequency) 3. The SCP changes the Big CPU frequency & changes the DSU+Littles frequency as the depended device 4. The SCP sends updated performance limits for the depended DSU+Littles domian to the SCMI cpufreq kernel driver, for proper Littles domain cpufreq device 5. SCMI cpufreq kernel driver gets the SCP notification about updated perf limits & translates the perf limits min value as the lowest currently available frequency for the Littles 6. The SCMI cpufreq driver updates the EM perf limits for Littles as the currently minimum available frequency. This allows to properly simulate the energy impact when the EAS tries to put a task on that domain, even when that PD's util signals might show lower frequency potentially being used. That's why I see this as part of the CPUfreq driver feature. The leakage driver might be better suited for the thermal framework, since there is more information available there. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel