topology1: SoundWire/HDAudio: add headphone deep buffer support

[plbossart]

This PR splits the headphone pipeline in two parts (host and dai-mixer) and adds a deep-buffer path.

Edit: this works fine now that I used pipeline indices larger for the FEs than the BE. Thanks @ranj063 for the hint. The topology now looks like this:

[lgirdwood]

SOFCI TEST

[lgirdwood]

@plbossart some failures on TGL, retesting to rule out CI.

[plbossart]

Oh man, it looks like this exposes a real bad kernel bug

https://sof-ci.sh.intel.com/#/result/planresultdetail/5800?model=CML_RVP_SDW&testcase=multiple-pause-resume-5

[  622.335069] kernel: sdw_enable_stream: subdevice #0-Playback: inconsistent state state 3
[  622.335074] kernel:  SDW1-Playback: sdw_trigger trigger 1 failed: -22
[  622.335077] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  622.336343] kernel:  Jack Out DeepBuffer: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  622.336346] kernel:  Jack Out DeepBuffer: ASoC: trigger FE cmd: 1 failed: -22
[  622.336347] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  622.336351] kernel:  SDW1-Playback: sdw_trigger trigger 3 failed: -22
[  622.336353] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  622.336356] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  622.336358] kernel:  Jack Out: ASoC: trigger FE cmd: 3 failed: -22
[  622.943300] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  622.943327] kernel:  SDW1-Playback: sdw_trigger trigger 3 failed: -22
[  622.943342] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  622.943354] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  622.943364] kernel:  Jack Out: ASoC: trigger FE cmd: 3 failed: -22
[  622.943886] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  622.943901] kernel:  SDW1-Playback: sdw_trigger trigger 3 failed: -22
[  622.943912] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  622.943923] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  622.943933] kernel:  Jack Out: ASoC: trigger FE cmd: 3 failed: -22
[  623.551438] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  623.551466] kernel:  SDW1-Playback: sdw_trigger trigger 3 failed: -22
[  623.551480] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  623.551491] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  623.551501] kernel:  Jack Out: ASoC: trigger FE cmd: 3 failed: -22
[  623.552131] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  623.552151] kernel:  SDW1-Playback: sdw_trigger trigger 3 failed: -22
[  623.552164] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  623.552175] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  623.552185] kernel:  Jack Out: ASoC: trigger FE cmd: 3 failed: -22
[  623.956355] kernel: sdw_disable_stream: subdevice #0-Playback: inconsistent state state 4
[  623.956381] kernel:  SDW1-Playback: sdw_trigger trigger 0 failed: -22
[  623.956394] kernel:  SDW1-Playback: ASoC: error at soc_link_trigger on SDW1-Playback: -22
[  623.956405] kernel:  Jack Out: ASoC: dpcm_be_dai_trigger() failed at SDW1-Playback (-22)
[  623.956415] kernel:  Jack Out: ASoC: trigger FE cmd: 0 failed: -22

@bardliao @RanderWang FYI

[plbossart]

I can reproduce the issue on CML SKU 09C6

TPLG=/lib/firmware/intel/sof-tplg/sof-cml-rt711-rt1308-mono-rt715.tplg  ~/sof-test/test-case/multiple-pause-resume.sh -r 5
[  325.564658] kernel: sdw_enable_stream: subdevice #0-Playback: inconsistent state state 3

Also failure on

TPLG=/lib/firmware/intel/sof-tplg/sof-cml-rt711-rt1308-mono-rt715.tplg  ~/sof-test/test-case/multiple-pipeline.sh -f p
2021-08-12 23:42:32 UTC [INFO] Testing: Jack Out [hw:0,0]
2021-08-12 23:42:32 UTC [COMMAND] aplay   -D hw:0,0 -c 2 -r 48000 -f S16_LE /dev/zero -q
2021-08-12 23:42:32 UTC [INFO] Testing: Jack Out DeepBuffer [hw:0,31]
2021-08-12 23:42:32 UTC [COMMAND] aplay   -D hw:0,31 -c 2 -r 48000 -f S16_LE /dev/zero -q
2021-08-12 23:42:32 UTC [INFO] Testing: Speaker [hw:0,2]
2021-08-12 23:42:32 UTC [COMMAND] aplay   -D hw:0,2 -c 2 -r 48000 -f S16_LE /dev/zero -q
2021-08-12 23:42:32 UTC [INFO] Testing: HDMI 1 [hw:0,5]
2021-08-12 23:42:32 UTC [INFO] wait 0.5s for aplay_opts()
2021-08-12 23:42:32 UTC [COMMAND] aplay   -D hw:0,5 -c 2 -r 48000 -f S16_LE /dev/zero -q
2021-08-12 23:42:32 UTC [INFO] checking pipeline status
2021-08-12 23:42:32 UTC [INFO] Letting playback/capture run for 5s
aplay: pcm_write:2086: write error: Input/output error
aplay: pcm_write:2086: write error: Input/output error
2021-08-12 23:42:37 UTC [INFO] checking pipeline status again
2021-08-12 23:42:37 UTC [ERROR] Running process count is 2, but 4 is expected

[plbossart]

It looks like the BE dailink is triggered twice

SDW_STREAM_ENABLED = 3,
kernel: sdw_enable_stream: subdevice #0-Playback: inconsistent state state 3

This means the dailink/stream is already triggered/enabled and we try to trigger it again?

[plbossart]

with this diff

diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c
index dde94e256a5b..e7835047e1b8 100644
--- a/sound/soc/intel/boards/sof_sdw.c
+++ b/sound/soc/intel/boards/sof_sdw.c
@@ -312,12 +312,14 @@ int sdw_trigger(struct snd_pcm_substream *substream, int cmd)
        case SNDRV_PCM_TRIGGER_START:
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
        case SNDRV_PCM_TRIGGER_RESUME:
+               dev_err(rtd->dev, "enabling stream for DAI %s", dai->name);
                ret = sdw_enable_stream(sdw_stream);
                break;
 
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
        case SNDRV_PCM_TRIGGER_SUSPEND:
        case SNDRV_PCM_TRIGGER_STOP:
+               dev_err(rtd->dev, "disabling stream for DAI %s", dai->name);
                ret = sdw_disable_stream(sdw_stream);
                break;
        default:

the result is confirmed: something's not correct with a mixer topology.

[   38.655432] kernel:  SDW0-Playback: enabling stream for DAI SDW0 Pin2
[   38.655675] kernel:  SDW0-Playback: enabling stream for DAI SDW0 Pin2
[   38.656435] kernel: sdw_enable_stream: subdevice #0-Playback: inconsistent state state 3

@bardliao I am running out of time for today, any idea why this might be happening?

[lgirdwood]

@plbossart @bardliao could there be a duplicate path in the topology that causes triggering twice ? or two different widgets that use the same DAI ?

[bardliao]

@plbossart @bardliao could there be a duplicate path in the topology that causes triggering twice ? or two different widgets that use the same DAI ?

Yes, I am also thinking are there two different widgets that use the same DAI. I am trying to figure it out.

[bardliao]

@plbossart It looks like a timing issue.
Both PCM 0 and 31 use DAI SDW1 Pin2, I can't reproduce it if I run aplay -D hw:0,0 and -D hw:0,31 manually.
But it is very easy to reproduce it if I run the test.txt script.
Ideally sdw_trigger will not be triggered again when the second pcm is opened.
But look like sdw_trigger will be triggered again if the second pcm is opening when the first pcm is not marked as opened yet.
Note that the first and second pcm here should use the same BE dai.
I don't know the mechanism yet, but my intuition tell me that the above inference is true.

[bardliao]

@plbossart It looks like a timing issue.
Both PCM 0 and 31 use DAI SDW1 Pin2, I can't reproduce it if I run aplay -D hw:0,0 and -D hw:0,31 manually.
But it is very easy to reproduce it if I run the test.txt script.
Ideally sdw_trigger will not be triggered again when the second pcm is opened.
But look like sdw_trigger will be triggered again if the second pcm is opening when the first pcm is not marked as opened yet.
Note that the first and second pcm here should use the same BE dai.
I don't know the mechanism yet, but my intuition tell me that the above inference is true.

