Repository navigation
Failed to set DAI config for SSP4 on UP2 w/o codec #660
Description
Summary:
Failed to set DAI config for SSP4 on UP2 w/o codec.
This issue cannot be reproduced with the same kernel and the firmware on Nov. 26, so it seems to be a firmware regression.
sof-logger is empty. sof-logger -t log is attached below.
dmesg:
[ 3.973831] sof-audio sof-audio: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG
[ 3.973965] sof-audio sof-audio: ipc tx succeeded: 0x80010000: GLB_DAI_MSG: CONFIG
[ 3.973973] sof-audio sof-audio: tplg: config SSP3 fmt 0x4001 mclk 24576000 bclk 1536000 fclk 48000 width (16)16 slots 2 mclk id 0
[ 3.973992] sof-audio sof-audio: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG
[ 3.974121] sof-audio sof-audio: ipc tx succeeded: 0x80010000: GLB_DAI_MSG: CONFIG
[ 3.974132] sof-audio sof-audio: tplg: config SSP4 fmt 0x4001 mclk 24576000 bclk 1536000 fclk 48000 width (16)16 slots 2 mclk id 0
[ 3.974151] sof-audio sof-audio: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG
[ 3.974284] sof-audio sof-audio: error: ipc error for 0x80010000 size 0xc
[ 3.974298] sof-audio sof-audio: error: failed to set DAI config for SSP4
[ 3.974307] sof-audio sof-audio: ASoC: physical link loading failed
[ 3.974312] sof-audio sof-audio: error: tplg component load failed -5
[ 3.974326] sof-audio sof-audio: error: failed to load DSP topology -22
[ 3.974330] sof-audio sof-audio: ASoC: failed to probe component -22
[ 3.974353] sof-nocodec sof-nocodec: ASoC: failed to instantiate card -22
Test steps:
aplay -l
aplay: device_list:270: no soundcards found...
Test env:
sof master: e94a34f
kernel sof-dev: de1f57a
tplg: sof-apl-nocodec.tplg
Log:
dmesg.txt
logger-t.txt
config-4.19.0-unset-hda-link.txt
Activity
mengdonglin commentedon Dec 4, 2018
@markyang Could you help to locate the regression point?
For "This issue cannot be reproduced with the same kernel and the firmware on Nov. 26, so it seems to be a firmware regression." Is there any change on the topology file?
[-]Failed to set DAI config for SSP4 on UP2 w/t codec[/-][+]Failed to set DAI config for SSP4 on UP2 w/o codec[/+]mengdonglin commentedon Dec 4, 2018
@libinyang Please note debugging may be blocked by #662
mengdonglin commentedon Dec 5, 2018
#662 is solved by rebuilding rimage and so is not a blocker.
markyang commentedon Dec 5, 2018
@mengdonglin the same kernel and topology, only the firmware was changed.
libinyang commentedon Dec 6, 2018
This bug is caused by commit: 9bebdbf.
The root cause is dma channel is allocated statically now in 9bebdbf, which will cause dma channels are not enough for nocodec mode.
keyonjie commentedon Dec 6, 2018
@libinyang we require specific channel for hda-dma only, for i2s, we uses dw-dma for dai, where req_channel is actually ignored if it < max_channel.
mengdonglin commentedon Dec 7, 2018
@libinyang @RanderWang Could you help to clarify if "dma channel is allocated statically now in 9bebdbf" applies to both HD-A and SSP backend DAI and caused dw-dma channels are exhausted for SSP4?
libinyang commentedon Dec 7, 2018
Yes, the issue is because the channels are exhausted.
mengdonglin commentedon Dec 7, 2018
It seems this issue is blocked by current DMA channel application solution. So now APL cannot work in no codec mode without reducing pipelines in m4 topology.
@plbossart @lgirdwood May we revisit the implementation of dma channel allocation after submitting the v1 patches to upstream?
keyonjie commentedon Dec 7, 2018
the dmac1 unable to be used in current implementation, we need fix that.
mengdonglin commentedon Dec 7, 2018
@keyonjie Sounds good. Thanks for the root cause and there is no blocker now.
RanderWang commentedon Dec 7, 2018
this is not a bug。please refer to b30658d#diff-9f8de02ec82000817dd1a9bbccac158c
First dma channel is allocated at dai_new, then marcin moved it to dai_param. It is for HDA, not for I2S.
this topology should be failed before marcin's change.
libinyang commentedon Dec 7, 2018
OK. So what if we add a count for dma_get() as we certainly will call get channel if we get dma. If we have already got dma as many times as its channel number, we will use next dmac?
plbossart commentedon Dec 7, 2018
This thread is difficult to follow. Are we in agreement that
a) for APL+ there are 16 GP-DMA channels which can be used for SSP/DMIC, and those represent the worst-case we will ever have in terms of physical interfaces (max 2*6 SSPs + 4 DMIC). we are not in a case where we will be out of DMA channels and have to deal with dynamic allocation based on use cases.
b) the addition of HDAudio/iDISP has no bearing on nocodec topology, a different DMA is used
c) for BYT we have 3 SSP interfaces and the rest can be used for Front-ends. We will only run into DMA allocation issues if there are more than 10 Front-ends, an unlikely scenario.
d) for Broadwell, we only have 2 SSPs (actually one used), so we also don't have a real problem even with a single 8-ch DMA controller.
libinyang commentedon Dec 10, 2018
@plbossart
Yes, mostly you are right. The main problem is the sof code issue and a little other HW limitations.
sof code issue.
Currently SOF dma_get() will not check its sref and it only check num_channels_busy. However SOF code will call dma_get() for firstly for all components and then dma_channel_get() later. So we will always assign dmac0.
Patch lib: dma: simplify DMAC search and fix users to max channels #687 is trying to fix this issue.
HW limitation
a) on CHT, we may use 6 SSPs? If so, 6x2 will be occupied by ssp. And 1 channel for dma trace. So it only leaves 3 channels for host.
b) For all platforms, GPDMA can also be used in DSP memory-memory copy for some advanced usage to loadoff the DSP cpu workload. (Not sure we are using this feature or not). Also, GPDMA can be used for device-device communication. We didn't count them in. If we count all cases in, GPDMA may not be enough.
mengdonglin commentedon Dec 14, 2018
By commit 6c066d0, that commented out some pipelines in sof-apl-nocodec.tplg, this issue is gone but topology loading will fail because “failed to set DAI config for DMIC0” (similar reason?)
So closing this bug and will file a new bug to folllow up.
libinyang commentedon Dec 14, 2018
Although this bug is closed. I suggested we still keep an eye on it as the root cause is a potential issue.