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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
