Re: [RFC PATCH v2 0/5] ASoC: soc-pcm: fix trigger race conditions with shared BE

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>> Takashi, Mark, do you think that an all/none assumption on FE nonatomic
>> properties would make sense?
> 
> As long as BE's are updated from FE's PCM callback, BE has to follow
> the atomicity of its FE, so we can't assume all or none globally.

A BE may have more than one FEs. That's precisely the point of
mixers/demux, and if the BE has FEs with different 'atomicity' then I
don't see how locking can work: the BE operations are run in the context
of each of its FE, typically using the following loop:

for_each_dpcm_be(fe, stream, dpcm) {
   do_something();
}

Applications will view multiple FEs as completely independent. They may
be opened/prepared/started/stopped/paused as needed. When the BE is
shared, then there is a need for consistency, such as starting the BE
when the first FE becomes active and stopping it when the last FE stops.

> How is the expected lock granularity and the protection context?  Do
> we need a card global lock/mutex, or is it specific to each BE
> substream?

We already have a dpcm_lock at the card level, which protects the
addition of BEs and BE states. That spin_lock is fine for most cases.

The only real problem is the trigger, which is currently completely
unprotected: we have to serialize the BE triggers, otherwise you could
STOP before you START due to scheduling, or other problems that I saw in
my SoundWire tests with two START triggers, or the STOP never sent.

But how to do this serialization is unclear...

A lateral thinking approach would be to decouple the BEs entirely, and
have the FEs 'signal' their change of state. The BE 'thread' run in the
BE context would then serialize the requests and perform all the BE
operations, and the same approach could be chained. I am afraid that
would be a complete rewrite of DPCM, but maybe we have to do so anyways
if we can't support a basic case of a mixer with 2 streams :-)