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 9C664C4345F for ; Wed, 1 May 2024 08:21:50 +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=QP76M+a3SoPcUWimVisDSMx708++5fWQ4Vb99/XHn3E=; b=OMsraL90X6dT1o 4527gr3ms9XZo1G0bLBuZcNZmScjhXCXgnsWLLTnq2UCLzH6hMfi57qWR3XhyDx0kouvvdQCglX1q omEDr5BSfbrSplzFxL8EDpqMHoJiLepcJYb6TIi0LOXAgC7NWeM48P7hadmjqzDS4xx6gTsN6JTDO az2npDCJrxgZbai/eNBGPUl/3jXg9qXJxnwSLeWU5Oi/CFV21B6Zjv6dukr8F2onzjWe3dQH9cf+r TJ+448qh1iimK6J5U/+O4mME1UtmOlsuI1kQWzAxIf03gaFOMDaS9HXzRXmuL5f65+VoEjbtpAFv2 GajrVkMd15CNZVNQR5AQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s25Dc-00000008qMO-45Fh; Wed, 01 May 2024 08:21:36 +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 1s25DZ-00000008qLk-0hfs for linux-arm-kernel@lists.infradead.org; Wed, 01 May 2024 08:21:35 +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 46DF12F4; Wed, 1 May 2024 01:21:56 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3CA3C3F793; Wed, 1 May 2024 01:21:28 -0700 (PDT) Date: Wed, 1 May 2024 09:21:25 +0100 From: Cristian Marussi To: Sibi Sankar Cc: sudeep.holla@arm.com, rafael@kernel.org, viresh.kumar@linaro.org, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, lukasz.luba@arm.com, pierre.gondois@arm.com, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, quic_mdtipton@quicinc.com, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH V4 2/2] cpufreq: scmi: Register for limit change notifications Message-ID: References: <20240328074131.2839871-1-quic_sibis@quicinc.com> <20240328074131.2839871-3-quic_sibis@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240328074131.2839871-3-quic_sibis@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240501_012133_318691_44F7DD43 X-CRM114-Status: GOOD ( 23.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-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, Mar 28, 2024 at 01:11:31PM +0530, Sibi Sankar wrote: > Register for limit change notifications if supported and use the throttled > frequency from the notification to apply HW pressure. > Hi Sibi, a bit late on this, sorry. Just a couple of nitpicks down below. > Signed-off-by: Sibi Sankar > --- > > v4: > * Use a interim variable to show the khz calc. [Lukasz] > * Use driver_data to pass on the handle and scmi_dev instead of using > global variables. Dropped Lukasz's Rb due to adding these minor > changes. > > drivers/cpufreq/scmi-cpufreq.c | 44 ++++++++++++++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > > diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c > index 3b4f6bfb2f4c..d946b7a08258 100644 > --- a/drivers/cpufreq/scmi-cpufreq.c > +++ b/drivers/cpufreq/scmi-cpufreq.c > @@ -21,11 +21,18 @@ > #include > #include > > +struct scmi_cpufreq_driver_data { > + struct scmi_device *sdev; > + const struct scmi_handle *handle; > +}; > + > 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; > }; > > static struct scmi_protocol_handle *ph; > @@ -174,6 +181,22 @@ static struct freq_attr *scmi_cpufreq_hw_attr[] = { > NULL, > }; > > +static int scmi_limit_notify_cb(struct notifier_block *nb, unsigned long event, void *data) > +{ > + struct scmi_data *priv = container_of(nb, struct scmi_data, limit_notify_nb); > + struct scmi_perf_limits_report *limit_notify = data; > + struct cpufreq_policy *policy = priv->policy; > + unsigned int limit_freq_khz; > + > + limit_freq_khz = limit_notify->range_max_freq / HZ_PER_KHZ; > + > + policy->max = clamp(limit_freq_khz, policy->cpuinfo.min_freq, policy->cpuinfo.max_freq); > + > + cpufreq_update_pressure(policy); > + > + return NOTIFY_OK; > +} > + > static int scmi_cpufreq_init(struct cpufreq_policy *policy) > { > int ret, nr_opp, domain; > @@ -181,6 +204,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) > struct device *cpu_dev; > struct scmi_data *priv; > struct cpufreq_frequency_table *freq_table; > + struct scmi_cpufreq_driver_data *data = cpufreq_get_driver_data(); > > cpu_dev = get_cpu_device(policy->cpu); > if (!cpu_dev) { > @@ -294,6 +318,17 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) > } > } > > + priv->limit_notify_nb.notifier_call = scmi_limit_notify_cb; > + ret = data->handle->notify_ops->devm_event_notifier_register(data->sdev, SCMI_PROTOCOL_PERF, > + SCMI_EVENT_PERFORMANCE_LIMITS_CHANGED, > + &domain, > + &priv->limit_notify_nb); > + if (ret) > + dev_warn(cpu_dev, or &data->sdev->dev which refers to this driver ? which is more informational ? no strong opinion just a question... > + "failed to register for limits change notifier for domain %d\n", domain); > + > + priv->policy = policy; > + > return 0; > > out_free_opp: > @@ -366,12 +401,21 @@ static int scmi_cpufreq_probe(struct scmi_device *sdev) > int ret; > struct device *dev = &sdev->dev; > const struct scmi_handle *handle; > + struct scmi_cpufreq_driver_data *data; > > handle = sdev->handle; ^^^ .... > > if (!handle) > return -ENODEV; > > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; > + > + data->sdev = sdev; > + data->handle = handle; ^^^ ... you dont need to pass around handle AND sdev really since you can access the handle from sdev. > + scmi_cpufreq_driver.driver_data = data; This is slightly better, but, as said, does not solve the multi-instance issue... ...the scmi cpufreq driver remains a driver that works only if instantiated (probed) once, given how the CPUFreq core handles cpufreq_driver registration itself... ...just a note about something to work on in the future...NOT a concern for this series. In general, LGTM. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel