[alsa-devel] problems writing pcm driver
Timur Tabi
timur at freescale.com
Tue Aug 21 23:30:26 CEST 2007
Trent Piepho wrote:
> The driver writing howto says for hw_params, "is that this callback is
> non-atomic (schedulable)."
>
> If it's non-atomic, that would mean to me that it can be called multiple
> times at once, and at the same time as other callbacks. But, you're saying
> that's not the case?
Sounds like the documentation using a wrong definition of "atomic". Perhaps
it's confused with GFP_ATOMIC, which is a parameter used for kmalloc() when
you don't want the kernel to schedule another task.
> Suppose the ring buffer has 256 frames of valid data in it, from position 0
> to position 255. Do I return 255 or 256? It could be either one,
> depending on how your ring buffer operates.
If you have 256 frames of valid data in a 256-frame buffer, then you are about
to have an underrun condition. I think it would be better if your driver
reported an underrun before it got the 256th frame. Just don't allow the
buffer to be completely full.
Most circular buffers don't really support that concept anyway - they
generally require at least one empty slot.
> I have the pointer callback read a hardware register to get the number of
> frames transferred. Maybe I should instead have the irq handler save this
> register in the chip struct, and just read the value from there in the
> pointer callback? This means I have to use locking between the irq handler
> and the pointer callback, which I have been able to avoid so far.
Is reading a hardware register really that slow?
--
Timur Tabi
Linux Kernel Developer @ Freescale
More information about the Alsa-devel
mailing list