[Sound-open-firmware] How to figure out the direction when dai_config is called?
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.
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?
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.
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.
Resolved that one, I have taken the direction from the component data instead of the IPC. Now I'm getting another problem: the Dummy DMA (host DMA) driver receives negative values for the elems, and if I fail the configuration somehow I'm getting an IRQ storm (which may be related to never stopping the EDMA or could be something else, currently investigating). My question is why the size field in such a config (the dma_sg_elems) could contain -512?
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Paul Olaru Sent: Friday, November 8, 2019 11:47 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; sound-open-firmware@alsa-project.org; Lauda, Tomasz tomasz.lauda@intel.com; janusz.jankowski@linux.intel.com Subject: Re: [Sound-open-firmware] [EXT] Re: How to figure out the direction when dai_config is called?
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?
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. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...
I have investigated on this one and I believe the function `host_dma_get_split` is acting up.
I have added a few traces and noticed the following:
bytes = 0 local_elem->src=0x92c23d80 (in the buffer heap) local_elem->dest=0x960a1200 (external address, really the actual host buffer, managed by Linux) hd->source->current_end == hd->sink->current_end == 0x92c24080 (buffer heap).
The actual computation gives split_src = 0 and split_dst = 512. But 512 > bytes==0. Hence, configuration issues and the Dummy DMA driver (when it doesn't check for the validity of the size) triggers a freeze or panic due to the abnormal size.
host_dma_get_split is called from host_buffer_get_copy_bytes. Because of the irregularity mentioned above this function will return -512, which is simply assigned to the elem size.
What is wrong with this logic? Is the calculation from here wrong? Should I ignore it and instead ensure that EDMA always delivers bytes so that copy() isn't called with size 0? I believe this option will only cover up a real issue.
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Paul Olaru Sent: Friday, November 8, 2019 4:25 PM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; sound-open-firmware@alsa-project.org; Lauda, Tomasz tomasz.lauda@intel.com; janusz.jankowski@linux.intel.com Subject: Re: [Sound-open-firmware] [EXT] Re: How to figure out the direction when dai_config is called?
Caution: EXT Email
Resolved that one, I have taken the direction from the component data instead of the IPC. Now I'm getting another problem: the Dummy DMA (host DMA) driver receives negative values for the elems, and if I fail the configuration somehow I'm getting an IRQ storm (which may be related to never stopping the EDMA or could be something else, currently investigating). My question is why the size field in such a config (the dma_sg_elems) could contain -512?
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Paul Olaru Sent: Friday, November 8, 2019 11:47 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; sound-open-firmware@alsa-project.org; Lauda, Tomasz tomasz.lauda@intel.com; janusz.jankowski@linux.intel.com Subject: Re: [Sound-open-firmware] [EXT] Re: How to figure out the direction when dai_config is called?
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?
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. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al... _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...
participants (2)
-
Paul Olaru -
Pierre-Louis Bossart