Re: Question regarding scmi_perf_domain.c

[Sudeep Holla <sudeep.holla@arm.com>]

On Tue, Oct 17, 2023 at 01:18:38PM +0000, Peng Fan wrote:
> > Subject: Re: Question regarding scmi_perf_domain.c
> > 
> > On Thu, 12 Oct 2023 at 13:53, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Wed, 11 Oct 2023 at 16:17, Sudeep Holla <sudeep.holla@arm.com>
> > 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?
> 
> For debug, this is ok. But release the code for production, keep them enabled
> during boot is not good.

What is the point in adding it ? You can always hack and test if you need.

> > 
> > Maybe a module parameter or Kconfig debug option could be used to control
> > this?
> 
> Greg might not be happy for introducing module parameter, I guess.
>

True. But I don't see point in adding a Kconfig as it needs to be enabled
with single (distro) Image.

> > 
> > 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.
> > 
> > Peng, would this resolve your concern?
> 
> Actually I am not sure. multiple PD is not a technical issue, it is just adding
> more changes to various device drivers, we have VPU/GPU/DISPLAY/NPU/
> HSIO/CAMERA and etc.. so all the drivers need update, which is
> not welcomed by driver developers :)

Why ? Have you posted the patches ? Any discussions you can point to ?

> I am still trying to enable multiple PD for saying MMC,
> and see how it works after adding performance domain and how device
> dvfs works in such case.
>

Interesting. So MMC domain is presented as perf domain rather than the clock
+ regulator ? Nice to see that abstraction being used.

-- 
Regards,
Sudeep