[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1610f135-f1a0-4c0a-8776-3e56371b58cc@linaro.org>
Date: Fri, 29 Sep 2023 17:23:46 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Rob Herring <robh@...nel.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Georgi Djakov <djakov@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Shawn Guo <shawn.guo@...aro.org>,
Marijn Suijten <marijn.suijten@...ainline.org>,
Konrad Dybcio <konradybcio@...nel.org>,
linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/7] dt-bindings: interconnect: qcom: Introduce
qcom,rpm-common
On 11.08.2023 18:48, Rob Herring wrote:
> On Mon, Jul 24, 2023 at 04:06:27PM +0200, Konrad Dybcio wrote:
>> The current RPM interconnect bindings are messy. Start cleaning them
>> up with a common include.
>>
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@...aro.org>
>> ---
>> .../bindings/interconnect/qcom,qcm2290.yaml | 18 +++++++-------
>> .../bindings/interconnect/qcom,rpm-common.yaml | 28 ++++++++++++++++++++++
>> 2 files changed, 36 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> index f65a2fe846de..df89f390a9b0 100644
>> --- a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml
>> @@ -13,6 +13,9 @@ description: |
>> The Qualcomm QCM2290 interconnect providers support adjusting the
>> bandwidth requirements between the various NoC fabrics.
>>
>> +allOf:
>> + - $ref: qcom,rpm-common.yaml#
>> +
>> properties:
>> reg:
>> maxItems: 1
>> @@ -23,9 +26,6 @@ properties:
>> - qcom,qcm2290-cnoc
>> - qcom,qcm2290-snoc
>>
>> - '#interconnect-cells':
>> - const: 1
>> -
>> clock-names:
>> items:
>> - const: bus
>> @@ -44,6 +44,9 @@ patternProperties:
>> The interconnect providers do not have a separate QoS register space,
>> but share parent's space.
>>
>> + allOf:
>> + - $ref: qcom,rpm-common.yaml#
>> +
>> properties:
>> compatible:
>> enum:
>> @@ -51,9 +54,6 @@ patternProperties:
>> - qcom,qcm2290-mmrt-virt
>> - qcom,qcm2290-mmnrt-virt
>>
>> - '#interconnect-cells':
>> - const: 1
>> -
>> clock-names:
>> items:
>> - const: bus
>> @@ -66,20 +66,18 @@ patternProperties:
>>
>> required:
>> - compatible
>> - - '#interconnect-cells'
>> - clock-names
>> - clocks
>>
>> - additionalProperties: false
>> + unevaluatedProperties: false
>>
>> required:
>> - compatible
>> - reg
>> - - '#interconnect-cells'
>> - clock-names
>> - clocks
>>
>> -additionalProperties: false
>> +unevaluatedProperties: false
>>
>> examples:
>> - |
>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
>> new file mode 100644
>> index 000000000000..1ea52b091609
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm-common.yaml
>> @@ -0,0 +1,28 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm RPMh Network-On-Chip Interconnect
>> +
>> +maintainers:
>> + - Konrad Dybcio <konradybcio@...nel.org>
>> +
>> +description:
>> + RPM interconnect providers support for managing system bandwidth requirements
>> + through manual requests based on either predefined values or as indicated by
>> + the bus monitor hardware. Each provider node represents a NoC bus master,
>> + driven by a dedicated clock source.
>> +
>> +properties:
>> + '#interconnect-cells':
>> + oneOf:
>> + - const: 2
>> + - const: 1
>> + deprecated: true
>
> I think this is kind of questionable for a single property. Do you
> plan to add more properties here?
My best answer is "we'll see". Not in the forseeable future, but
this hardware has a never-ending queue of surprises..
I like this file for the broader description, but ultimately up to you.
(FWIW Georgi has queued this up for icc-dev (not icc-next) and I'd like
to flush my icc patch queue, but that's just my lazy €0.05)
> Also, if you add a new user of this
> schema, then it's going to allow the deprecated case when it could just
> start with 2 only.
I see your point.
Speaking of this keyword, shouldn't the dt checker start spitting out
warnings that would urge dts maintainers to update their trees?
Konrad
Powered by blists - more mailing lists