diff mbox series

[v2,1/4] dt-bindings: sound: Add Apple MCA I2S transceiver

Message ID 20220819125430.4920-2-povik+lin@cutebit.org
State Changes Requested, archived
Headers show
Series ASoC platform driver for Apple MCA | expand

Checks

Context Check Description
robh/checkpatch success
robh/patch-applied success
robh/dtbs-check warning build log
robh/dt-meta-schema success

Commit Message

Martin Povišer Aug. 19, 2022, 12:54 p.m. UTC
Add binding schema for MCA I2S transceiver found on Apple M1 and other
chips.

Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
---
 .../devicetree/bindings/sound/apple,mca.yaml  | 131 ++++++++++++++++++
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/apple,mca.yaml

Comments

Martin Povišer Aug. 19, 2022, 12:58 p.m. UTC | #1
> On 19. 8. 2022, at 14:54, Martin Povišer <povik+lin@cutebit.org> wrote:
> 
> Add binding schema for MCA I2S transceiver found on Apple M1 and other
> chips.
> 
> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
> ---
> .../devicetree/bindings/sound/apple,mca.yaml  | 131 ++++++++++++++++++
> 1 file changed, 131 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/apple,mca.yaml
> 
> diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
> new file mode 100644
> index 000000000000..7b4f348c2be3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
> @@ -0,0 +1,131 @@


> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - apple,t8103-mca
> +          - apple,t6000-mca

Since it was brought up last time but I didn’t respond: the
nonalphabetical order is as the chips were introduced (and
matches other schemas).

Martin
Krzysztof Kozlowski Aug. 19, 2022, 1:08 p.m. UTC | #2
On 19/08/2022 15:58, Martin Povišer wrote:
> 
>> On 19. 8. 2022, at 14:54, Martin Povišer <povik+lin@cutebit.org> wrote:
>>
>> Add binding schema for MCA I2S transceiver found on Apple M1 and other
>> chips.
>>
>> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
>> ---
>> .../devicetree/bindings/sound/apple,mca.yaml  | 131 ++++++++++++++++++
>> 1 file changed, 131 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/sound/apple,mca.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
>> new file mode 100644
>> index 000000000000..7b4f348c2be3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
>> @@ -0,0 +1,131 @@
> 
> 
>> +properties:
>> +  compatible:
>> +    items:
>> +      - enum:
>> +          - apple,t8103-mca
>> +          - apple,t6000-mca
> 
> Since it was brought up last time but I didn’t respond: the
> nonalphabetical order is as the chips were introduced (and
> matches other schemas).

Sure, just keep that order for future compatibles as well - so always
put them according to verifiable time of market introduction...

This is very poor reason, instead of alphabetical order. Even worse
reason is repeating wrong pattern just because someone else did it.

Best regards,
Krzysztof
Krzysztof Kozlowski Aug. 19, 2022, 1:09 p.m. UTC | #3
On 19/08/2022 16:08, Krzysztof Kozlowski wrote:
> On 19/08/2022 15:58, Martin Povišer wrote:
>>
>>> On 19. 8. 2022, at 14:54, Martin Povišer <povik+lin@cutebit.org> wrote:
>>>
>>> Add binding schema for MCA I2S transceiver found on Apple M1 and other
>>> chips.
>>>
>>> Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
>>> ---
>>> .../devicetree/bindings/sound/apple,mca.yaml  | 131 ++++++++++++++++++
>>> 1 file changed, 131 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/sound/apple,mca.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
>>> new file mode 100644
>>> index 000000000000..7b4f348c2be3
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
>>> @@ -0,0 +1,131 @@
>>
>>
>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - enum:
>>> +          - apple,t8103-mca
>>> +          - apple,t6000-mca
>>
>> Since it was brought up last time but I didn’t respond: the
>> nonalphabetical order is as the chips were introduced (and
>> matches other schemas).
> 
> Sure, just keep that order for future compatibles as well - so always
> put them according to verifiable time of market introduction...
> 
> This is very poor reason, instead of alphabetical order. Even worse
> reason is repeating wrong pattern just because someone else did it.

Ah, and the alphabetical order has clear advantage - reduces conflicts.
"Time" has clear disadvantage - increases conflicts.

So switch to alphabetical order.

Best regards,
Krzysztof
Martin Povišer Aug. 19, 2022, 2:14 p.m. UTC | #4
> On 19. 8. 2022, at 15:08, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> 
> On 19/08/2022 15:58, Martin Povišer wrote:
>> 
>>> On 19. 8. 2022, at 14:54, Martin Povišer <povik+lin@cutebit.org> wrote:


>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - enum:
>>> +          - apple,t8103-mca
>>> +          - apple,t6000-mca
>> 
>> Since it was brought up last time but I didn’t respond: the
>> nonalphabetical order is as the chips were introduced (and
>> matches other schemas).
> 
> Sure, just keep that order for future compatibles as well - so always
> put them according to verifiable time of market introduction...
> 
> This is very poor reason, instead of alphabetical order. Even worse
> reason is repeating wrong pattern just because someone else did it.
> 
> Best regards,
> Krzysztof
> 

I don’t see it nearly as clear-cut. Adding to the end seems pretty
foolproof too, but OK, next submission will have it alphabet. ordered.

Best,
Martin
Krzysztof Kozlowski Aug. 19, 2022, 2:17 p.m. UTC | #5
On 19/08/2022 17:14, Martin Povišer wrote:
>>> Since it was brought up last time but I didn’t respond: the
>>> nonalphabetical order is as the chips were introduced (and
>>> matches other schemas).
>>
>> Sure, just keep that order for future compatibles as well - so always
>> put them according to verifiable time of market introduction...
>>
>> This is very poor reason, instead of alphabetical order. Even worse
>> reason is repeating wrong pattern just because someone else did it.
>>
>> Best regards,
>> Krzysztof
>>
> 
> I don’t see it nearly as clear-cut. Adding to the end seems pretty
> foolproof too, but OK, next submission will have it alphabet. ordered.

The concept is the same everywhere, be it Kconfig, Makefile or other
lists. If everyone adds at the end, you increase the chances of
conflicts. Having alphabetical order usually means simultaneous edits
will happen in different places.


Best regards,
Krzysztof
Rob Herring Aug. 22, 2022, 6:59 p.m. UTC | #6
On Fri, Aug 19, 2022 at 05:17:17PM +0300, Krzysztof Kozlowski wrote:
> On 19/08/2022 17:14, Martin Povišer wrote:
> >>> Since it was brought up last time but I didn’t respond: the
> >>> nonalphabetical order is as the chips were introduced (and
> >>> matches other schemas).
> >>
> >> Sure, just keep that order for future compatibles as well - so always
> >> put them according to verifiable time of market introduction...
> >>
> >> This is very poor reason, instead of alphabetical order. Even worse
> >> reason is repeating wrong pattern just because someone else did it.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> > 
> > I don’t see it nearly as clear-cut. Adding to the end seems pretty
> > foolproof too, but OK, next submission will have it alphabet. ordered.
> 
> The concept is the same everywhere, be it Kconfig, Makefile or other
> lists. If everyone adds at the end, you increase the chances of
> conflicts. Having alphabetical order usually means simultaneous edits
> will happen in different places.

The difference for those cases is there is 0 control of when things are 
added with the source being all independent (different companies). For 
these, it's all one platform family and there's limits as to when one 
source can produce new entries.

I'd kind of like to know timeline order, but alphabetical is the only 
thing we can ever check easily and possibly automate (hint). 

Rob
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/sound/apple,mca.yaml b/Documentation/devicetree/bindings/sound/apple,mca.yaml
new file mode 100644
index 000000000000..7b4f348c2be3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/apple,mca.yaml
@@ -0,0 +1,131 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/apple,mca.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple MCA I2S transceiver
+
+description: |
+  MCA is an I2S transceiver peripheral found on M1 and other Apple chips. It is
+  composed of a number of identical clusters which can operate independently
+  or in an interlinked fashion. Up to 6 clusters have been seen on an MCA.
+
+maintainers:
+  - Martin Povišer <povik+lin@cutebit.org>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - apple,t8103-mca
+          - apple,t6000-mca
+      - const: apple,mca
+
+  reg:
+    items:
+      - description: Register region of the MCA clusters proper
+      - description: Register region of the DMA glue and its FIFOs
+
+  interrupts:
+    minItems: 4
+    maxItems: 6
+    description:
+      One interrupt per each cluster
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  dmas:
+    minItems: 16
+    maxItems: 24
+    description:
+      DMA channels corresponding to the SERDES units in the peripheral. They are
+      listed in groups of four per cluster, and within the group they are given
+      as associated to the TXA, RXA, TXB, RXB units.
+
+  dma-names:
+    minItems: 16
+    items:
+      - const: tx0a
+      - const: rx0a
+      - const: tx0b
+      - const: rx0b
+      - const: tx1a
+      - const: rx1a
+      - const: tx1b
+      - const: rx1b
+      - const: tx2a
+      - const: rx2a
+      - const: tx2b
+      - const: rx2b
+      - const: tx3a
+      - const: rx3a
+      - const: tx3b
+      - const: rx3b
+      - const: tx4a
+      - const: rx4a
+      - const: tx4b
+      - const: rx4b
+      - const: tx5a
+      - const: rx5a
+      - const: tx5b
+      - const: rx5b
+    description: |
+      Names for the DMA channels: 'tx'/'rx', then cluster number, then 'a'/'b'
+      based on the associated SERDES unit.
+
+  clocks:
+    minItems: 4
+    maxItems: 6
+    description:
+      Clusters' input reference clock.
+
+  resets:
+    maxItems: 1
+
+  power-domains:
+    minItems: 5
+    maxItems: 7
+    description:
+      First a general power domain for register access, then the power
+      domains of individual clusters for their operation.
+
+  '#sound-dai-cells':
+    const: 1
+
+required:
+  - compatible
+  - reg
+  - dmas
+  - dma-names
+  - clocks
+  - power-domains
+  - '#sound-dai-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    mca: i2s@9b600000 {
+      compatible = "apple,t6000-mca", "apple,mca";
+      reg = <0x9b600000 0x10000>,
+            <0x9b200000 0x20000>;
+
+      clocks = <&nco 0>, <&nco 1>, <&nco 2>, <&nco 3>;
+      power-domains = <&ps_audio_p>, <&ps_mca0>, <&ps_mca1>,
+                      <&ps_mca2>, <&ps_mca3>;
+      dmas = <&admac 0>, <&admac 1>, <&admac 2>, <&admac 3>,
+             <&admac 4>, <&admac 5>, <&admac 6>, <&admac 7>,
+             <&admac 8>, <&admac 9>, <&admac 10>, <&admac 11>,
+             <&admac 12>, <&admac 13>, <&admac 14>, <&admac 15>;
+      dma-names = "tx0a", "rx0a", "tx0b", "rx0b",
+                  "tx1a", "rx1a", "tx1b", "rx1b",
+                  "tx2a", "rx2a", "tx2b", "rx2b",
+                  "tx3a", "rx3a", "tx3b", "rx3b";
+
+      #sound-dai-cells = <1>;
+    };