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

Message-ID: <e2ee5603-0745-6d17-d389-fbee530a1985@arm.com>
Date:   Wed, 23 Feb 2022 10:16:15 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     dietmar.eggemann@....com, viresh.kumar@...aro.org,
        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,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] Introduce 'advanced' Energy Model in DT

Hi Daniel,

On 2/23/22 09:52, Daniel Lezcano wrote:
> 
> Hi Lukasz,
> 
> why not extend the energy model to any kind of devices?
> 
> The changes are shyly proposing a new entry in the OPP table like that 
> is the only place where power management can happen.

It was Viresh proposal to make it in the OPP v2 table. I've checked
the code and this u_watt fits perfectly there. New power value looks
natural there. We also have the interconnect info in the opp, so even
this kind of extensions are there.
It is a clean solution which meats the GPU requirements.

> 
> Is the approach to describe by small pieces here and there, specific 
> attributes and let the kernel create an energy model from that soap?
> 
> I prefer the RFC approach where the energy model is described clearly 
> but, IMHO, it should be more abstracted, without reference to frequency 
> or whatever but index <-> power (t-uple or equation)
> 
> By this way, it could be possible to describe the battery with the 
> different charges, the LCD bright light, etc ...

I can see your need, but I would focus on existing issues and devices.
This change was motivated by existing mainline platform which wants
to have EM in GPU (Chromebook) from DT. The GPU has OPP table, thus it
meets this requirement. The requirements are clear for the GPU (and
similar like DSP/ISP/etc which all have OPP table).

This is a clean, small step forward with the OPP approach and it
doesn't block your future needs and requirements. IMO it's orthogonal,
devices which have OPP table naturally might provide power there.
Devices which wouldn't have OPP table, but wanted to register EM
via DT - it's a different story (not the existing Chromebook's GPU).

This future story can be addressed in some next step. We need real
devices and examples to figure out the requirements and craft something.