On Friday 12 March 2010 00:43:41 ext Mark Brown wrote: > I can do, though there was some debate about how useful the > information the hardware returns actually is - could folks confirm > what the consensus there was, please? Yeah, that thread went silent without final go or no go... I do agree with Eero, that the BUFFSTAT register is not the most reliable source of information, but I still believe that the way we are going to use it will give pretty close to the reality estimation on the statuses. Eero also mentioned timestamp based estimation, which I think can also be used in this way: In element mode, we just return the delay as the whole size of the buffer (which is not accurate when we initially fill the buffer, and when we drain it at the end, but it is not a real problem). In threshold mode, than we can take timestamp at DMA completion interrupts, and calculate the delay based on the FIFO size (FIFO size - samples played out since the last timstamp). This can also give false numbers at the start of the playback (for few periods, until the buffer utilization settles). So the timestamp based solution looks good, but it is only usable when the codec is running synchronously. It will definitely falls apart as soon as we use a codec like tlv320dac33 in burst mode (FIFO on the codec as well). We could have ~100 ms between DMA interrupts, so the countdown for McBSP FIFO usage is already broken. Furthermore since there is no way at the moment to actually synchronize the omap-mcbsp, omap-pcm and tlv320dac33 (in DMA, McBSP threshold, McBSP mode and DAC33 mode sense), there could be cases, that this big silence on the bus (when DAC33 is playing from it's buffer) is not happening exactly after the DMA filled up the McBSP FIFO, but a bit later (could be just one sample away from the next McBSP threshold event), which means that the McBSP FIFO is nowhere near to be full. In this case the BUFFSTAT register would give good estimation, than any timestamp based solution for McBSP FIFO. All in all, I think the usage of the BUFFSTAT register is a good compromise for all cases, and it is needed for the cases, where the codec also have buffer of it's own. Never the less, we can also add the timestamp based estimation later, but we need to make sure, that those can be picked somehow for the given setup. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
