Hi Rob
On Wed, Mar 10, 2021 at 10:49 AM Rob Herring robh@kernel.org wrote:
On Mon, Mar 08, 2021 at 09:22:27PM +0800, Shengjiu Wang wrote:
fsl_rpmsg cpu dai driver is driver for rpmsg audio, which is mainly used
Bindings describe h/w blocks, not drivers.
I will modify the descriptions. but here it is a virtual device. the mapping in real h/w is cortex M core, Cortex M core controls the SAI, DMA interface. What we see from Linux side is a audio service through rpmsg channel.
for getting the user's configuration from device tree and configure the clocks which is used by Cortex-M core. So in this document define the needed property.
Signed-off-by: Shengjiu Wang shengjiu.wang@nxp.com
.../devicetree/bindings/sound/fsl,rpmsg.yaml | 118 ++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml new file mode 100644 index 000000000000..5731c1fbc0a6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,rpmsg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml#
+title: NXP Audio RPMSG CPU DAI Controller
+maintainers:
- Shengjiu Wang shengjiu.wang@nxp.com
+description: |
- fsl_rpmsg cpu dai driver is virtual driver for rpmsg audio, which doesn't
- touch hardware. It is mainly used for getting the user's configuration
- from device tree and configure the clocks which is used by Cortex-M core.
- So in this document define the needed property.
+properties:
- compatible:
- enum:
- fsl,imx7ulp-rpmsg
- fsl,imx8mn-rpmsg
- fsl,imx8mm-rpmsg
- fsl,imx8mp-rpmsg
- model:
- $ref: /schemas/types.yaml#/definitions/string
- description: User specified audio sound card name
- clocks:
- items:
- description: Peripheral clock for register access
- description: Master clock
- description: DMA clock for DMA register access
- description: Parent clock for multiple of 8kHz sample rates
- description: Parent clock for multiple of 11kHz sample rates
- minItems: 5
If this doesn't touch hardware, what are these clocks for?
When the cortex-M core support audio service, these clock needed prepared & enabled by ALSA driver.
You don't need 'minItems' unless it's less than the number of 'items'.
Ok, I will remove this minItems.
- clock-names:
- items:
- const: ipg
- const: mclk
- const: dma
- const: pll8k
- const: pll11k
- minItems: 5
- power-domains:
- maxItems: 1
- fsl,audioindex:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
- default: 0
- description: Instance index for sound card in
M core side, which share one rpmsg
channel.
We don't do indexes in DT. What's this numbering tied to?
I will remove it. it is not necessary
- fsl,version:
version of what?
This seems odd at best.
I will remove it. it is not necessary
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2]
You're going to update this with every new firmware version?
- default: 2
- description: The version of M core image, which is
to make driver compatible with different image.
- fsl,buffer-size:
- $ref: /schemas/types.yaml#/definitions/uint32
- description: pre allocate dma buffer size
How can you have DMA, this doesn't touch h/w?
The DMA is handled by M core image for sound playback and capture. we need to allocated buffer in Linux side. here just make the buffer size to be configurable.
- fsl,enable-lpa:
- $ref: /schemas/types.yaml#/definitions/flag
- description: enable low power audio path.
- fsl,rpmsg-out:
- $ref: /schemas/types.yaml#/definitions/flag
- description: |
This is a boolean property. If present, the transmitting function
will be enabled.
- fsl,rpmsg-in:
- $ref: /schemas/types.yaml#/definitions/flag
- description: |
This is a boolean property. If present, the receiving function
will be enabled.
- fsl,codec-type:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
- default: 0
- description: Sometimes the codec is registered by
driver not by the device tree, this items
can be used to distinguish codecs.
How does one decide what value to use?
I will add more description: 0: dummy codec 1: WM8960 codec 2: AK4497 codec
- audio-codec:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: The phandle of the audio codec
The codec is controlled from the Linux side?
yes.
- memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle
- description: phandle to the reserved memory nodes
+required:
- compatible
- fsl,audioindex
- fsl,version
- fsl,buffer-size
+additionalProperties: false
+examples:
- |
- rpmsg_audio: rpmsg_audio {
compatible = "fsl,imx8mn-rpmsg";
fsl,audioindex = <0> ;
fsl,version = <2>;
fsl,buffer-size = <0x6000000>;
fsl,enable-lpa;
How does this work? Don't you need somewhere to put the 'rpmsg' data?
The rpmsg data is not handled in this "rpmsg_audio" device, it is just to prepare the resource for rpmsg audio function, the clock, the memory the power...
The rpmsg data is handled in imx-pcm-rpmsg.c and imx-audio-rpmsg.c These devices is registered by imx remoteproc driver.
I will update this document in v5
Best regards Wang Shengjiu