[PATCH v3 11/17] ASoC: Intel: avs: Firmware resources management utilities

[Cezary Rojewski]

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