diff options
author | Peter Ujfalusi <peter.ujfalusi@nokia.com> | 2010-04-23 10:10:01 +0300 |
---|---|---|
committer | Liam Girdwood <lrg@slimlogic.co.uk> | 2010-04-26 15:16:39 +0100 |
commit | f57d2cfaad0d6858d700b5671e01cf3aba6ef779 (patch) | |
tree | 592557de5cb0020fc6bc993296c3574a3a3ab233 /drivers/oprofile/buffer_sync.h | |
parent | 76f471274dc9acacd521f151ac9171fd7bbc34c3 (diff) | |
download | blackbird-op-linux-f57d2cfaad0d6858d700b5671e01cf3aba6ef779.tar.gz blackbird-op-linux-f57d2cfaad0d6858d700b5671e01cf3aba6ef779.zip |
ASoC: tlv320dac33: FIFO caused delay reporting
Delay reporting for the three implemented DAC33 FIFO modes.
DAC33 has FIFO depth status register(s), but it can not be used, since
inside of pcm_pointer we can not send I2C commands.
Timestamp based estimation need to be used. The method of calculating
the delay depends on the active FIFO mode.
Bypass mode: FIFO is bypassed, report 0 as delay
Mode1: nSample fill mode. In this mode I need to use two timestamp
ts1: taken when the interrupt has been received
ts2: taken before writing to nSample register.
Interrupts are coming when DAC33 FIFO depth goes under alarm threshold.
Phase1: when we received the alarm threshold, but our workqueue has
not been executed (safeguard phase). Just count the played out
samples since ts1 and subtract it from the alarm threshold
value.
Phase2: During nSample burst (after writing to nSample register), count
the played out samples since ts1, count the samples received
since ts2 (in a burst). Estimate the FIFO depth using these and
alarm threshold value.
Phase3: Draining phase (after the burst read), count the played out
samples since ts1. Estimate the FIFO depth using the nSample
configuration and the alarm threshold value.
Mode7: Threshold based fill mode. In this mode one timestamp is enough.
ts1: taken when the interrupt has been received
Interrupts are coming when DAC33 FIFO depth reaches upper threshold.
Phase1: Draining phase (after the burst), counting the played out
samples since ts1, and subtract it from the upper threshold
value.
Phase2: During burst operation. Using the pre calculated time needed to
play out samples from the buffer during the drain period (from
upper to lower threshold), move the time window to cover the
estimated time from the burst start to the current time.
Calculate the samples played out since lower threshold and also
the samples received during the same time.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Diffstat (limited to 'drivers/oprofile/buffer_sync.h')
0 files changed, 0 insertions, 0 deletions