Message-ID: <Z4VqcQuY0VhXDg6g@pluto>
Date: Mon, 13 Jan 2025 19:33:17 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Peng Fan <peng.fan@....com>, "Peng Fan (OSS)" <peng.fan@....nxp.com>,
	"cristian.marussi@....com" <cristian.marussi@....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>,
	Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>
Subject: Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off

On Mon, Jan 13, 2025 at 01:49:12PM +0000, Sudeep Holla wrote:
> 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."
> > > >

Hi,

not really a short mail this one...

> > >
> > > 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.
> 
> > Or U-Boot is in a separate agent?
> >
> 
> No, it will be same as OS for the SCMI platform/agent as they use/share the
> same transport. It is hard to distinguish between them.
> 

Exactly, if U-Boot is SCMI capable, its requests will have been accounted,
lets say, as Agent_X, but when the Kernel springs to life it will take over
the role and the SAME channel used by the defunct UBoot, so as to appear as
being effectively the same Agent_X to the platform...

...the tricky part is what happens when, instead, UBoot is NOT an SCMI agent
and it does leave some resources ON (say some regulator needed while setting up
the screen...) with the intent of NOT having those turned off by the Kernel ?
(BUT with such actions not tracked by the platform, not being an SCMI agent)

To make the matter worse, all of this sort of "resource-state-alignment-issue"
between bootloader, Kernel or other independent agents, greatly depends on how
the state-get operations were implemented.

IOW, since some resources could be shared between agents (clocks, PDs), a
set-state on such resources is supposed to be "harmonized" by the platform,
so that, say, res_X will be enabled physically only when the first agent
acquires it, and res_X will be finally disabled only when the last agent
relinquishes it...

....you certainly dont want that after agent_A have issued a set_ON(res_X),
another agent_B issuing a set_OFF(res_X) can cause that same shared res_X to
be effectively switched off while still used by agent_A...in such a case agent_B
should receive an OK but res_X should anyway effectively stay ON until also
agent_A has relinquished it too...

...now the question is...what state would you expect to read-back from a
get_state operation on such shared resources ? the real/physical one OR the
virtual/per_agent state ?

...IOW in the above example, after agent_B successfully issued a set_OFF(res_X),
on the shared res_X (which indeed did NOT really caused sharted res_X to be
turned OFF) what will agent_B should read back from a get_state(res_X):

	OFF (virtual-view) ? ... or ON (physical view) ?

This platform "states-view" behaviour was long debated and at the end
AFAICR it has been left by the spec as IMPDEF, so each platform can
decide what to return...physical vs virtual state...and that means that,
whatever we do, Kernel side we should cope with 4 possible scenarios

- Uboot NON-SCMI / physical GET_STATE platform-impl
- Uboot NON-SCMI / virtual GET_STATE platform-impl
- Uboot SCMI / physical GET_STATE platform-impl
- Uboot SCMI / virtual GET_STATE platform-impl

...and in all of these scenarios we should additionally consider what
happens when the kernel wants or want-not to keep a resource in the state,
that it has found it (as queried with a get_state (physical or virtual))

IOW, as an example, what if:

I have an UBOOT/NON_SCMI that leaves res_X OFF from its point-of-view at
the end of its life, BUT res_X is also claimed as ON by another SCMI agent_Z
at the same time, and the platform implements physical-real-views, so that
Kernel will see anyway res_X as ON....what should happen, in this context,
if the Kernel wants to keep res_X ON ?

OR what if:

I have an UBOOT/SCMI agent_X that leaves res_X ON from its point-of-view at
the end of its life, BUT res_X is also claimed as ON by another SCMI agent_Z
at the same time, and the platform implements virtual-per-agent-views,
so that Kernel will see res_X as ON....what will happen, in this
context, if the Kernel wants to turn res_X OFF ? AND what happens
instead if, in this scenario, we have additionally the currently proposed patch
applied (that forcibly would makke the Kernel think that res_X is OFF) ?

All of these scenario should be considered, and I have indeed an even
longer (:P) mail currently brewing on my side to try to layout all
possibilities...

...next days once it is more refined I will post it.... you've been warned ! :P

Thanks
Cristian

Powered by blists - more mailing lists