Repository navigation
Can't find sof_dai in sof_link_unload() #343
Description
We will see below error message if we rmmod sof_pci_dev
[ 82.481898] sof-audio sof-audio: error: invalid DAI type 0
[ 82.482352] sof-audio sof-audio: error: invalid DAI type 0
[ 82.482823] sof-audio sof-audio: error: invalid DAI type 0
[ 82.483266] sof-audio sof-audio: error: invalid DAI type 0
The reason is link->name and sof_dai->name are not matched in sof_link_unload()
for example, on up2 with pcm512x codec,
the link->name are HDMI3, HDMI2, HDMI1, and Port5
But the sof_dai->name are iDisp3, iDisp2, iDisp1, SSP5-Codec
But it was matched in sof_link_load().
Activity
bardliao commentedon Dec 3, 2018
The reason why the dai->name does not match with the link->name in sof_link_unload() is sof_link_unload() is not called by those matched dai links.
sof_link_unload() will be called by remove_link(). But it will only deal with the dai links created by soc_tplg_fe_link_create(). (HDMI3, HDMI2, HDMI1, and Port5). The other dai links (iDisp3, iDisp2, iDisp1, SSP5-Codec) are created by snd_soc_instantiate_card() -> snd_soc_add_dai_link(). These dai links will be load in snd_soc_tplg_component_load() -> soc_tplg_load_header() -> soc_tplg_link_elems_load(), but will never be unload. ie. Those dai links which be loaded from snd_soc_tplg_component_load() will never be unload since soc-topology or soc-core didn't do it for us. Probably we need to call sof_link_unload by ourselves or modify soc-core and let it do it for us. @lgirdwood What do you think?
plbossart commentedon Dec 3, 2018
@bardliao: my take is that whatever is allocated by the topology is released by the topology, and whatever is statically added by the card creation should also be released on removing the card. We don't want to confuse the two parts, do we?
bardliao commentedon Dec 4, 2018
@plbossart Agree. Let's focus on the dai links which ever call sof_link_unload(). Suppose sof_link_unload() is the invert of sof_link_load(), right? So, if a dai link is called by sof_link_load(), we will expect it will be called by sof_link_unload(). Currently, sof_link_load() will be invoked by soc_tplg_load(). But there is no corresponding link_unload for it. Actually I can't find an API for tplg unload. snd_soc_tplg_component_remove() will only remove the object which is created by soc-topology.c.
mengdonglin commentedon Dec 29, 2018
Closing this issue since it's fixed by #392
bardliao commentedon Dec 30, 2018
@mengdonglin Actually, there are two issues.
mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM
sched: Fix sched_numa_find_nth_cpu() if mask offline
selftests/bpf: Extend tcx tests to cover late tcx_entry release