Re: Question regarding scmi_perf_domain.c

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

On Tue, Oct 10, 2023 at 12:53:58PM +0000, Peng Fan wrote:
> Hi Sudeep
>
> > Subject: Re: Question regarding scmi_perf_domain.c
> >
> > On Tue, Oct 10, 2023 at 01:02:01PM +0200, Ulf Hansson wrote:
> > > On Tue, 10 Oct 2023 at 12:55, Sudeep Holla <sudeep.holla@arm.com>
> > wrote:
> > > >
> > > > On Tue, Oct 10, 2023 at 10:30:17AM +0000, Peng Fan wrote:
> > > > > Hi Ulf,
> > > > >
> > > > > I just see you wrote scmi_perf_domain.c, just wonder this driver
> > > > > is only for devices, not support arm cores, right?
> > > > >
> > > > > For ARM cores, we still need scmi_cpufreq.c for performance
> > > > > settings, right?
> > > >
> > > > Sorry if I wasn't clear. The reason I mentioned it in private is
> > > > that we now support the power domain bindings in the scmi-cpufreq.c
> > > > as you were little bit nervous to use the clock bindings(though they
> > > > work just fine, I understand the possible confusion with the clock
> > protocol).
> > >
> > > Right, good point!
> > >
> > > I think we discussed earlier whether we should deprecate the use of
> > > the clock bindings. Maybe that's a good idea, to indicate that we
> > > prefer the power-domain bindings when going forward?
> >
> > Yes we could do that. I prefer to have some example in the actual DTS files
> > before we can think of deprecating it. I need to get around, test and push the
> > change to switch from clock to power domain bindings on Juno for example.
>
> Before that, I think we need think about whether it is possible to use
> a property saying perf-domain, using power domains implies a restriction
> that power domain is same as perf domain, but the spec not say that.
>

Just responded on the other thread, lets continue the discussion there to
keep the related discussions together there.

--
Regards,
Sudeep