Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <467a7de4-df84-8e9e-a26a-80449ca55950@linaro.org>
Date:   Wed, 23 Feb 2022 10:52:02 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH v2 0/2] Introduce 'advanced' Energy Model in DT
Content-Language: en-US
To:     Lukasz Luba <lukasz.luba@arm.com>, linux-kernel@vger.kernel.org
Cc:     dietmar.eggemann@arm.com, viresh.kumar@linaro.org,
        rafael@kernel.org, nm@ti.com, sboyd@kernel.org, mka@chromium.org,
        dianders@chromium.org, robh+dt@kernel.org,
        devicetree@vger.kernel.org, linux-pm@vger.kernel.org
References: <20220222140746.12293-1-lukasz.luba@arm.com>
From:   Daniel Lezcano <daniel.lezcano@linaro.org>
In-Reply-To: <20220222140746.12293-1-lukasz.luba@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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