SMP: power down cores only if all pipelines running on it have been stopped

[zhuyingjiang]

Currently implement of sof_widget_unload has a issue of powerdown the core immediately after the snd_soc_dapm_scheduler swidget is removed.
At least this need check if all the pipeline in the core are all removed.

[plbossart]

@zhuyingjiang your issue is borderline useless at this point without explanation, logs, context, etc. Please be more specific on what you are seeing and describe the effects

[ranj063]

@zhuyingjiang I think this is a valid issue. I am guessing you hit the issue during module unload.
And I think this is the root cause for all the ipc timeouts that we are seeing during module unload.

Basically, we should add a usage counter for the core and when a pipeline widget is unloaded, we need to decrement the core's usage counter. And only when it hits 0, we should power it down. Can you fix this please?

And also maybe we need to keep core 0 alive all the time until the call to snd_sof_dsp_remove() takes care of it.

[zhuyingjiang]

@ranj063 Yes, I can do that, but since I am now taking AL, the respond maybe slow.

[ranj063]

@zhuyingjiang no problem. ENjoy your vacation. I'll take care of it.

[plbossart]

On 1/25/19 6:56 PM, Ranjani Sridharan wrote: @zhuyingjiang <https://github.com/zhuyingjiang> I think this is a valid issue. I am guessing you hit the issue during module unload. And I think this is the root cause for all the ipc timeouts that we are seeing during module unload. Basically, we should add a usage counter for the core and when a pipeline widget is unloaded, we need to decrement the core's usage counter. And only when it hits 0, we should power it down. Can you fix this please?

I still don't get how we can even try to remove a module while it's being used? can someone provide a test script showing how to reproduce this?

…

[ranj063]

@plbossart On the up2 with Ubuntu installed and pulseaudio enabled, you will hit this issue with the sof_bootloop.sh on the very second iteration.

[plbossart]

On 1/28/19 1:02 PM, Ranjani Sridharan wrote: @plbossart <https://github.com/plbossart> On the up2 with Ubuntu installed and pulseaudio enabled, you will hit this issue with the sof_bootloop.sh on the very second iteration.

This is too system dependent, I don't have this problem on Ubilinux. and in some cases pulseaudio is only started if you use the UI, if you use SSH as root it's not started at all. Bottom line we need a script with aplay/speaker-test. When I try with the legacy driver on Up2 w/ speaker-test, I get this: root@ubilinux4:~# rmmod snd-hda-intel rmmod: ERROR: Module snd_hda_intel is in use If I look at the following sysfs file, one can see clearly the difference between the case where audio is playing and the case where it's not. root@ubilinux4:/sys/bus/pci/drivers/snd_hda_intel# more module/refcnt 1 root@ubilinux4:/sys/bus/pci/drivers/snd_hda_intel# more module/refcnt 0 One can only remove the snd-hda-intel module when the refcount is zero. If you try with SOF, you will get the following report: root@ubilinux4:/# more /sys/bus/pci/drivers/sof-audio-pci/module/refcnt 0 root@ubilinux4:/# more /sys/bus/pci/drivers/sof-audio-pci/module/refcnt 0 In short, the device model we have for SOF isn't quite right. There is also something fishy about module dependency. This is what you see on startup: snd_sof                94208  4 snd_sof_intel_hda_common,snd_sof_intel_byt,sof_pci_dev and if I rmmod sof-pci-dev I get this: snd_sof                94208  2 snd_sof_intel_hda_common,snd_sof_intel_byt so somehow we have a bad refcount for module usage.

[ranj063]

@plbossart thanks for the analysis. I'll take a look at the module dependency and refcounts today.

But leaving the module load/unload case apart, does it logically make sense to power down the core only if all the pipelines running on it have been unloaded?

[plbossart]

On 1/28/19 2:55 PM, Ranjani Sridharan wrote: @plbossart <https://github.com/plbossart> thanks for the analysis. I'll take a look at the module dependency and refcounts today. But leaving the module load/unload case apart, does it logically make sense to power down the core only if all the pipelines running on it have been unloaded?

I don't know to be honest, I have already too many questions on IPC, PM and suspend/resume to look at this for now.

[wenqingfu]

the dsp core ref count probably can be fixed together with #557

[wenqingfu]

@zhuyingjiang can you verify if this bug is still valid? please post your test procedure so that others can reproduce the bug.