On 17/04/2024 11:25, Shengjiu Wang wrote:
> Convert the fsl,ssi binding to YAML.
>
...
> +description:
> + Notes on fsl,playback-dma and fsl,capture-dma
> + On SOCs that have an SSI, specific DMA channels are hard-wired for playback
> + and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
> + playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
> + playback and DMA channel 3 for capture. The developer can choose which
> + DMA controller to use, but the channels themselves are hard-wired. The
> + purpose of these two properties is to represent this hardware design.
> +
> + The device tree nodes for the DMA channels that are referenced by
> + "fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
> + "fsl,ssi-dma-channel". The SOC-specific compatible string (e.g.
> + "fsl,mpc8610-dma-channel") can remain. If these nodes are left as
> + "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
> + drivers (fsldma) will attempt to use them, and it will conflict with the
> + sound drivers.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,imx50-ssi
> + - fsl,imx53-ssi
> + - enum:
> + - fsl,imx51-ssi
> + - enum:
> + - fsl,imx21-ssi
That's a mess... you cannot have enums as fallbacks.
> + - items:
> + - enum:
> + - fsl,imx25-ssi
> + - fsl,imx27-ssi
> + - fsl,imx35-ssi
> + - fsl,imx51-ssi
> + - fsl,imx6q-ssi
> + - fsl,imx6sl-ssi
> + - fsl,imx6sx-ssi
> + - enum:
> + - fsl,imx21-ssi
> + - fsl,imx51-ssi
> + - items:
> + - const: fsl,mpc8610-ssi
> +
> + cell-index:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2]
> + description: The SSI index
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + fsl,fifo-depth:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The number of elements in the transmit and receive FIFOs.
> + This number is the maximum allowed value for SFCSR[TFWM0].
> +
> + clocks:
> + items:
> + - description: The ipg clock for register access
> + - description: clock for SSI master mode
> + minItems: 1
> +
> + clock-names:
> + items:
> + - const: ipg
> + - const: baud
> + minItems: 1
> +
> + dmas:
> + oneOf:
> + - items:
> + - description: DMA controller phandle and request line for RX
> + - description: DMA controller phandle and request line for TX
> + - items:
> + - description: DMA controller phandle and request line for RX0
> + - description: DMA controller phandle and request line for TX0
> + - description: DMA controller phandle and request line for RX1
> + - description: DMA controller phandle and request line for TX1
> +
> + dma-names:
> + oneOf:
> + - items:
> + - const: rx
> + - const: tx
> + - items:
> + - const: rx0
> + - const: tx0
> + - const: rx1
> + - const: tx1
> +
> + codec-handle:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to a 'codec' node that defines an audio
> + codec connected to this SSI. This node is typically
> + a child of an I2C or other control node.
> +
> + fsl,fiq-stream-filter:
> + type: boolean
> + description:
> + Disabled DMA and use FIQ instead to filter the codec stream.
> + This is necessary for some boards where an incompatible codec
> + is connected to this SSI, e.g. on pca100 and pcm043.
> +
> + fsl,mode:
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ ac97-slave, ac97-master, i2s-slave, i2s-master,
> + lj-slave, lj-master, rj-slave, rj-master ]
> + description: |
> + "ac97-slave" - AC97 mode, SSI is clock slave
> + "ac97-master" - AC97 mode, SSI is clock master
> + "i2s-slave" - I2S mode, SSI is clock slave
> + "i2s-master" - I2S mode, SSI is clock master
> + "lj-slave" - Left justified mode, SSI is clock slave
> + "lj-master" - Left justified mode, SSI is clock master
> + "rj-slave" - Right justified mode, SSI is clock slave
> + "rj-master" - Right justified mode, SSI is clock master
> +
> + fsl,ssi-asynchronous:
> + type: boolean
> + description: If specified, the SSI is to be programmed in asynchronous
> + mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
> + all be connected to valid signals. In synchronous mode,
> + SRCK and SRFS are ignored. Asynchronous mode allows
> + playback and capture to use different sample sizes and
> + sample rates. Some drivers may require that SRCK and STCK
> + be connected together, and SRFS and STFS be connected
> + together. This would still allow different sample sizes,
> + but not different sample rates.
> +
> + fsl,playback-dma:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: Phandle to a node for the DMA channel to use for
> + playback of audio. This is typically dictated by SOC
> + design. Only used on Power Architecture.
> +
> + fsl,capture-dma:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: Phandle to a node for the DMA channel to use for
> + capture (recording) of audio. This is typically dictated
> + by SOC design. Only used on Power Architecture.
> +
> + "#sound-dai-cells":
> + const: 0
> + description: optional, some dts node didn't add it.
The question is: is this DAI or not?
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - fsl,fifo-depth
> +
> +unevaluatedProperties: false
This must be additionalProperties:false. Use example-schema as
reference... unless you want to reference dai-common.yaml, but then that
one is missing.
Best regards,
Krzysztof
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]
