Re: problems writing pcm driver

[Timur Tabi <timur@freescale.com>]

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