could not access debugfs when DSP panic or IPC failed

[xiulipan]

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

linux/sound/soc/sof/debug.c

Line 64 in 2af9599

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.

[xiulipan]

@libinyang
Could you share the workaround to get etrace on UP2?

[mengdonglin]

@ranj063 This issue is observed when debugging thesofproject/sof#443 on UP2. But it should be a generic issue.

[keyonjie]

when DSP is panic, we should let reading trace debugFS entries(with old value at worst case) possible, let me try some fix to it.

[ranj063]

@Keyon agree with you. Let me know if you need help

[mengdonglin]

@keyonjie please check if thesofproject/sof#518 could improve the logger health for your debugging.

[xiulipan]

@keyonjie @ranj063
What about tplg load fail?
This will also make resume fail, right?
So we may also want the debugfs can be read or just disable pm when error happen.

[keyonjie]

@xiulipan why tplg load fail? we will not destroy the entry, so it should be still readable when resume fails.