Diff was removed by the server for this mailing list, inlining here.
My issue is that it's ESAI0 that supports both playback and capture, so I considered PCM_DUPLEX_ADD to be the correct function to use here. On a platform I will eventually add there will also be an ESAI1 so I cannot just have two DAI instances for ESAI0 (I hope it isn't necessary).
The kernel sends one IPC but SOF actually configures all the components, no matter what the direction, from a single IPC. So even if the kernel sends it separately SOF will actually send a failure response (due to reusing the same DMA channel) on the first send.
diff --git a/tools/topology/sof-imx8qxp-cs42888.m4 b/tools/topology/sof-imx8qxp-cs42888.m4 index 215921587..e1542b891 100644 --- a/tools/topology/sof-imx8qxp-cs42888.m4 +++ b/tools/topology/sof-imx8qxp-cs42888.m4 @@ -38,6 +38,13 @@ PIPELINE_PCM_ADD(sof/pipe-volume-playback.m4, 1000, 0, 0, 48000, 48000, 48000)
+# Low Latency capture pipeline 2 on PCM 0 using max 2 channels of s24le. +# Set 1000us deadline on core 0 with priority 0 +PIPELINE_PCM_ADD(sof/pipe-volume-capture.m4, + 2, 0, 2, s24le, + 1000, 0, 0, + 48000, 48000, 48000) + # # DAIs configuration # @@ -54,10 +61,19 @@ DAI_ADD(sof/pipe-dai-playback.m4, PIPELINE_SOURCE_1, 2, s24le, 1000, 0, 0)
+# capture DAI is ESAI0 using 2 periods +# Buffers use s24le format, with 48 frame per 1000us on core 0 with priority 0 +DAI_ADD(sof/pipe-dai-capture.m4, + 2, ESAI, 0, ESAI0-Codec, + PIPELINE_SINK_2, 2, s24le, + 1000, 0, 0) + # PCM Low Latency, id 0
dnl PCM_PLAYBACK_ADD(name, pcm_id, playback) -PCM_PLAYBACK_ADD(Port0, 0, PIPELINE_PCM_1) +dnl PCM_PLAYBACK_ADD(Port0, 0, PIPELINE_PCM_1) + +PCM_DUPLEX_ADD(Port0, 0, PIPELINE_PCM_1, PIPELINE_PCM_2)
dnl DAI_CONFIG(type, idx, link_id, name, esai_config) DAI_CONFIG(ESAI, 0, 0, ESAI0-Codec, @@ -66,3 +82,10 @@ DAI_CONFIG(ESAI, 0, 0, ESAI0-Codec, ESAI_CLOCK(fsync, 48000, codec_slave), ESAI_TDM(2, 32, 3, 3), ESAI_CONFIG_DATA(ESAI, 0, 0))) + +DAI_CONFIG(ESAI, 0, 1, ESAI0-Codec, + ESAI_CONFIG(I2S, ESAI_CLOCK(mclk, 49152000, codec_mclk_in), + ESAI_CLOCK(bclk, 3072000, codec_slave), + ESAI_CLOCK(fsync, 48000, codec_slave), + ESAI_TDM(2, 32, 3, 3), + ESAI_CONFIG_DATA(ESAI, 0, 0)))
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, November 7, 2019 5:43 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org; Lauda, Tomasz tomasz.lauda@intel.com; janusz.jankowski@linux.intel.com Subject: [EXT] Re: [Sound-open-firmware] How to figure out the direction when dai_config is called?
Caution: EXT Email
On 11/7/19 6:18 AM, Paul Olaru wrote:
On the i.MX platform, the SAI and ESAI DAIs require the direction (whether it's playback or capture) to be able to correctly decide which DMA channel is to be used (the channels differ between playback and capture). I have just made a simple modification to the pipeline to also have a record pipeline on the ESAI and I'm getting an error due to attempting to request channel 7 (Playback) twice. It seems that dai_config is called twice within the same IPC request (once for each instance of the DAI) and in both cases with the same direction too.
I vaguely recall the kernel sends the dai config for each direction. Ranjani might recall better than me...
What would be the best approach with this one?
I have attached the diff with my current attempt to adding that record pipeline. Perhaps something is wrong with that?
I don't see a diff, not sure if you forgot it or if the mail server removes it.