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 46FDEC48BF6 for ; Mon, 4 Mar 2024 08:16:03 +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=5giJFksjXzkXOkgrbJhYnU4CelyuNCJws8KmOJv/sJw=; b=YtKfcCqwkV3UGB HBbqdFGIAHZpgaKDlDqd9Zf4eMTjcqka82i7Bf2eWoHi0b/xmo9PhDFeWQ3GwIvWpuJFeC3FDBVcB OKAxmbof/u3sY98dFHeNa0fM4wnxDYjo7ezirUQyYgrP8GZkB//Isxbe0ZJFBdeUD/V3EXSzRAma5 zQhl5Y/WU3x2of8CGXktuzpbxKHIlCsKMWv80ehdneFVI2q5hWDGM9bTmtl4eFGuKgxbk61w7HScJ EwOZfkpFNc95lpvrzeyYZ3thOuEm7rEz0waMMx+uiIujF47AfsJ6xXItvFEkkSD7aI1KPxj9wNm1r 283qP15vObBE09kX2J3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rh3U9-000000086GV-20JG; Mon, 04 Mar 2024 08:15:45 +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 1rh3U1-000000086CK-0fVe for linux-arm-kernel@lists.infradead.org; Mon, 04 Mar 2024 08:15:43 +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 AB37B1FB; Mon, 4 Mar 2024 00:16:11 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 750153F762; Mon, 4 Mar 2024 00:15:33 -0800 (PST) Date: Mon, 4 Mar 2024 08:15:31 +0000 From: Cristian Marussi To: Pierre Gondois Cc: linux-kernel@vger.kernel.org, Christian Loehle , Ionela Voinescu , Sudeep Holla , Dietmar Eggemann , "Rafael J. Wysocki" , Viresh Kumar , linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Subject: Re: [PATCH 3/3] cpufreq: scmi: Set transition_delay_us Message-ID: References: <20240222135702.2005635-1-pierre.gondois@arm.com> <20240222135702.2005635-4-pierre.gondois@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240222135702.2005635-4-pierre.gondois@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240304_001537_457299_AE0D17B5 X-CRM114-Status: GOOD ( 25.02 ) 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 Thu, Feb 22, 2024 at 02:57:01PM +0100, Pierre Gondois wrote: > Make use of the newly added callbacks: > - rate_limit_get() > - fast_switch_rate_limit() > to populate policies's `transition_delay_us`, defined as the > 'Preferred average time interval between consecutive > invocations of the driver to set the frequency for this policy.' > > Signed-off-by: Pierre Gondois > --- > drivers/cpufreq/scmi-cpufreq.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > Hi, > diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c > index 4ee23f4ebf4a..0b483bd0d3ca 100644 > --- a/drivers/cpufreq/scmi-cpufreq.c > +++ b/drivers/cpufreq/scmi-cpufreq.c > @@ -144,6 +144,29 @@ scmi_get_cpu_power(struct device *cpu_dev, unsigned long *power, > return 0; > } > > +static int > +scmi_get_rate_limit(u32 domain, bool has_fast_switch) > +{ > + int ret, rate_limit; > + > + if (has_fast_switch) { > + /* > + * Fast channels are used whenever available, > + * so use their rate_limit value if populated. > + */ > + ret = perf_ops->fast_switch_rate_limit(ph, domain, > + &rate_limit); > + if (!ret && rate_limit) > + return rate_limit; > + } > + > + ret = perf_ops->rate_limit_get(ph, domain, &rate_limit); > + if (ret) > + return 0; > + > + return rate_limit; > +} > + > static int scmi_cpufreq_init(struct cpufreq_policy *policy) > { > int ret, nr_opp, domain; > @@ -250,6 +273,9 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) > policy->fast_switch_possible = > perf_ops->fast_switch_possible(ph, domain); > > + policy->transition_delay_us = > + scmi_get_rate_limit(domain, policy->fast_switch_possible); > + > return 0; > As a second thought, I have just realized that now we have 2 ops to get the rate_limit for a domain, one used in case of FCs and another in case of std messaging w/out FCs, BUT given that we always use FCs when available, AND we do not indeed have any way from perf_ops to explicitly request a set/get ops NOT to use FCs when available, does it even make sense to expose such 2 functions ? Do we need such flexibility ? Shouldn't we just expose one single rate_limit perf_ops and let the SCMI core decide what to return depending on the presence or not of the FCs for that domain ? Maybe @Sudeep thinks differently. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel