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]

Date:   Wed, 23 Feb 2022 10:52:02 +0100
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Lukasz Luba <lukasz.luba@....com>, linux-kernel@...r.kernel.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
Subject: Re: [PATCH v2 0/2] Introduce 'advanced' Energy Model in DT


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.

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


On 22/02/2022 15:07, Lukasz Luba wrote:
> Hi all,
> 
> This patch set solves a few issues:
> 1. It allows to register EM from DT, when the voltage information is not
>     available. (Some background of the issues present on Chromebook devices
>     can be checked at [1].)
> 2. It allows to register 'advanced' EM from the DT, which is more accurate
>     and reflects total power (dynamic + static).
> 
> Implementation details:
> It adds a new callback in OPP framework to parse the OPP node entry and
> read the "opp-microwatt". It's going to only work with OPP-v2, but it's
> agreed to be OK.
> 
> Comments, suggestions are very welcome.
> 
> changelog:
> v2:
> - implemented Viresh idea to add "opp-microwatt" into the OPP node entry in DT
> v1 [2]
> 
> Regards,
> Lukasz Luba
> 
> [1] https://lore.kernel.org/linux-pm/20220207073036.14901-2-lukasz.luba@arm.com/
> [2] https://lore.kernel.org/linux-pm/20220221225131.15836-1-lukasz.luba@arm.com/
> 
> Lukasz Luba (2):
>    dt-bindings: opp: Add 'opp-microwatt' entry in the OPP
>    OPP: Add 'opp-microwatt' parsing for advanced EM registration
> 
>   .../devicetree/bindings/opp/opp-v2-base.yaml  |  7 ++
>   drivers/opp/of.c                              | 70 +++++++++++++++++++
>   2 files changed, 77 insertions(+)
> 


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog