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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2482CDB474 for ; Tue, 17 Oct 2023 16:24:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232849AbjJQQYN (ORCPT ); Tue, 17 Oct 2023 12:24:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230343AbjJQQYN (ORCPT ); Tue, 17 Oct 2023 12:24:13 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3D64FF0 for ; Tue, 17 Oct 2023 09:24:11 -0700 (PDT) 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 7BBB62F4; Tue, 17 Oct 2023 09:24:51 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AB2883F762; Tue, 17 Oct 2023 09:24:09 -0700 (PDT) Date: Tue, 17 Oct 2023 17:24:07 +0100 From: Sudeep Holla To: Peng Fan Cc: Ulf Hansson , Sudeep Holla , "cristian.marussi@arm.com" , "linux-pm@vger.kernel.org" , Ranjani Vaidyanathan , Glen G Wienecke Subject: Re: Question regarding scmi_perf_domain.c Message-ID: References: <20231010145137.fyxjlsj5qq3elq7l@bogus> <20231011141551.exqxkmt3xsl5fyjh@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Tue, Oct 17, 2023 at 02:35:49PM +0000, Peng Fan wrote: > > Subject: Re: Question regarding scmi_perf_domain.c > > [...] > > What is the point in adding it ? You can always hack and test if you need. > > I might misunderstand, I thought this was a formal solution. Not really, it was a proposal which we are discussing the options here. > > > > > > > > > > Maybe a module parameter or Kconfig debug option could be used to > > > > control this? > > > > > > Greg might not be happy for introducing module parameter, I guess. > > > > > > > True. But I don't see point in adding a Kconfig as it needs to be enabled with > > single (distro) Image. And figured out both module param and Kconfig are not good options. > > > > > > > > > > In this way an updated DTS with that adds a performance domain to a > > > > consumer device node (which already has a power-domain), should > > > > allow the consumer driver to continue to probe successfully. > > > > > > > > Peng, would this resolve your concern? > > > > > > Actually I am not sure. multiple PD is not a technical issue, it is > > > just adding more changes to various device drivers, we have > > > VPU/GPU/DISPLAY/NPU/ HSIO/CAMERA and etc.. so all the drivers need > > > update, which is not welcomed by driver developers :) > > > > Why ? Have you posted the patches ? Any discussions you can point to ? > > I mean NXP internal. > OK at this point, I really don't care then. I was under the assumption that we were talking everything upstream here. Downstream always has the burden of constantly adapting to the upstream changes. This is not a user ABI. I was pushing Ulf assuming something is needed upstream. Sorry Ulf, I wasn't aware of this downstream driver business here, my bad. So, if the genpd has changed the behaviour for multiple agents and has decided not to support this case, then the drivers need to adapt. I don't see a way out by working around in the SCMI driver as it may break some other platforms and we haven't got a way to do it conditionally other than module param which you have raised right concerns. iAll I can say is downstream drivers need to adapt. Sorry I know it is not what you want to hear but it is part and parcel for the downstream code. > > > > > I am still trying to enable multiple PD for saying MMC, and see how it > > > works after adding performance domain and how device dvfs works in > > > such case. > > > > > > > Interesting. So MMC domain is presented as perf domain rather than the > > clock > > + regulator ? Nice to see that abstraction being used. > > MMC IP is inside a block(named mix) which contains several other IPs. > Current scmi sever perf design only exports MIX level perf, no regulator > for now. > Thanks for the details. -- Regards, Sudeep