[alsa-devel] [PATCH 0/4] Yet another patchset for LPE audio refactoring

[Pierre-Louis Bossart]

>>>> - 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.