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

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

 




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@xxxxxxxxxxx>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
---
   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?



[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