mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>, heiko@sntech.de
Cc: Rob Herring <robh+dt@kernel.org>,
	Johan Jonker <jbx6244@gmail.com>,
	Helen Koike <helen.koike@collabora.com>,
	Shunqian Zheng <zhengsq@rock-chips.com>,
	Jacob Chen <jacob2.chen@rock-chips.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Markus Reichl <m.reichl@fivetechno.de>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"moderated list:ARM/Rockchip SoC support" 
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC support" 
	<linux-rockchip@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dt: rockchip: rk3399: Add dynamic power coefficient for GPU
Date: Fri, 19 Mar 2021 18:05:50 +0000	[thread overview]
Message-ID: <11480a47-47da-c5b3-edad-c2dd8edb2cd9@arm.com> (raw)
In-Reply-To: <9322db05-2cad-453c-ec1b-1fdb3df142fa@linaro.org>

On 2021-03-19 14:35, Daniel Lezcano wrote:
> 
> Hi Robin,
> 
> On 19/03/2021 13:17, Robin Murphy wrote:
>> On 2021-03-19 11:05, Daniel Lezcano wrote:
>>> The DTPM framework is looking for upstream SoC candidates to share the
>>> power numbers.
>>>
>>> We can see around different numbers but the one which seems to be
>>> consistent with the initial post for the values on the CPUs can be
>>> found in the patch https://lore.kernel.org/patchwork/patch/810159/
>>
>> The kernel hacker in me would be more inclined to trust the BSP that the
>> vendor actively supports than a 5-year-old patch that was never pursued
>> upstream. Apparently that was last updated more recently:
>>
>> https://github.com/rockchip-linux/kernel/commit/98d4505e1bd62ff028bd79fbd8284d64b6f468f8
> 
> Yes, I've seen this value also.
> 
>> The ex-mathematician in me can't even comment either way without
>> evidence that whatever model expects to consume this value is even
>> comparable to whatever "arm,mali-simple-power-model" is. >
>> The way the
>> latter apparently needs an explicit "static" coefficient as well as a
>> "dynamic" one, and the value here being nearly 3 times that of a
>> similarly-named one in active use downstream (ChromeOS appears to still
>> be using the values from before the above commit), certainly incline me
>> to think they may not be...
> 
> Sorry, I'm missing the point :/
> 
> We dropped in the kernel any static power computation because as there
> was no value, the resulting code was considered dead. So we rely on the
> dynamic power only.

Right, so a 2-factor model is clearly not identical to a 1-factor model, 
so how do we know that a value for one is valid for the other, even if 
it happens to have a similar name? I'm not saying that it is or isn't; I 
don't know. If someone can point to the downstream coefficient 
definition being identical to the upstream one then great, let's use 
that as justification. If not, then the justification of one arbitrary 
meaningless number over any other is a bit misleading.

>>> I don't know the precision of this value but it is better than
>>> nothing.
>>
>> But is it? If it leads to some throttling mechanism kicking in and
>> crippling GPU performance because it's massively overestimating power
>> consumption, that would be objectively worse for most users, no?
> 
> No because there is no sustainable power specified for the thermal zones
> related to the GPU.
OK, that's some reassurance at least. Does the exact value have any 
material effect? If not, what's to stop us from using an obviously 
made-up value like 1, and saying so?

Robin.

  reply	other threads:[~2021-03-19 18:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 11:05 Daniel Lezcano
2021-03-19 12:17 ` Robin Murphy
2021-03-19 14:35   ` Daniel Lezcano
2021-03-19 18:05     ` Robin Murphy [this message]
2021-03-19 18:38       ` Daniel Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11480a47-47da-c5b3-edad-c2dd8edb2cd9@arm.com \
    --to=robin.murphy@arm.com \
    --cc=boris.brezillon@collabora.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=helen.koike@collabora.com \
    --cc=jacob2.chen@rock-chips.com \
    --cc=jbx6244@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=m.reichl@fivetechno.de \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    --cc=zhengsq@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®