Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASoC: SOF: ipc4-topology: Fix ChainDMA DMA Link ID handling during xrun #5119

Conversation

ujfalusi
Copy link
Collaborator

Hi,

Recent fixes for xrun (pending_stop) caused a regression on xrun handling of ChainDMA by uncovering two bugs related to how the DMA Link ID is handled and causing firmware crash under special circumstances.
The bugs will result loosing the DMA Link ID for the stream which experienced an xrun.

The first patch is a fix for a code move, but the actual bug was introduced by the same commit as the second patch is fixing, we need to create a new patch out from the first one for kernel versions prior to 6.9.

Fixes: #5116

@ujfalusi
Copy link
Collaborator Author

The patch which actually triggers the issue is new for 6.10:
ebd3b3014eeb ("ASoC: SOF: pcm: reset all PCM sources in case of xruns")

@ujfalusi
Copy link
Collaborator Author

to reproduce the issue (on soundwire device):

aplay -Dhw:0,0 -c2 -r48000 -fS16_LE /dev/zero -d 120 &
sleep 0.5; aplay -Dhw:0,2 -c2 -r48000 -fS16_LE /dev/zero -d 120 &
sleep 1; aplay -Dhw:0,5 -c8 -r48000 -fS32_LE /dev/zero -d 120 &
sleep 1.5; aplay -Dhw:0,6 -c8 -r48000 -fS32_LE /dev/zero -d 120 &
sleep 2; aplay -Dhw:0,7 -c8 -r48000 -fS32_LE /dev/zero -d 120 &
sleep 2.5; aplay -Dhw:0,31 -c2 -r48000 -fS16_LE /dev/zero -d 120 &

Kill the second HDMI playback:

pgrep -f "aplay -Dhw:0,6" | xargs kill -9

Start it again:

aplay -Dhw:0,6 -c8 -r48000 -fS32_LE /dev/zero -d 120

Press <CTRL+z> to freeze aplay, then type fg to bring it back. This will trigger an xrun.

Note: Likely only two aplay to HDMI is adequate.

Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Impressive fixes @ujfalusi

I can't believe we've had this forever...

But one of the changes looks weird, can you take a look?

sound/soc/sof/ipc4-topology.c Outdated Show resolved Hide resolved
sound/soc/sof/ipc4-topology.c Show resolved Hide resolved
@ujfalusi ujfalusi force-pushed the peter/sof/pr/chaindma_dmalinkid_fix_01 branch from 1016f12 to 20e8ef5 Compare July 23, 2024 10:18
…hainDMA

The DMA Link ID is only valid in snd_sof_dai_config_data when the
dai_config is called with HW_PARAMS.

The commit that this patch fixes is actually moved a code section without
changing it, the same bug exists in the original code, needing different
patch to kernel prior to 6.9 kernels.

Cc: stable@vger.kernel.org
Fixes: 3858464 ("ASoC: SOF: ipc4-topology: change chain_dma handling in dai_config")
Link: thesofproject#5116
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
…prepare

The DMA Link ID is set to the IPC message's primary during dai_config,
which is only during hw_params.
During xrun handling the hw_params is not called and the DMA Link ID
information will be lost.

All other fields in the message expected to be 0 for re-configuration, only
the DMA Link ID needs to be preserved and the in case of repeated
dai_config, it is correctly updated (masked and then set).

Cc: stable@vger.kernel.org
Fixes: ca5ce0c ("ASoC: SOF: ipc4/intel: Add support for chained DMA")
Link: thesofproject#5116
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
@ujfalusi
Copy link
Collaborator Author

Changes since v1:

  • Drop the masking of DMA link ID on host side in patch 2

@plbossart plbossart merged commit 1958a09 into thesofproject:topic/sof-dev Jul 23, 2024
12 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MTL: DSP panic with firmware 2.10.1
4 participants