| Message ID | 20220720192807.130098-11-krzysztof.kozlowski@linaro.org |
|---|---|
| State | Accepted |
| Commit | 7921bd3d96d561d5bf145a905e9cc51c1fce589f |
| Headers | show |
| Series | soc/arm64: qcom: Add LLCC BWMON on SDM845 | expand |
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
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
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?
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 >
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 >>
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
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 --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>;
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(+)