Re: [PATCH 15/18] ARM: dts: qcom: apq8064: provide voltage scaling tables

[Dmitry Baryshkov <dmitry.baryshkov@linaro.org>]

On 12/06/2023 16:59, Stephan Gerhold wrote:
> On Mon, Jun 12, 2023 at 04:33:09PM +0300, Dmitry Baryshkov wrote:
>> On 12/06/2023 12:01, Stephan Gerhold wrote:
>>> On Mon, Jun 12, 2023 at 08:39:19AM +0300, Dmitry Baryshkov wrote:
>>>> APQ8064 has 4 speed bins, each of them having from 4 to 6 categorization
>>>> kinds. Provide tables necessary to handle voltage scaling on this SoC.
>>>>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> ---
>>>>    arch/arm/boot/dts/qcom-apq8064.dtsi | 1017 +++++++++++++++++++++++++++
>>>>    1 file changed, 1017 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
>>>> index 4ef13f3d702b..f35853b59544 100644
>>>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
>>>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
>>>> @@ -49,6 +49,9 @@ CPU0: cpu@0 {
>>>>    			clocks = <&kraitcc KRAIT_CPU_0>;
>>>>    			clock-names = "cpu";
>>>>    			clock-latency = <100000>;
>>>> +			vdd-mem-supply = <&pm8921_l24>;
>>>> +			vdd-dig-supply = <&pm8921_s3>;
>>>> +			vdd-core-supply = <&saw0_vreg>;
>>>>    			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
>>>>    			operating-points-v2 = <&cpu_opp_table>;
>>>>    			#cooling-cells = <2>;
>>>> @@ -66,6 +69,9 @@ CPU1: cpu@1 {
>>>>    			clocks = <&kraitcc KRAIT_CPU_1>;
>>>>    			clock-names = "cpu";
>>>>    			clock-latency = <100000>;
>>>> +			vdd-mem-supply = <&pm8921_l24>;
>>>> +			vdd-dig-supply = <&pm8921_s3>;
>>>> +			vdd-core-supply = <&saw1_vreg>;
>>>>    			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
>>>>    			operating-points-v2 = <&cpu_opp_table>;
>>>>    			#cooling-cells = <2>;
>>>> @@ -83,6 +89,9 @@ CPU2: cpu@2 {
>>>>    			clocks = <&kraitcc KRAIT_CPU_2>;
>>>>    			clock-names = "cpu";
>>>>    			clock-latency = <100000>;
>>>> +			vdd-mem-supply = <&pm8921_l24>;
>>>> +			vdd-dig-supply = <&pm8921_s3>;
>>>> +			vdd-core-supply = <&saw2_vreg>;
>>>>    			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
>>>>    			operating-points-v2 = <&cpu_opp_table>;
>>>>    			#cooling-cells = <2>;
>>>> @@ -100,6 +109,9 @@ CPU3: cpu@3 {
>>>>    			clocks = <&kraitcc KRAIT_CPU_3>;
>>>>    			clock-names = "cpu";
>>>>    			clock-latency = <100000>;
>>>> +			vdd-mem-supply = <&pm8921_l24>;
>>>> +			vdd-dig-supply = <&pm8921_s3>;
>>>> +			vdd-core-supply = <&saw3_vreg>;
>>>>    			interconnects = <&kraitcc MASTER_KRAIT_L2 &kraitcc SLAVE_KRAIT_L2>;
>>>>    			operating-points-v2 = <&cpu_opp_table>;
>>>>    			#cooling-cells = <2>;
>>>> @@ -132,6 +144,81 @@ cpu_opp_table: opp-table-cpu {
>>>>    		opp-384000000 {
>>>>    			opp-hz = /bits/ 64 <384000000>;
>>>>    			opp-peak-kBps = <384000>;
>>>> +			opp-microvolt-speed0-pvs0 = <1050000 1050000 1150000>,
>>>> +						    <950000 950000 1150000>,
>>>> +						    <950000 950000 975000>;
>>>

[skipped the OPP voltage vs bw ordering]

>>
>>>
>>> The alternative that I've already argued for on IRC in #linux-msm a
>>> couple of days ago would be to give the L2 cache (here: "interconnect")
>>> an own OPP table where it can describe its voltage requirements,
>>> independent from the CPU. That way the icc_set_bw() would be guaranteed
>>> to apply the correct voltage before adjusting the L2 cache clock. It
>>> looks like the "l2_level" voltages for vdd_dig and vdd_mem are not
>>> speedbin/PVS-specific [2] so this would also significantly reduce the DT
>>> size, since you wouldn't need to repeat the same vdd_dig/vdd_mem
>>> voltages for all of them.
>>
>> Yes. I fact our discussion triggered me to do this patchset.
>>
>> So, another option would be to have something like the following snippet. Do
>> you know if we are allowed to squish additional data into the L2 cache DT
>> node?
>>
> 
> I suspect no one has tried this before, so only the DT maintainers could
> answer this. I would say that it just follows the existing design of
> clocks/-supply/OPPs on the CPU nodes. vdd-mem-supply isn't a property of
> the CPU, it's a property of the L2 cache so it actually fits better there. >
> I think the more controversial questions might be:
> 
>    - Is a L2 cache really an "interconnect"? I suppose one could argue it
>      connects multiple CPU cores to a cluster (similar how a CCI connects
>      multiple clusters to a system).

Yes. This was my reasoning for CBF clock as well as for this L2 clock. 
The separate L2 cache device is also an interconnect from my POV. It 
connects all CPU cores and we have to vote on its frequency.

>    - What would bind to the l2-cache node? A separate driver? Does that
>      work if it sits below the /cpus node?

In the worst case we'd have to populate that manually. E.g. from the 
qcom-cpufreq-nvmem.c

-- 
With best wishes
Dmitry