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
