linux-kernel - Re: [PATCH v4] dt-bindings: dvfs: Add support for generic 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]

Date:   Tue, 19 Oct 2021 15:58:35 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>
Cc:     Rob Herring <robh@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Hector Yuan <hector.yuan@...iatek.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v4] dt-bindings: dvfs: Add support for generic performance domains

On Tue, 19 Oct 2021 at 09:24, Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 15-10-21, 11:17, Ulf Hansson wrote:
> > As far as I understand, the "performance domains" DT bindings that
> > $subject patch introduces, allows us to group devices into domains, to
> > let them be "performance controlled" together. Right?
>
> This and it also provides a reg space where we can get/set the
> performance state.

Right. So that can be done for power-domains too.

>
> > Unless I am missing something, it looks like power domains DT bindings
> > already offer this for us. Yes, certainly, the DT doc [1] needs an
> > updated description to better explain this, but other than that we
> > should be fine, don't you think?
>
> I think yes we can make it work through that as well, but I am not
> sure if we will be able to use required-opp n stuff here as the DT
> doesn't have the OPP table for the CPUs.
>
> The CPU's freq table is generated at runtime, see
> drivers/cpufreq/mediatek-cpufreq-hw.c for example.

To me, this looks doable from a genpd provider too. Of course, we may
need to extend the genpd interface a bit to make it fit well for this
new use case, of course. And I am happy to help, if that is needed.

One thing though; how is the aggregation of the OPP votes expected to
be done? Is that entirely managed by FW - or is it expected that the
cpufreq driver, in this case, keeps track of the aggregated votes too?

Don't get me wrong, I am not pushing for these DT bindings to be
deprecated (at least not yet :-)), but I would certainly like to
understand more about them. In the end, we haven't walked this far, by
extending genpd and inventing new DT bindings to enable it to support
"performance management" - then just to just forget about them again.
:-)

Kind regards
Uffe