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 37502CD6E50 for ; Wed, 11 Oct 2023 09:18:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345857AbjJKJSU (ORCPT ); Wed, 11 Oct 2023 05:18:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345869AbjJKJST (ORCPT ); Wed, 11 Oct 2023 05:18:19 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D9392A7 for ; Wed, 11 Oct 2023 02:18:17 -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 85902106F; Wed, 11 Oct 2023 02:18:57 -0700 (PDT) Received: from bogus (unknown [10.57.93.106]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B9FA33F762; Wed, 11 Oct 2023 02:18:15 -0700 (PDT) Date: Wed, 11 Oct 2023 10:16:44 +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: <20231011091644.gwzkpbppuyjs3xp6@bogus> References: <20231010105503.jwrmjahuvcjgwtk5@bogus> <20231010130054.ieylxocuapugajif@bogus> <20231010133059.57rs52qedrc5mxfr@bogus> <20231010145137.fyxjlsj5qq3elq7l@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 Wed, Oct 11, 2023 at 12:30:35AM +0000, Peng Fan wrote: > > Subject: Re: Question regarding scmi_perf_domain.c > > > > On Tue, Oct 10, 2023 at 01:43:32PM +0000, Peng Fan wrote: > > > > Subject: Re: Question regarding scmi_perf_domain.c > > > > > > > > On Tue, Oct 10, 2023 at 01:15:26PM +0000, Peng Fan wrote: > > > > > > > > > > Thanks for the detailed explanation, so power-domains property > > > > > could be used both for power domain or performance domain. But if > > > > > one device has both power domain and performance domain. Only > > > > > power-domain property is not enough. I may understand wrong, let me > > look into the code. > > > > > > > > > > > > > I haven't tried this but something I could come up quick wit Juno > > > > DTS as > > > > reference: > > > > > > > > We can change something like this: > > > > > > > > scmi_dvfs: protocol@13 { > > > > reg = <0x13>; > > > > - #clock-cells = <1>; > > > > + #power-domain-cells = <1>; > > > > mbox-names = "tx", "rx"; > > > > mboxes = <&mailbox 1 0 &mailbox 1 1>; > > > > shmem = <&cpu_scp_hpri0 &cpu_scp_hpri1>; > > > > }; > > > > > > > > And then in the consumer node(taking GPU as it has both perf and > > > > power domains). The CPUs are simpler as don't have explicit power > > > > domains, some Qcom platforms do use that. Anyways I would change > > GPU node like this. > > > > Hope this clarifies things for you. > > > > > > > > &gpu { > > > > - clocks = <&scmi_dvfs 2>; > > > > - power-domains = <&scmi_devpd 9>; > > > > + power-domains = <&scmi_dvfs 2 &scmi_devpd 9>; > > > > + power-domain-names = "perf", "power"; > > > > > > With one single power domain, the platform common code will > > > automatically power on the domain before probe, with help from > > > genpd_dev_pm_attach. > > > > > > But with multiple entries, device driver should handle power domains > > > by themselves. > > > > > > Maybe Ulf could comment whether the genpd could update to support > > > perf/power case just as one power domain entry before. > > > > > > > Hmm, I would rather check if the genpd can still handle automatic > > power on of the domain before probe with one power and one perf domain. > > IWO, one power domains and other domains in the mix. The reason why we > > can't have single domain to support both power and perf using SCMI is > > we don't know if the domains are 1:1 as presented by the SCMI platform > > firmware. > > > > AFAIU it was the main issue/confusion you raised initially. I am > > surprised as how we had all these discussions and now you are circling > > back and requesting to combine the support in single domain which > > contradicts your initial confusion. I am seriously lost as what you are > > looking for now ? > > No, I am not requesting to combine in single domain. I still wanna perf > domain and power domain has their own IDs. But I was not aware > perf domain is using power-domains property, so one device has > power domains and perf domains both, the automatic power domain > on is broken. I was thinking we introduce a new property saying > perf-domains property. > IIUC, this should not need any extra information from the DT than what we already have. It is just implementation could improve to deal with your ask. -- Regards, Sudeep