Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <8aa2592d-5fc7-4ae2-a355-fcf46bb076de@arm.com>
Date:   Mon, 27 Nov 2023 10:00:15 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to
 rk3399 GPU
Content-Language: en-US
To:     =?UTF-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>
Cc:     robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
        linux-rockchip@lists.infradead.org, conor+dt@kernel.org,
        linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org
References: <20231127081511.1911706-1-lukasz.luba@arm.com>
 <14787054.VsHLxoZxqI@diego>
From:   Lukasz Luba <lukasz.luba@arm.com>
In-Reply-To: <14787054.VsHLxoZxqI@diego>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Heiko,

On 11/27/23 09:42, Heiko Stübner wrote:
> Hi Lukasz,
> 
> Am Montag, 27. November 2023, 09:15:11 CET schrieb Lukasz Luba:
>> Add dynamic-power-coefficient to the GPU node. That will create Energy
>> Model for the GPU based on the coefficient and OPP table information.
>> It will enable mechanism such as DTMP or IPA to work with the GPU DVFS.
>> In similar way the Energy Model for CPUs in rk3399 is created, so both
>> are aligned in power scale. The maximum power used from this coefficient
>> is 1.5W at 600MHz.
> 
> 2640 is a pretty arbitary value, so it would be really helpful to describe
> in the commit message, how you arrived with that specific value.

It's in the above patch header. The power at 600MHz is ~1.5Watts, so for
max freq and max voltage you get the coefficient. The DT schema
describes quite well how the coefficient is calculated. IMO, there is no
need to duplicate that description here [1].

Have you checked that documentation? Is there still anything unclear?
I might elaborate a bit more why it's important for GPU to take the top
OPP for considerations (due to thermal operating mostly on top-half
OPPs, but the curve is a bit constraining). Unfortunately, this simple
model doesn't allow to reflect the leakage impact over time. It doesn't
also address the chip binning lottery. Although, it will be possible in
near future to address those [2].

Regards,
Lukasz

[1] 
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml#L94
[2] 
https://lore.kernel.org/lkml/20230925081139.1305766-1-lukasz.luba@arm.com/