On 11/22/2022 1:50 AM, Krzysztof Kozlowski wrote: > 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@xxxxxxxxxxx> >>>> --- >>>> .../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@xxxxxxxxxx> >>>> + - Odelu Kukatla <quic_okukatla@xxxxxxxxxxx> >>>> + >>>> +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. Thanks, Melody > > Best regards, > Krzysztof >
