[PATCH 1/2] dt-bindings: arm,scmi: Do not use clocks for SCMI performance domains

[Sudeep Holla]

On Fri, Oct 23, 2020 at 08:34:05AM -0500, Rob Herring wrote:
> On Wed, Oct 21, 2020 at 1:19 PM Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > On Wed, Oct 21, 2020 at 11:20:27AM -0500, Rob Herring wrote:
> > > On Tue, Oct 20, 2020 at 3:37 PM Sudeep Holla <sudeep.holla at arm.com> wrote:
> > > >
> >
> > [...]
> >
> > >
> > > When is this not 1 (IOW, you only need this if variable)? How would it
> > > be used outside SCMI (given it has a generic name)?
> > >
> > > > +
> > > > +* Property arm,scmi-perf-domain
> > >
> > [...]
> >
> > > Really though, why can't you give SCMI a CPUs MPIDR and get its domain?
> > >
> >
> > Now I remembered why we can't use MPIDR. The spec talks about perf domains
> > for devices in generic. CPU is just a special device. We will still need
> > a mechanism to get device performance domain. So MPIDR idea was dropped to
> > keep it uniform across all the devices.
>
> What implications to the binding are there for non-CPU devices? Do
> they need more cells? How does this integrate our plethora of other PM
> related bindings?
>

Ideally it is just a device perf domain ID. SCMI f/w will just assign
perf domain IDs for both CPUs and other devices like GPUs sequentially
without any distinction.

However, I can't speak about other aspects of PM especially on wild
variety of platforms we have on Arm.

Today even with SCMI each device/cpu needs to track clock or performance,
reset, power, voltage, ...etc domains and their IDs needs to be passed
via DT.

We are thinking of making all these device ID centric in future. It means
if the device tree had scmi device ID for each of them, we must be able to
perform any power management or configuration management on that device.
SCMI f/w must then abstract everything at device level. Just a thought
as of now and it aligns with some of the ACPI concepts.

> So somewhere in the firmware we're defining device X is domain 0,
> device Y is domain 1, etc. Then we do this again in DT. Seems fragile
> to define this information twice. I guess that's true for any number
> space SCMI defines.
>

Correct and agreed on your point. Any ideas to make this discoverable ?
Atleast with SCMI, we have been able to reduce the amount of information
just to that ID(though there are multiple ID space today for each aspects
of PM and config management). As I mentioned we would like to make it
device centric. Any thoughts on making IDs discoverable is appreciated.

We thought about names and other things during initial days of the
spec evolution, but we circled back to how does OS provide that info and
we go back to DT/ACPI which was not too bad at that time. We can see if
we can improve anything there.

--
Regards,
Sudeep