@plbossart See dpcm_be_dai_trigger
be->dpcm[stream].state will be set to SND_SOC_DPCM_STATE_START after soc_pcm_trigger(be_substream, cmd); is done. L2027
So the issue happens when the 2nd PCM is starting during soc_pcm_trigger(be_substream, cmd); is running.

[plbossart]

@plbossart It looks like a timing issue.
Both PCM 0 and 31 use DAI SDW1 Pin2, I can't reproduce it if I run aplay -D hw:0,0 and -D hw:0,31 manually.
But it is very easy to reproduce it if I run the test.txt script.
Ideally sdw_trigger will not be triggered again when the second pcm is opened.
But look like sdw_trigger will be triggered again if the second pcm is opening when the first pcm is not marked as opened yet.
Note that the first and second pcm here should use the same BE dai.
I don't know the mechanism yet, but my intuition tell me that the above inference is true.

@plbossart See dpcm_be_dai_trigger
be->dpcm[stream].state will be set to SND_SOC_DPCM_STATE_START after soc_pcm_trigger(be_substream, cmd); is done. L2027
So the issue happens when the 2nd PCM is starting during soc_pcm_trigger(be_substream, cmd); is running.

Phew, this doesn't look good, are we missing a mutex somewhere then?

[RanderWang]

@plbossart It looks like a timing issue.
Both PCM 0 and 31 use DAI SDW1 Pin2, I can't reproduce it if I run aplay -D hw:0,0 and -D hw:0,31 manually.
But it is very easy to reproduce it if I run the test.txt script.
Ideally sdw_trigger will not be triggered again when the second pcm is opened.
But look like sdw_trigger will be triggered again if the second pcm is opening when the first pcm is not marked as opened yet.
Note that the first and second pcm here should use the same BE dai.
I don't know the mechanism yet, but my intuition tell me that the above inference is true.

@plbossart See dpcm_be_dai_trigger
be->dpcm[stream].state will be set to SND_SOC_DPCM_STATE_START after soc_pcm_trigger(be_substream, cmd); is done. L2027
So the issue happens when the 2nd PCM is starting during soc_pcm_trigger(be_substream, cmd); is running.

Phew, this doesn't look good, are we missing a mutex somewhere then?

@ranj063 for dynamic pipeline https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/sof-audio.c#L180, do we need to protect this use_count ? this can result such issue.

[plbossart]

@marc-hb I added your change and bumped the version required to 5.19, turns out we were missing patches that were only sent upstream in this cycle.

@lgirdwood this should be good to go if Marc approves.

[marc-hb]

The CMake logic looks good to me now (but that's not the important bit)

[marc-hb]

The failures in https://sof-ci.01.org/sofpr/PR4611/build88/devicetest/ seem topology-related, so that's worrying.

[plbossart]

looks like a git rebase issue, this makes no sense.

PCM_PLAYBACK_ADD(HDA Analog Deep Buffer, 31, PIPELINE_PCM_31)
ifdef(`DEEP_BUFFER',
`
PCM_DUPLEX_ADD(HDA Digital, 1, PIPELINE_PCM_3, PIPELINE_PCM_4)
'
)

[plbossart]

looks like a git rebase issue, this makes no sense.

PCM_PLAYBACK_ADD(HDA Analog Deep Buffer, 31, PIPELINE_PCM_31)
ifdef(`DEEP_BUFFER',
`
PCM_DUPLEX_ADD(HDA Digital, 1, PIPELINE_PCM_3, PIPELINE_PCM_4)
'
)

Corrected that blatant mistake - collision between two PRs. Tested on UpExtreme w/ and w/o deep-buffer

[marc-hb]

https://sof-ci.01.org/sofpr/PR4611/build90/devicetest/ has 2 instances of #5352, one rtcwake timeout, one BYT crash and one device not available. Routine.