diff mbox series

[10/10] arm64: dts: qcom: sdm845: add LLCC BWMON

Message ID 20220720192807.130098-11-krzysztof.kozlowski@linaro.org
State Superseded
Headers show
Series soc/arm64: qcom: Add LLCC BWMON on SDM845 | expand

Commit Message

Krzysztof Kozlowski July 20, 2022, 7:28 p.m. UTC
The SDM845 comes with few instances of Bandwidth Monitor.  The already
supported one monitors traffic between CPU and Last Level Cache
Controller (LLCC) and in downstream sources is called BWMON v4 (or v4 of
register layout).

SDM845 also has also BWMON instance measuring traffic between LLCC and
memory with different register layout: called v5.

Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 37 ++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

Comments

Steev Klimaszewski July 22, 2022, 1:22 a.m. UTC | #1
Hi Krzysztof,

On 7/20/22 2:28 PM, Krzysztof Kozlowski wrote:
> The SDM845 comes with few instances of Bandwidth Monitor.  The already
> supported one monitors traffic between CPU and Last Level Cache
> Controller (LLCC) and in downstream sources is called BWMON v4 (or v4 of
> register layout).
>
> SDM845 also has also BWMON instance measuring traffic between LLCC and
> memory with different register layout: called v5.
>
> Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sdm845.dtsi | 37 ++++++++++++++++++++++++++++
>   1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fe14f7e7523b..4aab464e2bd6 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -2053,6 +2053,43 @@ llcc: system-cache-controller@1100000 {
>   			interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
>   		};
>   
> +		pmu@114a000 {
> +			compatible = "qcom,sdm845-llcc-bwmon";
> +			reg = <0 0x0114a000 0 0x1000>;
> +			interrupts = <GIC_SPI 580 IRQ_TYPE_LEVEL_HIGH>;
> +			interconnects = <&mem_noc MASTER_LLCC 3 &mem_noc SLAVE_EBI1 3>;
> +
> +			operating-points-v2 = <&llcc_bwmon_opp_table>;
> +
> +			llcc_bwmon_opp_table: opp-table {
> +				compatible = "operating-points-v2";
> +
> +				/*
> +				 * The interconnect path bandwidth taken from
> +				 * cpu4_opp_table bandwidth for gladiator_noc-mem_noc
> +				 * interconnect.  This also matches the
> +				 * bandwidth table of qcom,llccbw (qcom,bw-tbl,
> +				 * bus width: 4 bytes) from msm-4.9 downstream
> +				 * kernel.
> +				 */
> +				opp-0 {
> +					opp-peak-kBps = <800000>;
> +				};
> +				opp-1 {
> +					opp-peak-kBps = <1804000>;
> +				};
> +				opp-2 {
> +					opp-peak-kBps = <3072000>;
> +				};
> +				opp-3 {
> +					opp-peak-kBps = <5412000>;
> +				};
> +				opp-4 {
> +					opp-peak-kBps = <7216000>;
> +				};
> +			};
> +		};
> +
>   		pmu@1436400 {
>   			compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
>   			reg = <0 0x01436400 0 0x600>;


With this series applied, testing on a Lenovo Yoga C630, which has an 
SDM850, I see the following:

[    3.673660] qcom-bwmon 114a000.pmu: can't request region for resource 
[mem 0x0114a000-0x0114afff]
[    3.673673] qcom-bwmon 114a000.pmu: error -EBUSY: failed to map bwmon 
registers
[    3.673678] qcom-bwmon: probe of 114a000.pmu failed with error -16
Krzysztof Kozlowski July 22, 2022, 5:30 p.m. UTC | #2
On 22/07/2022 03:22, Steev Klimaszewski wrote:
> Hi Krzysztof,
> 
> On 7/20/22 2:28 PM, Krzysztof Kozlowski wrote:
>> The SDM845 comes with few instances of Bandwidth Monitor.  The already
>> supported one monitors traffic between CPU and Last Level Cache
>> Controller (LLCC) and in downstream sources is called BWMON v4 (or v4 of
>> register layout).
>>
>> SDM845 also has also BWMON instance measuring traffic between LLCC and
>> memory with different register layout: called v5.
>>
>> Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sdm845.dtsi | 37 ++++++++++++++++++++++++++++
>>   1 file changed, 37 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index fe14f7e7523b..4aab464e2bd6 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -2053,6 +2053,43 @@ llcc: system-cache-controller@1100000 {
>>   			interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
>>   		};
>>   
>> +		pmu@114a000 {
>> +			compatible = "qcom,sdm845-llcc-bwmon";
>> +			reg = <0 0x0114a000 0 0x1000>;
>> +			interrupts = <GIC_SPI 580 IRQ_TYPE_LEVEL_HIGH>;
>> +			interconnects = <&mem_noc MASTER_LLCC 3 &mem_noc SLAVE_EBI1 3>;
>> +
>> +			operating-points-v2 = <&llcc_bwmon_opp_table>;
>> +
>> +			llcc_bwmon_opp_table: opp-table {
>> +				compatible = "operating-points-v2";
>> +
>> +				/*
>> +				 * The interconnect path bandwidth taken from
>> +				 * cpu4_opp_table bandwidth for gladiator_noc-mem_noc
>> +				 * interconnect.  This also matches the
>> +				 * bandwidth table of qcom,llccbw (qcom,bw-tbl,
>> +				 * bus width: 4 bytes) from msm-4.9 downstream
>> +				 * kernel.
>> +				 */
>> +				opp-0 {
>> +					opp-peak-kBps = <800000>;
>> +				};
>> +				opp-1 {
>> +					opp-peak-kBps = <1804000>;
>> +				};
>> +				opp-2 {
>> +					opp-peak-kBps = <3072000>;
>> +				};
>> +				opp-3 {
>> +					opp-peak-kBps = <5412000>;
>> +				};
>> +				opp-4 {
>> +					opp-peak-kBps = <7216000>;
>> +				};
>> +			};
>> +		};
>> +
>>   		pmu@1436400 {
>>   			compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
>>   			reg = <0 0x01436400 0 0x600>;
> 
> 
> With this series applied, testing on a Lenovo Yoga C630, which has an 
> SDM850, I see the following:
> 
> [    3.673660] qcom-bwmon 114a000.pmu: can't request region for resource 
> [mem 0x0114a000-0x0114afff]
> [    3.673673] qcom-bwmon 114a000.pmu: error -EBUSY: failed to map bwmon 
> registers
> [    3.673678] qcom-bwmon: probe of 114a000.pmu failed with error -16
> 

Thanks for the report. What are you running there? `uname -r`? Maybe
your secure world uses it?

Best regards,
Krzysztof
Steev Klimaszewski July 23, 2022, 12:29 a.m. UTC | #3
On 7/22/22 12:30 PM, Krzysztof Kozlowski wrote:
> On 22/07/2022 03:22, Steev Klimaszewski wrote:
>> Hi Krzysztof,
>>
>> On 7/20/22 2:28 PM, Krzysztof Kozlowski wrote:
>>> The SDM845 comes with few instances of Bandwidth Monitor.  The already
>>> supported one monitors traffic between CPU and Last Level Cache
>>> Controller (LLCC) and in downstream sources is called BWMON v4 (or v4 of
>>> register layout).
>>>
>>> SDM845 also has also BWMON instance measuring traffic between LLCC and
>>> memory with different register layout: called v5.
>>>
>>> Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>> ---
>>>    arch/arm64/boot/dts/qcom/sdm845.dtsi | 37 ++++++++++++++++++++++++++++
>>>    1 file changed, 37 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> index fe14f7e7523b..4aab464e2bd6 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -2053,6 +2053,43 @@ llcc: system-cache-controller@1100000 {
>>>    			interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
>>>    		};
>>>    
>>> +		pmu@114a000 {
>>> +			compatible = "qcom,sdm845-llcc-bwmon";
>>> +			reg = <0 0x0114a000 0 0x1000>;
>>> +			interrupts = <GIC_SPI 580 IRQ_TYPE_LEVEL_HIGH>;
>>> +			interconnects = <&mem_noc MASTER_LLCC 3 &mem_noc SLAVE_EBI1 3>;
>>> +
>>> +			operating-points-v2 = <&llcc_bwmon_opp_table>;
>>> +
>>> +			llcc_bwmon_opp_table: opp-table {
>>> +				compatible = "operating-points-v2";
>>> +
>>> +				/*
>>> +				 * The interconnect path bandwidth taken from
>>> +				 * cpu4_opp_table bandwidth for gladiator_noc-mem_noc
>>> +				 * interconnect.  This also matches the
>>> +				 * bandwidth table of qcom,llccbw (qcom,bw-tbl,
>>> +				 * bus width: 4 bytes) from msm-4.9 downstream
>>> +				 * kernel.
>>> +				 */
>>> +				opp-0 {
>>> +					opp-peak-kBps = <800000>;
>>> +				};
>>> +				opp-1 {
>>> +					opp-peak-kBps = <1804000>;
>>> +				};
>>> +				opp-2 {
>>> +					opp-peak-kBps = <3072000>;
>>> +				};
>>> +				opp-3 {
>>> +					opp-peak-kBps = <5412000>;
>>> +				};
>>> +				opp-4 {
>>> +					opp-peak-kBps = <7216000>;
>>> +				};
>>> +			};
>>> +		};
>>> +
>>>    		pmu@1436400 {
>>>    			compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
>>>    			reg = <0 0x01436400 0 0x600>;
>>
>> With this series applied, testing on a Lenovo Yoga C630, which has an
>> SDM850, I see the following:
>>
>> [    3.673660] qcom-bwmon 114a000.pmu: can't request region for resource
>> [mem 0x0114a000-0x0114afff]
>> [    3.673673] qcom-bwmon 114a000.pmu: error -EBUSY: failed to map bwmon
>> registers
>> [    3.673678] qcom-bwmon: probe of 114a000.pmu failed with error -16
>>
> Thanks for the report. What are you running there? `uname -r`? Maybe
> your secure world uses it?
>
> Best regards,
> Krzysztof

Currently it's 5.19.0-rc7 (torvalds tree at 4ba1329c) with a few extra 
patches on top, the bwmon set included.  It's possible that secure world 
uses it, but I do not know enough about that to say one way or the other.

-- steev
Steev Klimaszewski July 23, 2022, 2:37 a.m. UTC | #4
On 7/22/22 7:29 PM, Steev Klimaszewski wrote:
>
> On 7/22/22 12:30 PM, Krzysztof Kozlowski wrote:
>> On 22/07/2022 03:22, Steev Klimaszewski wrote:
>>> Hi Krzysztof,
>>>
>>> On 7/20/22 2:28 PM, Krzysztof Kozlowski wrote:
>>>> The SDM845 comes with few instances of Bandwidth Monitor.  The already
>>>> supported one monitors traffic between CPU and Last Level Cache
>>>> Controller (LLCC) and in downstream sources is called BWMON v4 (or 
>>>> v4 of
>>>> register layout).
>>>>
>>>> SDM845 also has also BWMON instance measuring traffic between LLCC and
>>>> memory with different register layout: called v5.
>>>>
>>>> Cc: Rajendra Nayak <quic_rjendra@quicinc.com>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/sdm845.dtsi | 37 
>>>> ++++++++++++++++++++++++++++
>>>>    1 file changed, 37 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
>>>> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> index fe14f7e7523b..4aab464e2bd6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>>> @@ -2053,6 +2053,43 @@ llcc: system-cache-controller@1100000 {
>>>>                interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
>>>>            };
>>>>    +        pmu@114a000 {
>>>> +            compatible = "qcom,sdm845-llcc-bwmon";
>>>> +            reg = <0 0x0114a000 0 0x1000>;
>>>> +            interrupts = <GIC_SPI 580 IRQ_TYPE_LEVEL_HIGH>;
>>>> +            interconnects = <&mem_noc MASTER_LLCC 3 &mem_noc 
>>>> SLAVE_EBI1 3>;
>>>> +
>>>> +            operating-points-v2 = <&llcc_bwmon_opp_table>;
>>>> +
>>>> +            llcc_bwmon_opp_table: opp-table {
>>>> +                compatible = "operating-points-v2";
>>>> +
>>>> +                /*
>>>> +                 * The interconnect path bandwidth taken from
>>>> +                 * cpu4_opp_table bandwidth for gladiator_noc-mem_noc
>>>> +                 * interconnect.  This also matches the
>>>> +                 * bandwidth table of qcom,llccbw (qcom,bw-tbl,
>>>> +                 * bus width: 4 bytes) from msm-4.9 downstream
>>>> +                 * kernel.
>>>> +                 */
>>>> +                opp-0 {
>>>> +                    opp-peak-kBps = <800000>;
>>>> +                };
>>>> +                opp-1 {
>>>> +                    opp-peak-kBps = <1804000>;
>>>> +                };
>>>> +                opp-2 {
>>>> +                    opp-peak-kBps = <3072000>;
>>>> +                };
>>>> +                opp-3 {
>>>> +                    opp-peak-kBps = <5412000>;
>>>> +                };
>>>> +                opp-4 {
>>>> +                    opp-peak-kBps = <7216000>;
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +
>>>>            pmu@1436400 {
>>>>                compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
>>>>                reg = <0 0x01436400 0 0x600>;
>>>
>>> With this series applied, testing on a Lenovo Yoga C630, which has an
>>> SDM850, I see the following:
>>>
>>> [    3.673660] qcom-bwmon 114a000.pmu: can't request region for 
>>> resource
>>> [mem 0x0114a000-0x0114afff]
>>> [    3.673673] qcom-bwmon 114a000.pmu: error -EBUSY: failed to map 
>>> bwmon
>>> registers
>>> [    3.673678] qcom-bwmon: probe of 114a000.pmu failed with error -16
>>>
>> Thanks for the report. What are you running there? `uname -r`? Maybe
>> your secure world uses it?
>>
>> Best regards,
>> Krzysztof
>
> Currently it's 5.19.0-rc7 (torvalds tree at 4ba1329c) with a few extra 
> patches on top, the bwmon set included.  It's possible that secure 
> world uses it, but I do not know enough about that to say one way or 
> the other.
>
> -- steev
>
I think you may be right; I just applied this patchset to -next 
(20220722) and i do not see the error message there.  On my 5.19-rc7 
tree, i am also testing a patchset that enables qcom devices to access 
efivars, so possibly we are ending up in secure world there?
Krzysztof Kozlowski July 23, 2022, 8:36 a.m. UTC | #5
On 23/07/2022 04:37, Steev Klimaszewski wrote:
>>
>> Currently it's 5.19.0-rc7 (torvalds tree at 4ba1329c) with a few extra 
>> patches on top, the bwmon set included.  It's possible that secure 
>> world uses it, but I do not know enough about that to say one way or 
>> the other.

To test patches you should apply them on maintainer's tree or
linux-next. Applying on other trees of course might be useful for
testing some backports, but it is independent process and different issue.

>>
>> -- steev
>>
> I think you may be right; I just applied this patchset to -next 
> (20220722) and i do not see the error message there.  On my 5.19-rc7 
> tree, i am also testing a patchset that enables qcom devices to access 
> efivars, so possibly we are ending up in secure world there?

Actually mapping of IO space should not touch secure world, so this was
a long shot assuming you test it on the next.


Best regards,
Krzysztof
Sibi Sankar July 26, 2022, 12:01 p.m. UTC | #6
On 7/26/22 5:01 PM, Sibi Sankar wrote:
> On 7/23/22 2:06 PM, Krzysztof Kozlowski wrote:
>> On 23/07/2022 04:37, Steev Klimaszewski wrote:
>>>>
>>>> Currently it's 5.19.0-rc7 (torvalds tree at 4ba1329c) with a few extra
>>>> patches on top, the bwmon set included.  It's possible that secure
>>>> world uses it, but I do not know enough about that to say one way or
>>>> the other.
>>
>> To test patches you should apply them on maintainer's tree or
>> linux-next. Applying on other trees of course might be useful for
>> testing some backports, but it is independent process and different 
>> issue.
>>
>>>>
>>>> -- steev
>>>>
>>> I think you may be right; I just applied this patchset to -next
>>> (20220722) and i do not see the error message there.  On my 5.19-rc7
>>> tree, i am also testing a patchset that enables qcom devices to access
>>> efivars, so possibly we are ending up in secure world there?
>>
>> Actually mapping of IO space should not touch secure world, so this was
>> a long shot assuming you test it on the next.
>>
> 
> The memory region specified in device tree overlaps with the llcc system
> cache controller node. Steev probably had the QCOM_LLCC config enabled 
> when he tested it out on his branch.

 From what I see we can probably get away with restricting the llcc_base
reg region to just llcc0_common region and leave the lcc-bwmon as is.

> 
>>
>> Best regards,
>> Krzysztof
>>
Krzysztof Kozlowski July 26, 2022, 1:49 p.m. UTC | #7
On 26/07/2022 14:01, Sibi Sankar wrote:
>>>> I think you may be right; I just applied this patchset to -next
>>>> (20220722) and i do not see the error message there.  On my 5.19-rc7
>>>> tree, i am also testing a patchset that enables qcom devices to access
>>>> efivars, so possibly we are ending up in secure world there?
>>>
>>> Actually mapping of IO space should not touch secure world, so this was
>>> a long shot assuming you test it on the next.
>>>
>>
>> The memory region specified in device tree overlaps with the llcc system
>> cache controller node. Steev probably had the QCOM_LLCC config enabled 
>> when he tested it out on his branch.
> 
>  From what I see we can probably get away with restricting the llcc_base
> reg region to just llcc0_common region and leave the lcc-bwmon as is.

Och, that IO mapping for llcc is quite big. I'll try that.


Best regards,
Krzysztof
Steev Klimaszewski July 26, 2022, 3:15 p.m. UTC | #8
On 7/26/22 6:31 AM, Sibi Sankar wrote:
> On 7/23/22 2:06 PM, Krzysztof Kozlowski wrote:
>> On 23/07/2022 04:37, Steev Klimaszewski wrote:
>>>>
>>>> Currently it's 5.19.0-rc7 (torvalds tree at 4ba1329c) with a few extra
>>>> patches on top, the bwmon set included.  It's possible that secure
>>>> world uses it, but I do not know enough about that to say one way or
>>>> the other.
>>
>> To test patches you should apply them on maintainer's tree or
>> linux-next. Applying on other trees of course might be useful for
>> testing some backports, but it is independent process and different 
>> issue.
>>
>>>>
>>>> -- steev
>>>>
>>> I think you may be right; I just applied this patchset to -next
>>> (20220722) and i do not see the error message there.  On my 5.19-rc7
>>> tree, i am also testing a patchset that enables qcom devices to access
>>> efivars, so possibly we are ending up in secure world there?
>>
>> Actually mapping of IO space should not touch secure world, so this was
>> a long shot assuming you test it on the next.
>>
>
> The memory region specified in device tree overlaps with the llcc system
> cache controller node. Steev probably had the QCOM_LLCC config enabled 
> when he tested it out on his branch.
>
>>
>> Best regards,
>> Krzysztof
>>
Good catch!  You are correct, my -next config did not have QCOM_LLCC 
set, and I am using QCOM_LLCC=m on the 5.19.0 release candidate.
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fe14f7e7523b..4aab464e2bd6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2053,6 +2053,43 @@  llcc: system-cache-controller@1100000 {
 			interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
 		};
 
+		pmu@114a000 {
+			compatible = "qcom,sdm845-llcc-bwmon";
+			reg = <0 0x0114a000 0 0x1000>;
+			interrupts = <GIC_SPI 580 IRQ_TYPE_LEVEL_HIGH>;
+			interconnects = <&mem_noc MASTER_LLCC 3 &mem_noc SLAVE_EBI1 3>;
+
+			operating-points-v2 = <&llcc_bwmon_opp_table>;
+
+			llcc_bwmon_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				/*
+				 * The interconnect path bandwidth taken from
+				 * cpu4_opp_table bandwidth for gladiator_noc-mem_noc
+				 * interconnect.  This also matches the
+				 * bandwidth table of qcom,llccbw (qcom,bw-tbl,
+				 * bus width: 4 bytes) from msm-4.9 downstream
+				 * kernel.
+				 */
+				opp-0 {
+					opp-peak-kBps = <800000>;
+				};
+				opp-1 {
+					opp-peak-kBps = <1804000>;
+				};
+				opp-2 {
+					opp-peak-kBps = <3072000>;
+				};
+				opp-3 {
+					opp-peak-kBps = <5412000>;
+				};
+				opp-4 {
+					opp-peak-kBps = <7216000>;
+				};
+			};
+		};
+
 		pmu@1436400 {
 			compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
 			reg = <0 0x01436400 0 0x600>;