On 2022-03-07 6:30 PM, Ranjani Sridharan wrote:
On Mon, 2022-03-07 at 18:13 +0100, Cezary Rojewski wrote:
This is the part that's hard to follow without seeing the actual code where this new library is loaded. When does a libray get loaded? When you start streaming and you realize that the stream requires a module that is not built into the base FW? Can this be done during topology loading instead?
But that's already done during topology load! If there is no topology
telling the driver: "hey, load this lib for me!", nothing gets loaded
regardless of how your /lib/firmware looks like. Libraries get loaded
during soc-component's (platform component) ->probe(). This is place
where snd_soc_tplg_component_load() is called.
However, if platform has no IMR capability, driver has to re-load
libraries for all platform components of bound sound cards on every
pm_runtime_resume().
And if it done during pm_runtime_resume(), where would the problem with synchronizing arise from? userspace apps do not get resumed until after the PCI device is resumed isnt it?
Scenario you describe is correct and does not prompt the need for the mutex.
However, ->mods_info is accessed through getters found in utils.c (this very patch) during stream creation too. That fragment is part of path management series though - it was requested to split those bits away.
So, there is a possibility for a platform-soc-component to have its ->probe() called - and thus triggering ->mods_info update - while a stream is being opened on a different sound card simultaneously. To avoid unwanted behavior e.g.: looping through ->mods_info while it's being updated in separate thread, we lock the array.
Regards, Czarek