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 E7F6DC48BF6 for ; Thu, 29 Feb 2024 11:29:07 +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=HkHZw1VsJHvHx5ifKTobvVqLWT1CMnoiir6+TfzUyWo=; b=4oOlmhX6xPRb8c 9MvnL2fLSCm3k2nGXtPuTQRZzA8M9gJbzWHCGEd5LF4KqiKTJ1yqzbKQ+PXAuxujiiiPebFQwS/xm kLDuNa4Vpw2BpIBJw50MvMy0keu0KRaod0GPMu7dI/+Gf0ACer3g1gJfdh08lE2SdZSc4IY7yaXDj wtVZKRp8MKW+xxeJ650MEgOLLCfcedX5P9gVErxellYcv+7hWUZTuGfuSJvI1w/0y3yeMs/udWBmL 67YSECkyuxvog7MyfmRmh4II1qa2xvBQb7T0xwXuv0nr+MUbF4jXbYAxB6Di+8x5wLnH0m3Yc+Cbd 7eutwOI2ctgo8g6E/OnA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfeap-0000000DLbN-0qkc; Thu, 29 Feb 2024 11:28:51 +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 1rfeal-0000000DLaI-42Iv for linux-arm-kernel@lists.infradead.org; Thu, 29 Feb 2024 11:28:49 +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 5DD9E1FB; Thu, 29 Feb 2024 03:29:23 -0800 (PST) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D7DAF3F762; Thu, 29 Feb 2024 03:28:42 -0800 (PST) Date: Thu, 29 Feb 2024 11:28:40 +0000 From: Cristian Marussi To: Lukasz Luba Cc: Sibi Sankar , sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, pierre.gondois@arm.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, viresh.kumar@linaro.org, rafael@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, quic_mdtipton@quicinc.com, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH V3 2/2] cpufreq: scmi: Register for limit change notifications Message-ID: References: <20240227181632.659133-1-quic_sibis@quicinc.com> <20240227181632.659133-3-quic_sibis@quicinc.com> <2608b2d8-f3b0-b4f5-f8e4-1f2242043ded@quicinc.com> <64c6a1bc-92f2-4f44-ab10-cbd2473746f3@arm.com> <18c249b2-ce8c-435b-8d65-a1770a1f294e@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18c249b2-ce8c-435b-8d65-a1770a1f294e@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240229_032848_179739_C31A484D X-CRM114-Status: GOOD ( 30.37 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 29, 2024 at 10:22:39AM +0000, Lukasz Luba wrote: > = > = > On 2/29/24 09:59, Lukasz Luba wrote: > > = > > = > > On 2/28/24 17:00, Sibi Sankar wrote: > > > = > > > = > > > On 2/28/24 18:54, Lukasz Luba wrote: > > > > = > > > > = > > > > On 2/27/24 18:16, Sibi Sankar wrote: > > > > > Register for limit change notifications if supported and use > > > > > the throttled > > > > > frequency from the notification to apply HW pressure. > > > = > > > Lukasz, > > > = > > > Thanks for taking time to review the series! > > > = > > > > > = > > > > > Signed-off-by: Sibi Sankar > > > > > --- > > > > > = > > > > > v3: > > > > > * Sanitize range_max received from the notifier. [Pierre] > > > > > * Update commit message. > > > > > = > > > > > =A0 drivers/cpufreq/scmi-cpufreq.c | 29 +++++++++++++++++++++++++= +++- > > > > > =A0 1 file changed, 28 insertions(+), 1 deletion(-) > > > > > = > > > > > diff --git a/drivers/cpufreq/scmi-cpufreq.c > > > > > b/drivers/cpufreq/scmi-cpufreq.c > > > > > index 76a0ddbd9d24..78b87b72962d 100644 > > > > > --- a/drivers/cpufreq/scmi-cpufreq.c > > > > > +++ b/drivers/cpufreq/scmi-cpufreq.c > > > > > @@ -25,9 +25,13 @@ struct scmi_data { > > > > > =A0=A0=A0=A0=A0 int domain_id; > > > > > =A0=A0=A0=A0=A0 int nr_opp; > > > > > =A0=A0=A0=A0=A0 struct device *cpu_dev; > > > > > +=A0=A0=A0 struct cpufreq_policy *policy; > > > > > =A0=A0=A0=A0=A0 cpumask_var_t opp_shared_cpus; > > > > > +=A0=A0=A0 struct notifier_block limit_notify_nb; > > > > > =A0 }; > > > > > +const struct scmi_handle *handle; > > = > > I've missed this bit here. > = > So for this change we actually have to ask Cristian or Sudeep > because I'm not sure if we have only one 'handle' instance > for all cpufreq devices. > = > If we have different 'handle' we cannot move it to the > global single pointer. > = > Sudeep, Cristian what do you think? I was just replying noticing this :D .... since SCMI drivers can be probed multiple times IF you defined multiple scmi top nodes in your DT containing the same protocol nodes, they receive a distinct sdev/handle/ph for each probe...so any attempt to globalize these wont work...BUT... ...this is a bit of a weird setup BUT it is not against the spec and it can be used to parallelize more the SCMI accesses to disjont set of resources within the same protocol (a long story here...) AND this type of setup is something that it is already used by some other colleagues of Sibi working on a different line of products (AFAIK)... So, for these reasons, usually, all the other SCMI drivers have per-instance non-global references to handle/sdev/ph.... ...having said that, thought, looking at the structure of CPUFReq drivers, I am not sure that they can stand such a similar setup where multiple instances of this same driver are probed .... indeed the existent *ph refs above is already global....so it wont alr= eady work anyway in case of multiple instances now... ...and if I look at how CPUFreq expects the signature of scmi_cpufreq_get_r= ate() to be annd how it is implemented now using the global *ph reference, it is clearly already not working cleanly on a multi-instance setup... ...now...I can imagine how to (maybe) fix the above removing the globals and fixing this, BUT the question, more generally, is CPUFreq supposed to work = at all in this multi-probed mode of operation ? Does it even make sense to be able to support this in CPUFREQ ? (as an example in cpufreq,c there is static global cpufreq_driver pointing to the arch-specific configured driver BUT that also holds some .driver_data AND that cleraly wont be instance specific if you probe multiple times and register with CPUFreq multiple times...) More questions than answers here :D Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel