Re: [PATCH v2 09/11] ASoC: dt-bindings: mediatek,mt8196-afe: add audio AFE document

From: Krzysztof Kozlowski
Date: Mon Apr 07 2025 - 09:10:07 EST


On 07/04/2025 14:06, Darren.Ye wrote:
> From: Darren Ye <darren.ye@xxxxxxxxxxxx>
>
> Add mt8196 audio AFE document.
>
> Signed-off-by: Darren Ye <darren.ye@xxxxxxxxxxxx>
> ---
> .../bindings/sound/mediatek,mt8196-afe.yaml | 233 ++++++++++++++++++

Bindings are before their users. Order your patches correctly (see DT
submitting patches).

> 1 file changed, 233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt8196-afe.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8196-afe.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8196-afe.yaml
> new file mode 100644
> index 000000000000..44f8847b13a8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8196-afe.yaml

Filename matching compatible.


> @@ -0,0 +1,233 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/mediatek,mt8196-afe.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Audio Front End PCM controller for MT8196
> +
> +maintainers:
> + - Darren Ye <darren.ye@xxxxxxxxxxxx>
> +
> +properties:
> + compatible:
> + const: mediatek,mt8196-afe-pcm
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1

Blank line

> + memory-region:
> + maxItems: 1
> + description: |
> + Shared memory region for AFE memif. A "shared-dma-pool".
> + See dtschema reserved-memory/shared-dma-pool.yaml for details.

Drop description

Blank line

> + mediatek,cksys:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the mediatek clk systemd controller

For what purpose? this should be answered here. Anyway you clocks for
handling clocks of clk controller.

> +
> + mediatek,vlpcksys:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the mediatek vlpcksys controller

Blank line. For what purpose?

> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: audio hopping clock gate
> + - description: audio f26m clock gate
> + - description: audio apll1 clock gate
> + - description: audio apll2 clock gate
> + - description: audio apll1 tuner gate
> + - description: audio apll2 tuner gate
> + - description: mux for audio vlp int
> + - description: mux for audio vlp engen1
> + - description: mux for audio vlp engen2
> + - description: mux for audio h
> + - description: vlp clock 26m
> + - description: audio mainpll divide 4
> + - description: mux for audio apll1
> + - description: audio apll1
> + - description: mux for audio apll2
> + - description: audio apll2
> + - description: audio apll1 divide 4
> + - description: audio apll2 divide 4
> + - description: mux for i2sin0 mck
> + - description: mux for i2sin1 mck
> + - description: mux for fmi2s mck
> + - description: mux for tdmout mck
> + - description: auido apll12 divide for i2sin0
> + - description: auido apll12 divide for i2sin1
> + - description: auido apll12 divide for fmi2s
> + - description: auido apll12 divide for tdmout mck
> + - description: auido apll12 divide for tdmout bck
> + - description: audio adsp clk
> + - description: 26m clock

Do not come with entirely different ordering than existing variants.

> +
> + clock-names:
> + items:
> + - const: aud_hopping_clk

Look how this is called in upstream.

> + - const: aud_f26m_clk
> + - const: aud_apll1_clk
> + - const: aud_apll2_clk
> + - const: aud_apll_tuner1_clk
> + - const: aud_apll_tuner2_clk
> + - const: vlp_mux_audio_int
> + - const: vlp_mux_aud_eng1
> + - const: vlp_mux_aud_eng2
> + - const: vlp_mux_audio_h
> + - const: vlp_clk26m_clk
> + - const: ck_mainpll_d4_d4
> + - const: ck_mux_aud_1
> + - const: ck_apll1_ck
> + - const: ck_mux_aud_2
> + - const: ck_apll2_ck
> + - const: ck_apll1_d4
> + - const: ck_apll2_d4
> + - const: ck_i2sin0_m_sel
> + - const: ck_i2sin1_m_sel
> + - const: ck_fmi2s_m_sel
> + - const: ck_tdmout_m_sel
> + - const: ck_apll12_div_i2sin0
> + - const: ck_apll12_div_i2sin1
> + - const: ck_apll12_div_fmi2s
> + - const: ck_apll12_div_tdmout_m
> + - const: ck_apll12_div_tdmout_b
> + - const: ck_adsp_sel
> + - const: ck_clk26m_clk

The same.

> +
> + mediatek,etdm4-out-ch:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Number of ETDM4 output channels.
> + minimum: 1
> + maximum: 8
> +
> + mediatek,etdm4-in-ch:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Number of ETDM4 input channels.
> + minimum: 1
> + maximum: 8

Why is this binding so different than existing ones? I expect uniformity
not rework of all properties every time you upstream new device.

> +
> + mediatek,etdm4-out-sync:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + ETDM4 output and input enable synchronization.
> + enum:
> + - 0 # Enable controlled by itself
> + - 1 # Enable synchronization with ETDM4 input.
> +
> + mediatek,etdm4-in-sync:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + ETDM4 input and outpuot enable synchronization.
> + enum:
> + - 0 # Enable controlled by itself
> + - 1 # Enable synchronization with ETDM4 output.
> +
> +
> +

Hm? But why? One blank line is enough.

> + mediatek,etdm4-ip-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: ETDM IP mode.
> + enum:
> + - 0 # One ip multi-ch mode
> + - 1 # Multi-ip 2ch mode
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - mediatek,cksys
> + - mediatek,vlpcksys
> + - power-domains
> + - memory-region
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + afe: mt8196-afe-pcm@1a110000 {

Look at other bindings.

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation


Best regards,
Krzysztof