All of lore.kernel.org
 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 12:17:01 +0000	[thread overview]
Message-ID: <5db868e4-5b86-7b32-51e0-665a2e1fc1ac@arm.com> (raw)
In-Reply-To: <20210319110511.24787-1-daniel.lezcano@linaro.org>

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

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

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

Robin.

> Hopefully, one day SoC vendors will be more generous with the power
> numbers at least for the SoC which are from the previous generation
> and give the community the opportunity to develop power based
> frameworks.
> ---
>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index edbbf35fe19e..1ab1d293d2e9 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1933,6 +1933,7 @@
>   		interrupt-names = "job", "mmu", "gpu";
>   		clocks = <&cru ACLK_GPU>;
>   		#cooling-cells = <2>;
> +		dynamic-power-coefficient = <977>;
>   		power-domains = <&power RK3399_PD_GPU>;
>   		status = "disabled";
>   	};
> 

WARNING: multiple messages have this Message-ID (diff)
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 12:17:01 +0000	[thread overview]
Message-ID: <5db868e4-5b86-7b32-51e0-665a2e1fc1ac@arm.com> (raw)
In-Reply-To: <20210319110511.24787-1-daniel.lezcano@linaro.org>

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

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

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

Robin.

> Hopefully, one day SoC vendors will be more generous with the power
> numbers at least for the SoC which are from the previous generation
> and give the community the opportunity to develop power based
> frameworks.
> ---
>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index edbbf35fe19e..1ab1d293d2e9 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1933,6 +1933,7 @@
>   		interrupt-names = "job", "mmu", "gpu";
>   		clocks = <&cru ACLK_GPU>;
>   		#cooling-cells = <2>;
> +		dynamic-power-coefficient = <977>;
>   		power-domains = <&power RK3399_PD_GPU>;
>   		status = "disabled";
>   	};
> 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
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 12:17:01 +0000	[thread overview]
Message-ID: <5db868e4-5b86-7b32-51e0-665a2e1fc1ac@arm.com> (raw)
In-Reply-To: <20210319110511.24787-1-daniel.lezcano@linaro.org>

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

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

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

Robin.

> Hopefully, one day SoC vendors will be more generous with the power
> numbers at least for the SoC which are from the previous generation
> and give the community the opportunity to develop power based
> frameworks.
> ---
>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index edbbf35fe19e..1ab1d293d2e9 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1933,6 +1933,7 @@
>   		interrupt-names = "job", "mmu", "gpu";
>   		clocks = <&cru ACLK_GPU>;
>   		#cooling-cells = <2>;
> +		dynamic-power-coefficient = <977>;
>   		power-domains = <&power RK3399_PD_GPU>;
>   		status = "disabled";
>   	};
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 11:05 [PATCH] dt: rockchip: rk3399: Add dynamic power coefficient for GPU Daniel Lezcano
2021-03-19 11:05 ` Daniel Lezcano
2021-03-19 11:05 ` Daniel Lezcano
2021-03-19 12:17 ` Robin Murphy [this message]
2021-03-19 12:17   ` Robin Murphy
2021-03-19 12:17   ` Robin Murphy
2021-03-19 14:35   ` Daniel Lezcano
2021-03-19 14:35     ` Daniel Lezcano
2021-03-19 14:35     ` Daniel Lezcano
2021-03-19 18:05     ` Robin Murphy
2021-03-19 18:05       ` Robin Murphy
2021-03-19 18:05       ` Robin Murphy
2021-03-19 18:38       ` Daniel Lezcano
2021-03-19 18:38         ` Daniel Lezcano
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=5db868e4-5b86-7b32-51e0-665a2e1fc1ac@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.