As far as I can see, snd_pcm_update_hw_ptr0() is a critical section of
code that is protected by some form of mutex in all its call paths:
snd_pcm_period_elapsed() - snd_pcm_stream_lock_irqsave()
snd_pcm_update_hw_ptr()
snd_pcm_lib_ioctl_reset() - snd_pcm_stream_lock_irqsave()
snd_pcm_lib_write1() - snd_pcm_stream_lock_irq()
snd_pcm_lib_read1() - snd_pcm_stream_lock_irq()
snd_pcm_status() - snd_pcm_stream_lock_irq()
snd_pcm_do_pause - I think via the locking in snd_pcm_action()
snd_pcm_playback_rewind() - snd_pcm_stream_lock_irq()
snd_pcm_capture_rewind() - snd_pcm_stream_lock_irq()
snd_pcm_playback_forward() - snd_pcm_stream_lock_irq()
snd_pcm_capture_forward() - snd_pcm_stream_lock_irq()
snd_pcm_hwsync() - snd_pcm_stream_lock_irq()
snd_pcm_delay() - snd_pcm_stream_lock_irq()
However, I am not familiar with how kernel locking mechanisms work. It
is possible that the DMA interrupt handler (snd_pcm_period_elapsed()),
could call snd_pcm_update_hw_ptr0() while it is part way through a call
from snd_pcm_status(), or vice versa?
Alan.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
