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 7CFA4C3DA6E for ; Wed, 10 Jan 2024 08:25:46 +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=YpBGGbnidUULYPeHESNoRxKlwu7srb5N7wPPwR5RkjI=; b=awiZHZ/xa9qM4P Sbjbql0U7L9UBt99OGJcqxpwVXCRzuQ+3eY3Lf/aEF+KniNnjgRAS7QI4KV3d79GtkiayUpBqPaYS MdieAHlf3Jx7sdsSax49dui1ofVqdvjRzIfXAJSOEknh6O3m7GyxeQCcUWGZJRmewNON/5N3hZ9Z4 efNB8xjjRTIl0PPJoCQVzn4XNCBjzlLGZuvTQgqZlrk6/Q+gHkRNRX8Dzf5FSc9NDIgIYBVB0CbUr zcI4xU8hwnr19AnVIf3cS3FZSk4uZeY8bFLtaa60gdjYzCZNsXzHtdEabN4rVEMnhnYAxUI+IM4Os JbSKlzs1NPlbMHC1gb3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rNTtk-00Ajqa-1x; Wed, 10 Jan 2024 08:25:16 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rNTth-00AjpW-1J for linux-arm-kernel@lists.infradead.org; Wed, 10 Jan 2024 08:25:15 +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 CBF482F4; Wed, 10 Jan 2024 00:25:50 -0800 (PST) Received: from [10.57.87.179] (unknown [10.57.87.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 38B753F73F; Wed, 10 Jan 2024 00:25:03 -0800 (PST) Message-ID: <94aad654-4f20-4b82-b978-77f1f9376dab@arm.com> Date: Wed, 10 Jan 2024 08:26:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/3] cpufreq: scmi: Register for limit change notifications Content-Language: en-US To: Sibi Sankar Cc: linux-arm-kernel@lists.infradead.org, viresh.kumar@linaro.org, rafael@kernel.org, cristian.marussi@arm.com, sudeep.holla@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, quic_mdtipton@quicinc.com, linux-arm-msm@vger.kernel.org, Morten Rasmussen , Dietmar Eggemann References: <20240108140118.1596-1-quic_sibis@quicinc.com> <20240108140118.1596-4-quic_sibis@quicinc.com> From: Lukasz Luba In-Reply-To: <20240108140118.1596-4-quic_sibis@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240110_002513_515554_C6F62F12 X-CRM114-Status: GOOD ( 20.12 ) 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 Hi Sibi, + Morten and Dietmar on CC On 1/8/24 14:01, Sibi Sankar wrote: > Register for limit change notifications if supported with the help of > perf_notify_support interface and determine the throttled frequency > using the perf_opp_xlate to apply HW pressure. > > Signed-off-by: Sibi Sankar > --- > drivers/cpufreq/scmi-cpufreq.c | 42 +++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c > index 4ee23f4ebf4a..53bc8868455d 100644 > --- a/drivers/cpufreq/scmi-cpufreq.c > +++ b/drivers/cpufreq/scmi-cpufreq.c > @@ -25,9 +25,13 @@ struct scmi_data { > int domain_id; > int nr_opp; > struct device *cpu_dev; > + struct cpufreq_policy *policy; > cpumask_var_t opp_shared_cpus; > + struct notifier_block limit_notify_nb; > }; > > +const struct scmi_handle *handle; > +static struct scmi_device *scmi_dev; > static struct scmi_protocol_handle *ph; > static const struct scmi_perf_proto_ops *perf_ops; > > @@ -144,6 +148,22 @@ scmi_get_cpu_power(struct device *cpu_dev, unsigned long *power, > return 0; > } > > +static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event, void *data) > +{ > + unsigned long freq_hz; > + struct scmi_perf_limits_report *limit_notify = data; > + struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb); > + struct cpufreq_policy *policy = priv->policy; > + > + if (perf_ops->perf_opp_xlate(ph, priv->domain_id, limit_notify->range_max, &freq_hz)) > + return NOTIFY_OK; > + > + /* Update HW pressure (the boost frequencies are accepted) */ > + arch_update_hw_pressure(policy->related_cpus, (freq_hz / HZ_PER_KHZ)); This is wrong. The whole idea of the new HW pressure was that I wanted to get rid of the 'signal smoothing' mechanism in order to get instantaneous value from FW to task scheduler. Vincent created 2 interfaces in that new HW pressure: 1. cpufreq_update_pressure(policy) - raw variable 2. arch_update_hw_pressure(policy->related_cpus, (freq_hz / HZ_PER_KHZ)) - smoothing PELT mechanism, good for raw IRQ in drivers In our SCMI cpufreq driver we need the 1st one: cpufreq_update_pressure(policy) The FW will do the 'signal smoothing or filtering' and won't flood the kernel with hundreds of notifications. So, please change that bit and add me, Morten and Dietmar on CC. I would like to review it. Regards, Lukasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel