- The behavior in had_process_buffer_underrun() isn't clear enough.
Or, more exactly, the behavior of AUD_HDMI_STATUS reg and AUD_CONFIG
reg look complex, and need a bit more description for readers
(including me).
Can you guys enlighten a bit?
For the LPE_AUDIO_Buffer_config register (65020h), there is one
important field
10:8: DMA Fifo watermark. The audio unit has 8x64 bytes, this register
define when to fetch data. Bottom line it'd be wise to avoid rewinding
below that FIFO size...
Right, this may be needed to be exposed.
There are two possible interrupt sources in the
STREAM_X_LPE_AUD_HDMI_STATUS (65064h)
Bit 31: sample buffer underrun. HDMI audio unit did not have enough
samples to insert in video frame (cleared by writing a one)
Bit 29: buffer done status, write 1 to clear
Bit 15: sample buffer underrun interrupt enable
OK, then the current code seems naming the function wrongly.
It names had_enable_audio_int() but actually this should be named as
had_clear_interrupts() or such.
I think enable and clear are two separate steps, you only clear what
you've enabled, no?
To be crystal-clear, there are two interrupts we care about
1. buffer interrupt. This is enabled in bit1 of
STREAM_X_LPE_AUD_BUFFER_M_ADDR, the hardware will generate an interrupt
when the hardware is done reading the data from memory. Bit0 is set
after a new address is programmed (or just to reactivate the same address).
2. underrun interrupt. This is enabled once in the
STREAM_X_LPE_AUD_HDMI_STATUS register, you don't need to re-enable it
for each buffer.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
