[PATCH] ASoC: amd: renoir: restore two more registers during resume
Recently we found an issue about the suspend and resume. If dmic is recording the sound, and we run suspend and resume, after the resume, the dmic can't work well anymore. we need to close the app and reopen the app, then the dmic could record the sound again.
For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2 -r 48000 test.wav", then suspend and resume, after the system resume back, we speak to the dmic. then stop the arecord, use aplay to play the test.wav, we could hear the sound recorded after resume is weird, it is not what we speak to the dmic.
I found two registers are set in the dai_hw_params(), if the two registers are set in the resume() too, this issue could be fixed.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com --- sound/soc/amd/renoir/acp3x-pdm-dma.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/soc/amd/renoir/acp3x-pdm-dma.c b/sound/soc/amd/renoir/acp3x-pdm-dma.c index 623dfd3ea705..8acb0315a169 100644 --- a/sound/soc/amd/renoir/acp3x-pdm-dma.c +++ b/sound/soc/amd/renoir/acp3x-pdm-dma.c @@ -474,6 +474,11 @@ static int acp_pdm_resume(struct device *dev) rtd = runtime->private_data; period_bytes = frames_to_bytes(runtime, runtime->period_size); buffer_len = frames_to_bytes(runtime, runtime->buffer_size); + if (runtime->channels == TWO_CH) { + rn_writel(0x0 , rtd->acp_base + ACP_WOV_PDM_NO_OF_CHANNELS); + rn_writel(PDM_DECIMATION_FACTOR, rtd->acp_base + + ACP_WOV_PDM_DECIMATION_FACTOR); + } config_acp_dma(rtd, SNDRV_PCM_STREAM_CAPTURE); init_pdm_ring_buffer(MEM_WINDOW_START, buffer_len, period_bytes, adata->acp_base);
On 30/07/20 1:20 pm, Hui Wang wrote:
Recently we found an issue about the suspend and resume. If dmic is recording the sound, and we run suspend and resume, after the resume, the dmic can't work well anymore. we need to close the app and reopen the app, then the dmic could record the sound again.
For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2 -r 48000 test.wav", then suspend and resume, after the system resume back, we speak to the dmic. then stop the arecord, use aplay to play the test.wav, we could hear the sound recorded after resume is weird, it is not what we speak to the dmic.
I found two registers are set in the dai_hw_params(), if the two registers are set in the resume() too, this issue could be fixed.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com
sound/soc/amd/renoir/acp3x-pdm-dma.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/soc/amd/renoir/acp3x-pdm-dma.c b/sound/soc/amd/renoir/acp3x-pdm-dma.c index 623dfd3ea705..8acb0315a169 100644 --- a/sound/soc/amd/renoir/acp3x-pdm-dma.c +++ b/sound/soc/amd/renoir/acp3x-pdm-dma.c @@ -474,6 +474,11 @@ static int acp_pdm_resume(struct device *dev) rtd = runtime->private_data; period_bytes = frames_to_bytes(runtime, runtime->period_size); buffer_len = frames_to_bytes(runtime, runtime->buffer_size);
if (runtime->channels == TWO_CH) {rn_writel(0x0 , rtd->acp_base + ACP_WOV_PDM_NO_OF_CHANNELS);rn_writel(PDM_DECIMATION_FACTOR, rtd->acp_base +ACP_WOV_PDM_DECIMATION_FACTOR);}
Could you refactor the code. Remove this logic from resume callback Add this register sequence in acp_pdm_dai_trigger() callback before invoking start_pdm _dma() callback. Remove acp_pdm_dai_hw_params().
config_acp_dma(rtd, SNDRV_PCM_STREAM_CAPTURE); init_pdm_ring_buffer(MEM_WINDOW_START, buffer_len, period_bytes, adata->acp_base);
On 2020/7/30 下午8:02, Mukunda,Vijendar wrote:
On 30/07/20 1:20 pm, Hui Wang wrote:
Recently we found an issue about the suspend and resume. If dmic is recording the sound, and we run suspend and resume, after the resume, the dmic can't work well anymore. we need to close the app and reopen the app, then the dmic could record the sound again.
For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2 -r 48000 test.wav", then suspend and resume, after the system resume back, we speak to the dmic. then stop the arecord, use aplay to play the test.wav, we could hear the sound recorded after resume is weird, it is not what we speak to the dmic.
I found two registers are set in the dai_hw_params(), if the two registers are set in the resume() too, this issue could be fixed.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com
sound/soc/amd/renoir/acp3x-pdm-dma.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/soc/amd/renoir/acp3x-pdm-dma.c b/sound/soc/amd/renoir/acp3x-pdm-dma.c index 623dfd3ea705..8acb0315a169 100644 --- a/sound/soc/amd/renoir/acp3x-pdm-dma.c +++ b/sound/soc/amd/renoir/acp3x-pdm-dma.c @@ -474,6 +474,11 @@ static int acp_pdm_resume(struct device *dev) rtd = runtime->private_data; period_bytes = frames_to_bytes(runtime, runtime->period_size); buffer_len = frames_to_bytes(runtime, runtime->buffer_size); + if (runtime->channels == TWO_CH) { + rn_writel(0x0 , rtd->acp_base + ACP_WOV_PDM_NO_OF_CHANNELS); + rn_writel(PDM_DECIMATION_FACTOR, rtd->acp_base + + ACP_WOV_PDM_DECIMATION_FACTOR); + }
Could you refactor the code. Remove this logic from resume callback Add this register sequence in acp_pdm_dai_trigger() callback before invoking start_pdm _dma() callback. Remove acp_pdm_dai_hw_params().
OK, got it.
thx.
config_acp_dma(rtd, SNDRV_PCM_STREAM_CAPTURE); init_pdm_ring_buffer(MEM_WINDOW_START, buffer_len, period_bytes, adata->acp_base);
On Thu, 30 Jul 2020 15:50:20 +0800, Hui Wang wrote:
Recently we found an issue about the suspend and resume. If dmic is recording the sound, and we run suspend and resume, after the resume, the dmic can't work well anymore. we need to close the app and reopen the app, then the dmic could record the sound again.
For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2 -r 48000 test.wav", then suspend and resume, after the system resume back, we speak to the dmic. then stop the arecord, use aplay to play the test.wav, we could hear the sound recorded after resume is weird, it is not what we speak to the dmic.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: amd: renoir: restore two more registers during resume commit: ccff7bd468d5e0595176656a051ef67c01f01968
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (3)
-
Hui Wang -
Mark Brown -
Mukunda,Vijendar