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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201023142730.ru4rfoj3atxyinww@bogus>
Date:   Fri, 23 Oct 2020 15:27:30 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 1/2] dt-bindings: arm,scmi: Do not use clocks for SCMI
 performance domains

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