linux-kernel - Re: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to rk3399 GPU

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: <8aa2592d-5fc7-4ae2-a355-fcf46bb076de@arm.com>
Date:   Mon, 27 Nov 2023 10:00:15 +0000
From:   Lukasz Luba <lukasz.luba@....com>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-rockchip@...ts.infradead.org, conor+dt@...nel.org,
        linux-kernel@...r.kernel.org, daniel.lezcano@...aro.org
Subject: Re: [PATCH] arm64: dts: rockchip: Add dynamic-power-coefficient to
 rk3399 GPU

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/