Repository navigation
[BUG] DSP panic when using SSP0 on BYT #1937
Description
Describe the bug
For BYT-CR, we need to use SSP0 instead of SSP2. A tentative kernel patch is suggested here:
thesofproject/linux#1312
The PR generates a DSP panic, which can be reproduced with the regular kernel with partial changes to the topology.
It's likely that I don't fully get the topology changes needed, but regardless a DSP panic is a really bad thing ...
To Reproduce
use SOF master for kernel and firmware
kernel: 5edcfdf
firmware: 40bf5e0
compile the kernel in nocodec mode with the attached config
sof-dev-defconfig.txt
boot and modprobe snd-sof-acpi, then play on hw:0,0
Then add the attached diff, which completely replaces the use of SSP2 by SSP0
nocodec_ssp0_ok.diff.txt
Try with this change, there should be no issue
Then revert the changes, and apply the diff
nocodec_ssp0_nok.diff.txt
That generates a DSP panic, see log attached
dmesg_ssp0_dsp_panic.log
Steps to reproduce the behavior: (e.g. list commands or actions used to reproduce the bug)
Reproduction Rate
100%
Expected behavior
Error reported with no DSP panic
Impact
DSP panic -> P1 in my book.
Environment
-
Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
-
Name of the topology file
- Topology: sof-byt-nocodec
-
Name of the platform(s) on which the bug is observed.
- Platform: baytrail
Screenshots or console output
no sof-logger output available
Activity
plbossart commentedon Oct 14, 2019
@ranj063 could you take a look at the topology file changes to see if there is anything obvious that should be fixed?
tlauda commentedon Oct 15, 2019
@plbossart Could you check with #1942? It happened because DAI config has been sent with the wrong dai index, so the DMA channel stayed as NULL.
plbossart commentedon Oct 15, 2019
@tlauda PR #1942 does improve things, I don't get a DSP panic but a regular IPC error.
now I need to figure out how to replace SSP2 by SSP0, which is about to test my understanding of topology stuff (or lack thereof rather).
ranj063 commentedon Oct 15, 2019
@plbossart the topology changes look good. Im not sure why you're seeing this error. I had a similar error on my BYT this morning that got resolved by updating my FW with master
tlauda commentedon Oct 15, 2019
@plbossart As I already mentioned, you're getting this error because you are running the stream without previously configuring SSP 0 with DAI config. I suspect that this is the reason:
Wild guess, but maybe the second number is the actual dai index?
tlauda commentedon Oct 15, 2019
Edit: To be precise, you're sending dai config to the dai, which doesn't exist.
plbossart commentedon Oct 15, 2019
no, the first number is definitively the DAI index, and the second the dai link index.
the error does not happen while loading the topology but when playing audio. I believe I am sending the SSP0 index during the IPC_DAI_CONFIG, but I am not sure what happens during the hw_params (can't figure out how the DAI IPC happens).
There are additional issues with the topology, doing a blind change for SSP2->SSP0 isn't going to work I am afraid, there are a couple of shortcuts between DAI and DAI-links.
tlauda commentedon Oct 16, 2019
@plbossart You're changing dai index just in DAI_CONFIG but not in DAI_ADD macros. Basically you are configuring SSP 0, but you have DAI components connected to SSP 2. The reason why it throws an error on playback is because on BYT and CHT all the SSPs are probed on platform boot, so when DAI config IPC is sent it configures the right port. However FW doesn't return an error, when DAI component connected to this IPC is not found.
tlauda commentedon Oct 16, 2019
@plbossart Try #1951. It should return an error on dai config.
tlauda commentedon Oct 17, 2019
@plbossart Can we close the issue?
plbossart commentedon Oct 17, 2019
yep, thanks for the support!