When DSP panic or IPC failed. If we use sof-logger or rmbox we will see
sof-audio sof-audio: error: debugFS failed to resume -13
In dmesg.
Or if we want to access any debugfs exculde trace, the dmesg shows same thing and terminal refuse to open the file
sudo cat /sys/kernel/debug/sof/etrace
cat: /sys/kernel/debug/sof/etrace: Permission denied
Analysis:
trace and etrace used different read ops
For trace we used sof_dfsentry_read
static const struct file_operations sof_dfs_fops = {
.open = sof_dfsentry_open,
.read = sof_dfsentry_read,
.llseek = default_llseek,
};And the above dmesg is coming from
|
dev_err(sdev->dev, "error: debugFS failed to resume %d\n", |
So the guess is here, when DSP panic or IPC failed, how would our pm_runtime_get_sync pm_runtime_put behavior?
We may need some fallback handler for this case.
The debugfs is very valuable and critical for our debug when error happens. But now it could not work.
When DSP panic or IPC failed. If we use sof-logger or rmbox we will see
Or if we want to access any debugfs exculde
trace, the dmesg shows same thing and terminal refuse to open the fileAnalysis:
traceandetraceused different read opsFor trace we used
sof_dfsentry_readAnd the above dmesg is coming from
linux/sound/soc/sof/debug.c
Line 64 in 2af9599
So the guess is here, when DSP panic or IPC failed, how would our
pm_runtime_get_syncpm_runtime_putbehavior?We may need some fallback handler for this case.
The debugfs is very valuable and critical for our debug when error happens. But now it could not work.