Message-ID:
 <PA4PR04MB9485E62D248B983AE182187D921F2@PA4PR04MB9485.eurprd04.prod.outlook.com>
Date: Mon, 13 Jan 2025 19:40:43 +0000
From: Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>
To: Cristian Marussi <cristian.marussi@....com>, Sudeep Holla
	<sudeep.holla@....com>
CC: Peng Fan <peng.fan@....com>, "Peng Fan (OSS)" <peng.fan@....nxp.com>,
	"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>, "arm-scmi@...r.kernel.org"
	<arm-scmi@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state
 as off

Hello Cristian,

Regards,
Ranjani Vaidyanathan

-----Original Message-----
From: Cristian Marussi [mailto:cristian.marussi@....com] 
Sent: Monday, January 13, 2025 11:54 AM
To: Sudeep Holla <sudeep.holla@....com>; Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>
Cc: Peng Fan <peng.fan@....com>; Peng Fan (OSS) <peng.fan@....nxp.com>; cristian.marussi@....com; ulf.hansson@...aro.org; arm-scmi@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button


On Mon, Jan 13, 2025 at 05:20:38PM +0000, Sudeep Holla wrote:
> On Mon, Jan 13, 2025 at 03:30:58PM +0000, Ranjani Vaidyanathan wrote:
> > -----Original Message-----
> > From: Sudeep Holla [mailto:sudeep.holla@....com]
> > Sent: Monday, January 13, 2025 7:49 AM
> > To: Peng Fan <peng.fan@....com>
> > Cc: Peng Fan (OSS) <peng.fan@....nxp.com>; cristian.marussi@....com; 
> > Sudeep Holla <sudeep.holla@....com>; ulf.hansson@...aro.org; 
> > arm-scmi@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; 
> > linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org; Ranjani 
> > Vaidyanathan <ranjani.vaidyanathan@....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@....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?

Hi Sudeep, Ranjani,

> >
> > 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).
> >
>

So, RV,  you are saying that the your UBoot is cleanly releasing/turning_OFF all the resources that it claimed during its life before giving control to Linux (sicne no more needed) BUT some other agent in the system has requested that resource to be ON, so when Linux query the status of the resources it sees it as ON since it sees the physical real status of the resource ?

If this is the case, I suspected this was the issue, and I will address these scenario in a separate mail on this thread that I was already in the middle of writing....

[RV] Yes, this is our case. The platform will return the physical view of the resource (as SCMI spec has left it to be implementation defined).  I will try to provide comments to your other long email. 

> 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.

I think GenPD turns off unused PD domains ONLY if pd_ignore_unused kernel-param is false, BUT it is true by default AFAICS.

Thanks,
Cristian

Powered by blists - more mailing lists