linux-kernel - Re: [PATCH v2 0/2] Introduce 'advanced' Energy Model in DT

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] [day] [month] [year] [list]

Message-ID: <5fb6d841-db47-2009-9c41-e45f51de47cc@arm.com>
Date:   Wed, 23 Feb 2022 11:40:33 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     linux-kernel@...r.kernel.org, dietmar.eggemann@....com,
        rafael@...nel.org, nm@...com, sboyd@...nel.org, mka@...omium.org,
        dianders@...omium.org, robh+dt@...nel.org,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 0/2] Introduce 'advanced' Energy Model in DT



On 2/23/22 11:27, Viresh Kumar wrote:
> On 23-02-22, 11:22, Lukasz Luba wrote:
>> On 2/23/22 10:43, Viresh Kumar wrote:
>>> On 23-02-22, 10:52, Daniel Lezcano wrote:
>>>> why not extend the energy model to any kind of devices?
>>>
>>> FWIW, the OPP core supports a wide range of devices now, not just CPUs.
> 
> There are many other devices which still use Freq.
> 
>> Is that the "opp-level" thing which would allow that?
> 
> For power supplies/regulators, we don't have freq and they use level, right.
> 
> Also for interconnect we use bandwidth, in a similar way.
> 
>> I can see some DT files with regulators(?) using it e.g. [1].
>> It looks flexible, the opp-hz is not hard requirement,
>> the opp-level can be used instead IIUC.
> 
> Right.
> 

Looks good. It also doesn't collide with this patch set.

We could have an opp entry like:

	opp_1: opp-1 {
		opp-level = <1>;
		opp-microwatt = <200000>;
	};

Daniel would that design make sense to you?


If yes, we could discuss this further after this first
step for fixing GPU in merged. I would need to re-think
the EM em_perf_state and maybe the new ::level there.