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

[Sibi Sankar <quic_sibis@quicinc.com>]

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