- the 'only' change is to make sure the hw_ptr reported in .pointer is
NOT the number of samples pushed out to the interface. hw_ptr should
although, I'm not entirely sure this still makes rewinds fully safe. After driver has called period elapsed and hw_ptr jumps ahead one period worth of samples, the DMA for the next burst/batch is already programmed and possibly ongoing. And with some drivers the burst size (of a single DMA transaction) may be fairly large, while some transfer sample at a time, at codec rate.
This might lead to undefined behaviour when application rewinds upto hw_ptr and starts to refill the segment of the ringbuffer just after hw_ptr, while at the same time DMA engine is already transferring data out of that same ringbuffer segment.
So a safer bet would be to limit rewinds to hw_ptr+X, where X is highly driver/hw specific. At the minimum, 'X >= dma_get_cache_alignment()' (see linux/Documentation/DMA-API.txt) to get deterministic results on different platforms. A sane convervative assumption is 'X >= period-size'.
Well, we went from my interpretation that was completely broken to something that can still be broken at times... If you really want to be safe, you'd need a means to specify this X value for your system. Actually it would make a lot of sense to do so. On most embedded systems the DMA bursts and buffering in FIFOs can be programmed. It'd be nice to have the ability to set different values for DMA bursts and delay depending on the mode (low-power, low-latency, etc).