| Message ID | 20221118182245.31035-2-quic_molvera@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add interconnect support for QDU1000/QRU1000 SoCs | expand |
On 11/21/2022 9:23 AM, Georgi Djakov wrote: > Hi Melody, > > On 18.11.22 20:22, Melody Olvera wrote: >> Add documentation for virtual rpmh devices. These interconnects >> are not controlled by the application processor and thus >> require separate bindings. Also, move compatibles for sm8450 to >> this document and add them for QDU1000/QRU1000 platforms. >> >> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >> --- >> .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++ >> .../bindings/interconnect/qcom,rpmh.yaml | 2 - >> 2 files changed, 55 insertions(+), 2 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >> >> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >> new file mode 100644 >> index 000000000000..5cbaa51df863 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >> @@ -0,0 +1,55 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect >> + >> +maintainers: >> + - Georgi Djakov <georgi.djakov@linaro.org> > > This email is not valid anymore, so please replace it with djakov@kernel.org. Sounds good. Melody > > Thanks, > Georgi > >> + - Odelu Kukatla <quic_okukatla@quicinc.com> >> + >> +description: | >> + RPMh interconnect providers support system bandwidth requirements through >> + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is >> + able to communicate with the BCM through the Resource State Coordinator (RSC) >> + associated with each execution environment. Provider nodes must point to at >> + least one RPMh device child node pertaining to their RSC and each provider >> + can map to multiple RPMh resources. Virtual interconnect providers are not >> + controlled by AP and do not support QoS; they should not have associated >> + register regions. >> + >> +allOf: >> + - $ref: qcom,rpmh-common.yaml# >> + >> +properties: >> + compatible: >> + enum: >> + - qcom,qdu1000-clk-virt >> + - qcom,qdu1000-mc-virt >> + - qcom,sm8450-clk-virt >> + - qcom,sm8450-mc-virt >> + >> + '#interconnect-cells': true >> + >> +required: >> + - compatible >> + >> +unevaluatedProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/interconnect/qcom,sm8450.h> >> + >> + clk_virt: interconnect-0 { >> + compatible = "qcom,sm8450-clk-virt"; >> + #interconnect-cells = <2>; >> + qcom,bcm-voters = <&apps_bcm_voter>; >> + }; >> + >> + mc_virt: interconnect-1 { >> + compatible = "qcom,sm8450-mc-virt"; >> + #interconnect-cells = <2>; >> + qcom,bcm-voters = <&apps_bcm_voter>; >> + }; >> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml >> index a429a1ed1006..bd474f49deb0 100644 >> --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml >> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml >> @@ -123,11 +123,9 @@ properties: >> - qcom,sm8350-system-noc >> - qcom,sm8450-aggre1-noc >> - qcom,sm8450-aggre2-noc >> - - qcom,sm8450-clk-virt >> - qcom,sm8450-config-noc >> - qcom,sm8450-gem-noc >> - qcom,sm8450-lpass-ag-noc >> - - qcom,sm8450-mc-virt >> - qcom,sm8450-mmss-noc >> - qcom,sm8450-nsp-noc >> - qcom,sm8450-pcie-anoc >
On 21/11/2022 18:39, Melody Olvera wrote: > > > On 11/20/2022 5:13 AM, Krzysztof Kozlowski wrote: >> On 18/11/2022 19:22, Melody Olvera wrote: >>> Add documentation for virtual rpmh devices. These interconnects >>> are not controlled by the application processor and thus >>> require separate bindings. Also, move compatibles for sm8450 to >>> this document and add them for QDU1000/QRU1000 platforms. >>> >>> Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> >>> --- >>> .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++ >>> .../bindings/interconnect/qcom,rpmh.yaml | 2 - >>> 2 files changed, 55 insertions(+), 2 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >>> new file mode 100644 >>> index 000000000000..5cbaa51df863 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml >>> @@ -0,0 +1,55 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect >>> + >>> +maintainers: >>> + - Georgi Djakov <georgi.djakov@linaro.org> >>> + - Odelu Kukatla <quic_okukatla@quicinc.com> >>> + >>> +description: | >>> + RPMh interconnect providers support system bandwidth requirements through >>> + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is >>> + able to communicate with the BCM through the Resource State Coordinator (RSC) >>> + associated with each execution environment. Provider nodes must point to at >>> + least one RPMh device child node pertaining to their RSC and each provider >>> + can map to multiple RPMh resources. Virtual interconnect providers are not >>> + controlled by AP and do not support QoS; they should not have associated >>> + register regions. >>> + >>> +allOf: >>> + - $ref: qcom,rpmh-common.yaml# >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - qcom,qdu1000-clk-virt >>> + - qcom,qdu1000-mc-virt >>> + - qcom,sm8450-clk-virt >>> + - qcom,sm8450-mc-virt >> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt, >> qcom,sc8280xp-clk-virt and more. > > Ok. I wasn't sure since some of these entries don't seem to conform to > these bindings, even though it seems they should. I have impression that devices I listed conform to these bindings, this is why I listed them. But if you are sure that they do not, then they should not be moved. Best regards, Krzysztof
On 22/11/2022 18:57, Melody Olvera wrote: >>>>> + >>>>> +maintainers: >>>>> + - Georgi Djakov <georgi.djakov@linaro.org> >>>>> + - Odelu Kukatla <quic_okukatla@quicinc.com> >>>>> + >>>>> +description: | >>>>> + RPMh interconnect providers support system bandwidth requirements through >>>>> + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is >>>>> + able to communicate with the BCM through the Resource State Coordinator (RSC) >>>>> + associated with each execution environment. Provider nodes must point to at >>>>> + least one RPMh device child node pertaining to their RSC and each provider >>>>> + can map to multiple RPMh resources. Virtual interconnect providers are not >>>>> + controlled by AP and do not support QoS; they should not have associated >>>>> + register regions. >>>>> + >>>>> +allOf: >>>>> + - $ref: qcom,rpmh-common.yaml# >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + enum: >>>>> + - qcom,qdu1000-clk-virt >>>>> + - qcom,qdu1000-mc-virt >>>>> + - qcom,sm8450-clk-virt >>>>> + - qcom,sm8450-mc-virt >>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt, >>>> qcom,sc8280xp-clk-virt and more. >>> Ok. I wasn't sure since some of these entries don't seem to conform to >>> these bindings, even though it seems they should. >> I have impression that devices I listed conform to these bindings, this >> is why I listed them. But if you are sure that they do not, then they >> should not be moved. > > You're correct; those you listed do conform to the new bindings and should be moved. > I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings. Actually let's wait a bit with this. For SM8550 we had an idea to move interconnect to their own bindings file, because they will grow a bit with allOf:if:then clauses. Maybe SM8450 and QDU1000 should also go to their own files which will describe all their interconnects (the virt and the ones requiring clocks)? Apologies for bringing it late for your patches, but SM8550 is also happening right now, so new things pop-up :) Best regards, Krzysztof
On 11/28/2022 9:25 AM, Melody Olvera wrote: > > On 11/24/2022 2:30 AM, Krzysztof Kozlowski wrote: >> On 22/11/2022 18:57, Melody Olvera wrote: >>>>>>> + >>>>>>> +maintainers: >>>>>>> + - Georgi Djakov <georgi.djakov@linaro.org> >>>>>>> + - Odelu Kukatla <quic_okukatla@quicinc.com> >>>>>>> + >>>>>>> +description: | >>>>>>> + RPMh interconnect providers support system bandwidth requirements through >>>>>>> + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is >>>>>>> + able to communicate with the BCM through the Resource State Coordinator (RSC) >>>>>>> + associated with each execution environment. Provider nodes must point to at >>>>>>> + least one RPMh device child node pertaining to their RSC and each provider >>>>>>> + can map to multiple RPMh resources. Virtual interconnect providers are not >>>>>>> + controlled by AP and do not support QoS; they should not have associated >>>>>>> + register regions. >>>>>>> + >>>>>>> +allOf: >>>>>>> + - $ref: qcom,rpmh-common.yaml# >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + enum: >>>>>>> + - qcom,qdu1000-clk-virt >>>>>>> + - qcom,qdu1000-mc-virt >>>>>>> + - qcom,sm8450-clk-virt >>>>>>> + - qcom,sm8450-mc-virt >>>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt, >>>>>> qcom,sc8280xp-clk-virt and more. >>>>> Ok. I wasn't sure since some of these entries don't seem to conform to >>>>> these bindings, even though it seems they should. >>>> I have impression that devices I listed conform to these bindings, this >>>> is why I listed them. But if you are sure that they do not, then they >>>> should not be moved. >>> You're correct; those you listed do conform to the new bindings and should be moved. >>> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings. >> Actually let's wait a bit with this. For SM8550 we had an idea to move >> interconnect to their own bindings file, because they will grow a bit >> with allOf:if:then clauses. >> >> Maybe SM8450 and QDU1000 should also go to their own files which will >> describe all their interconnects (the virt and the ones requiring clocks)? >> >> Apologies for bringing it late for your patches, but SM8550 is also >> happening right now, so new things pop-up :) > Yeah no worries. I can definitely make this change; if this is how we want to do > things going forward I'm happy to oblige. > > Thanks, > Melody I think though for these PS, I'll stick to doing w QDU1000. So I'll have a file qcom,qdu1000-rpmh.yaml and qcom,qdu1000-rpmh-virt.yaml Thanks, Melody >> Best regards, >> Krzysztof >>
On 11/28/2022 3:08 PM, Melody Olvera wrote: > > On 11/28/2022 9:25 AM, Melody Olvera wrote: >> On 11/24/2022 2:30 AM, Krzysztof Kozlowski wrote: >>> On 22/11/2022 18:57, Melody Olvera wrote: >>>>>>>> + >>>>>>>> +maintainers: >>>>>>>> + - Georgi Djakov <georgi.djakov@linaro.org> >>>>>>>> + - Odelu Kukatla <quic_okukatla@quicinc.com> >>>>>>>> + >>>>>>>> +description: | >>>>>>>> + RPMh interconnect providers support system bandwidth requirements through >>>>>>>> + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is >>>>>>>> + able to communicate with the BCM through the Resource State Coordinator (RSC) >>>>>>>> + associated with each execution environment. Provider nodes must point to at >>>>>>>> + least one RPMh device child node pertaining to their RSC and each provider >>>>>>>> + can map to multiple RPMh resources. Virtual interconnect providers are not >>>>>>>> + controlled by AP and do not support QoS; they should not have associated >>>>>>>> + register regions. >>>>>>>> + >>>>>>>> +allOf: >>>>>>>> + - $ref: qcom,rpmh-common.yaml# >>>>>>>> + >>>>>>>> +properties: >>>>>>>> + compatible: >>>>>>>> + enum: >>>>>>>> + - qcom,qdu1000-clk-virt >>>>>>>> + - qcom,qdu1000-mc-virt >>>>>>>> + - qcom,sm8450-clk-virt >>>>>>>> + - qcom,sm8450-mc-virt >>>>>>> You should also move qcom,sdx65-mc-virt, qcom,sc8280xp-mc-virt, >>>>>>> qcom,sc8280xp-clk-virt and more. >>>>>> Ok. I wasn't sure since some of these entries don't seem to conform to >>>>>> these bindings, even though it seems they should. >>>>> I have impression that devices I listed conform to these bindings, this >>>>> is why I listed them. But if you are sure that they do not, then they >>>>> should not be moved. >>>> You're correct; those you listed do conform to the new bindings and should be moved. >>>> I also caught qcom,sc7280-clk-virt which needs to be moved. I'll add to the new bindings. >>> Actually let's wait a bit with this. For SM8550 we had an idea to move >>> interconnect to their own bindings file, because they will grow a bit >>> with allOf:if:then clauses. >>> >>> Maybe SM8450 and QDU1000 should also go to their own files which will >>> describe all their interconnects (the virt and the ones requiring clocks)? >>> >>> Apologies for bringing it late for your patches, but SM8550 is also >>> happening right now, so new things pop-up :) >> Yeah no worries. I can definitely make this change; if this is how we want to do >> things going forward I'm happy to oblige. >> >> Thanks, >> Melody > I think though for these PS, I'll stick to doing w QDU1000. So I'll have a file qcom,qdu1000-rpmh.yaml > and qcom,qdu1000-rpmh-virt.yaml > > Thanks, > Melody Nevermind; looks like SM8550 is keeping all in one file, so I'll keep all in one file. > >>> Best regards, >>> Krzysztof >>>
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml new file mode 100644 index 000000000000..5cbaa51df863 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,rpmh-virt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPMh Virtual Network-On-Chip Interconnect + +maintainers: + - Georgi Djakov <georgi.djakov@linaro.org> + - Odelu Kukatla <quic_okukatla@quicinc.com> + +description: | + RPMh interconnect providers support system bandwidth requirements through + RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is + able to communicate with the BCM through the Resource State Coordinator (RSC) + associated with each execution environment. Provider nodes must point to at + least one RPMh device child node pertaining to their RSC and each provider + can map to multiple RPMh resources. Virtual interconnect providers are not + controlled by AP and do not support QoS; they should not have associated + register regions. + +allOf: + - $ref: qcom,rpmh-common.yaml# + +properties: + compatible: + enum: + - qcom,qdu1000-clk-virt + - qcom,qdu1000-mc-virt + - qcom,sm8450-clk-virt + - qcom,sm8450-mc-virt + + '#interconnect-cells': true + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interconnect/qcom,sm8450.h> + + clk_virt: interconnect-0 { + compatible = "qcom,sm8450-clk-virt"; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; + + mc_virt: interconnect-1 { + compatible = "qcom,sm8450-mc-virt"; + #interconnect-cells = <2>; + qcom,bcm-voters = <&apps_bcm_voter>; + }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index a429a1ed1006..bd474f49deb0 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -123,11 +123,9 @@ properties: - qcom,sm8350-system-noc - qcom,sm8450-aggre1-noc - qcom,sm8450-aggre2-noc - - qcom,sm8450-clk-virt - qcom,sm8450-config-noc - qcom,sm8450-gem-noc - qcom,sm8450-lpass-ag-noc - - qcom,sm8450-mc-virt - qcom,sm8450-mmss-noc - qcom,sm8450-nsp-noc - qcom,sm8450-pcie-anoc
Add documentation for virtual rpmh devices. These interconnects are not controlled by the application processor and thus require separate bindings. Also, move compatibles for sm8450 to this document and add them for QDU1000/QRU1000 platforms. Signed-off-by: Melody Olvera <quic_molvera@quicinc.com> --- .../bindings/interconnect/qcom,rpmh-virt.yaml | 55 +++++++++++++++++++ .../bindings/interconnect/qcom,rpmh.yaml | 2 - 2 files changed, 55 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,rpmh-virt.yaml