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 C72D1CDB474 for ; Tue, 17 Oct 2023 09:04:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234741AbjJQJEa (ORCPT ); Tue, 17 Oct 2023 05:04:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234145AbjJQJE3 (ORCPT ); Tue, 17 Oct 2023 05:04:29 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F308DF7 for ; Tue, 17 Oct 2023 02:04:26 -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 3217A2F4; Tue, 17 Oct 2023 02:05:07 -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 B2DF73F762; Tue, 17 Oct 2023 02:04:25 -0700 (PDT) Date: Tue, 17 Oct 2023 10:04:23 +0100 From: Sudeep Holla To: Ulf Hansson Cc: Peng Fan , 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: <20231010130054.ieylxocuapugajif@bogus> <20231010133059.57rs52qedrc5mxfr@bogus> <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 Mon, Oct 16, 2023 at 05:08:18PM +0200, Ulf Hansson wrote: > On Thu, 12 Oct 2023 at 13:53, Ulf Hansson wrote: > > > > On Wed, 11 Oct 2023 at 16:17, Sudeep Holla wrote: > > > > > > On Wed, Oct 11, 2023 at 11:26:54AM +0200, Ulf Hansson wrote: > > > > > > [..] > > > > > > > Not sure exactly what you are referring to when saying that "automatic > > > > power domain on is broken". Genpd power-on the PM domain for a device > > > > that gets attached to it, if the device has only a single PM domain. > > > > This is the legacy behaviour. > > > > > > > > When we added support for multiple PM domains per device, we decided > > > > to *not* power-on the PM domain, if the device that gets attached has > > > > multiple PM domains. This behaviour was chosen deliberately, to allow > > > > consumer drivers to decide themselves instead. Is there a problem with > > > > this you think? > > > > > > > > > > Just my understanding. Since the second PM domain added now is for perf > > > and is not strictly power domain, Peng's concern is switching to this > > > binding will make the platform loose this automatic genpd power-on > > > feature. > > > > Yes, correct, as they way things are today. > > > > It all boils down to that attaching a device to multiple PM domains > > can't really be done in a generic way, as it becomes device/platform > > specific. Since this needs to be managed by the drivers/buses anyway, > > they might as well get control of what PM domain they need to power-on > > to probe their devices. > > Due to the above, it might be a good idea to power-on the SCMI > *power-domains* during boot and leave them on to allow drivers to > continue to probe their devices? > Such workarounds in my opinion are always inviting troubles as few platforms make not like it that way. > Maybe a module parameter or Kconfig debug option could be used to control this? > May be that works, but again I see this as working around. If the expectation is the driver must manage the PM domain eventually, does it make sense to start doing that now. You termed the single domain power on automatically in the genpd as the "legacy support". Do you mean there is a plan to remove it or make drivers not rely on it ? My main worry is now we are spreading this work around every where. It was in genpd but now you want in SCMI power domain driver. It just makes things harder to remove if the eventual plan is to make drivers take care of the power domains themselves. > 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. > This will work, but I find it hard as addition of some extra information in the DTS is ending up losing some feature which was otherwise available. If platforms relied on it, they may just stick with clock bindings silently as it is easier that way. Even expecting a module param might be a big ask if someone working on the platform isn't aware of all the details. That is my main concern. -- Regards, Sudeep