On 10/13/2021 8:00 PM, Pierre-Louis Bossart wrote:
Since the flow for DPCM is based on taking a lock for the FE first, we need to make sure during the connection between a BE and an FE that they both use the same 'atomicity', otherwise we may sleep in atomic context. If the FE is nonatomic, this patch forces the BE to be nonatomic as well. That should have no negative impact since the BE 'inherits' the FE properties. However, if the FE is atomic and the BE is not, then the configuration is flagged as invalid.
In normal PCM, atomicity seems to apply only for trigger(). Other callbacks like prepare, hw_params are executed in non-atomic context. So when 'nonatomic' flag is false, still it is possible to sleep in a prepare or hw_param callback and this is true for FE as well. So I am not sure if atomicity is applicable as a whole even for FE.
At this point it does not cause serious problems, but with subsequent patches (especially when patch 7/13 is picked) I see failures. Please refer to patch 7/13 thread for more details.
I am wondering if it is possible to only use locks internally for DPCM state management and decouple BE callbacks from this, like normal PCMs do?
