Re: [RFC 4/7] soc: qcom: Utilize qcom scmi vendor protocol for bus dvfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 6/19/24 01:07, Konrad Dybcio wrote:


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?

CPUCP isn't expected to know the various ranges supported by the memory
buses it can vote on and from a sandboxing perspective one would want to
control what CPUCP has access to as well. It also can't arrive at the
exact values just from the OPP tables we pass on as well. So it doesn't
have any default values to start off with. For all these reasons, they
need explicit setting up and without it, the algorithm wouldn't function
as expected.

-Sibi


Konrad




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux