[alsa-devel] [PATCH] [RFC] sis7019: Initial support for the SiS7019 Audio Accelerator

[Trent Piepho]

On Tue, 9 Oct 2007, Dave Dillow wrote:
> On Tue, 2007-10-09 at 11:48 +0200, Takashi Iwai wrote:
> > You need to unlock sis->hw_lock before calling
> > snd_pcm_period_elapsed().  It may call snd_pcm_stop() at XRUN, and
> > this invokes the trigger callback, which locks hw_lock again.
> > Simply re-acquire hw_lock after calling snd_pcm_period_elapsed().
>
> If I'm guaranteed that I'll never have my prepare() method called
> concurrently for the same substream, I think I can do away with the
> hw_lock completely -- though I need to think through scenarios about
> closing the stream and a late interrupt...
>
> It looks like my prepare() gets called by snd_pcm_action_nonatomic() in
> sound/core/pcm_native.c, and that takes a read lock on the link
> semaphore, so the group won't be changed, but I don't see anything that
> would prevent prepare() being called twice on the same substream
> concurrently. So, I'll probably need to keep some locking to avoid an
> issue there, unless I'm missing a lock upstream.

You're right about that, prepare() can be called concurrently on the same
substream, as can all the non-atomic functions like hw_params().  To be
sure, I wrote a multi-threaded test program to execute concurrent ioctls.

There is a per-device mutex for open/close, so they can't run concurrently.

Note that the ALSA code does *not* handle concurrent calls to hw_params()
or prepare() correctly.  Your driver may have a lock, but the alsa core
doesn't, and will read and write to the runtime parameters concurrently.
See http://article.gmane.org/gmane.linux.alsa.devel/48846