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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <854f324d-c9dc-affc-6f6f-0219bcbc1e1b@quicinc.com>
Date: Mon, 1 Jul 2024 14:14:05 +0530
From: Sibi Sankar <quic_sibis@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>, <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 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