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
