From: Sudeep Holla <sudeep.holla@arm.com>
To: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>,
"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"cristian.marussi@arm.com" <cristian.marussi@arm.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off
Date: Mon, 13 Jan 2025 17:20:38 +0000 [thread overview]
Message-ID: <Z4VLZgAWR7ugDl7W@bogus> (raw)
In-Reply-To: <PA4PR04MB94855052830C8F4874237BA6921F2@PA4PR04MB9485.eurprd04.prod.outlook.com>
On Mon, Jan 13, 2025 at 03:30:58PM +0000, Ranjani Vaidyanathan wrote:
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla@arm.com]
> Sent: Monday, January 13, 2025 7:49 AM
> To: Peng Fan <peng.fan@nxp.com>
> Cc: Peng Fan (OSS) <peng.fan@oss.nxp.com>; cristian.marussi@arm.com; Sudeep Holla <sudeep.holla@arm.com>; ulf.hansson@linaro.org; arm-scmi@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org; Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
> Subject: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off
>
> On Mon, Jan 13, 2025 at 11:37:23AM +0000, Peng Fan wrote:
> > > Subject: Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state
> > > as off
> > >
> > > On Fri, Jan 10, 2025 at 02:13:46PM +0800, Peng Fan (OSS) wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > Per ARM SCMI Spec DEN0056E, page 16, "The platform may disable a
> > > > resource if no agent has requested to use that resource."
> > > >
> > >
> > > True, but ...
> > >
> > > > Linux Kernel should not rely on a state that it has not requested,
> > > > so make state as off during initialization.
> > > >
> > >
> > > IIUC, this was done to avoid any transitions if the bootloader like
> > > U- Boot has turned on the resource and OS can just rely on that stay.
> >
> > But if it is not U-Boot turned it on?
>
> Not sure if I understand what exactly you mean by that.
> [RV] Its possible that some other agent (M33/M7 running OS) in the system
> turned on the power domain. Resources in the same power domain can shared
> across agents. That being said, uboot provides mechanism to clean up any
> power domains/clocks that it enabled. And our implementation of uboot does
> disable any power domain it powered up for downloading of images or anything
> else (display is a unique case if splash screen is enabled).
>
Right I was referring to the display as one of the example when I referred
to the case where bootloader turns on the resource.
> >
> > Because the power domain is ON, kernel will not issue SCMI to platform
> > to request it ON when kernel needs this power domain on.
> >
>
> Yes, but the agent(via bootloader) has already requested the SCMI platform,
> so it should be fine. No ?
> [RV] As mentioned above, it need not be the bootloader. And secondly how to
> handle this power domain during suspend/resume? It's possible that the agent
> that turned on the power domain initially will have different wakeup
> requirements. IMO Linux should completely be responsible for the power
> domains that the drivers need.
>
May be I am still missing something. The genpd framework does issue power
down of all the PD that are not used once we boot. Is that not sufficient.
We are just not changing the pd state when initialising the genpds.
Is that causing the issue ? I was under the impression that it shouldn't
matter if the driver manages the genpds they consume and all unused ones
get turned off eventually.
What exactly is the issue for which this patch is the solution ? I think
I might have not understood the issue properly here. Sorry if that is the
case.
--
Regards,
Sudeep
next prev parent reply other threads:[~2025-01-13 17:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 6:13 [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off Peng Fan (OSS)
2025-01-13 10:31 ` Sudeep Holla
2025-01-13 11:37 ` Peng Fan
2025-01-13 13:49 ` Sudeep Holla
2025-01-13 15:30 ` [EXT] " Ranjani Vaidyanathan
2025-01-13 17:20 ` Sudeep Holla [this message]
2025-01-13 17:54 ` Cristian Marussi
2025-01-13 19:40 ` Ranjani Vaidyanathan
2025-01-13 19:54 ` Ranjani Vaidyanathan
2025-01-14 15:24 ` Sudeep Holla
2025-01-14 16:09 ` Ranjani Vaidyanathan
2025-01-14 18:16 ` Sudeep Holla
2025-01-15 9:15 ` Cristian Marussi
2025-01-15 18:42 ` Ranjani Vaidyanathan
2025-01-16 16:18 ` Cristian Marussi
2025-01-17 1:22 ` Peng Fan
2025-01-17 5:13 ` Dan Carpenter
2025-01-13 19:33 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4VLZgAWR7ugDl7W@bogus \
--to=sudeep.holla@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=ranjani.vaidyanathan@nxp.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).