[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <027b9ba8-20b7-4d20-8128-156398f21902@linaro.org>
Date: Tue, 18 Jun 2024 21:37:33 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Sibi Sankar <quic_sibis@...cinc.com>, sudeep.holla@....com,
cristian.marussi@....com, andersson@...nel.org, jassisinghbrar@...il.com,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, quic_rgottimu@...cinc.com,
quic_kshivnan@...cinc.com, conor+dt@...nel.org,
Amir Vajid <avajid@...cinc.com>
Subject: Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus
dvfs
On 2/12/24 11:33, Sibi Sankar wrote:
[...]
>>
>>> + monitor->mon_type = (of_property_read_bool(monitor_np, "qcom,compute-mon")) ? 1 : 0;
>>> + monitor->ipm_ceil = (of_property_read_bool(monitor_np, "qcom,compute-mon")) ? 0 : 20000000;
>>
>> What does it even mean for a monitor to be a compute mon?
>>
>
> When a monitor is marked compute-mon it means that the table is
> followed religiously irrespective whether the instruction per miss
> count threshold (ipm) is exceeded or not. Equivalent to having
> a cpufreq map -> l3/DDR bw mapping upstream.
I'm sorta puzzled why the OS would even be required to program this, since
L3/DDR/CPU frequencies are known by various stages of boot and secure firmware
too.
What happens if we omit this? Is the default configuration identical to this?
Or does it need explicit enabling?
Konrad
Powered by blists - more mailing lists