[alsa-devel] snd_pcsp locking mess

[Stas Sergeev]

bugme-daemon at bugzilla.kernel.org wrote:
> ------- Comment #17 from tiwai at suse.de  2008-05-18 10:22 -------
> Anyway, what I meant is that the part touching I/O ports could be a faster path
> than softirq.  And the hrtimer code can use a bit simpler locks.  The hrtimer
> callback needs just one thing about DMA buffer - the buffer is allocated and
> the address doesn't change during the callback.  So, we'd need the lock for the
> hr callback and for the PCM prepare, hwparams and free callbacks, i.e. to
> assure that the hrtimer callback is finished when these PCM callbacks may
> change the DMA buffer.  Thus this lock doesn't have to be PCM substream lock.
I wonder if it would be better to introduce
such a lock in an alsa core rather than in a
driver. The same way as snd_pcm_stream_lock().

> The current lock mess may come from the PCM trigger (STOP) called from
> snd_pcm_period_elapsed().  So, putting snd_pcm_period_elapsed() out of hrtimer
> lock is anyway necessary.  A tasklet for snd_pcm_period_elapsed() is needed for
> this reason, too.
Wouldn't it be better to just make
snd_pcm_period_elapsed() to not take
the stream lock? There is a requirement
right now to drop the stream lock before
calling this. I still beleive this is
the root of all the headache. If you
need to drop it, then you either accept
the race or need a second lock, and the
troubles ensue.