[alsa-devel] [PATCH] ALSA: hda: Reset stream if DMA RUN bit not cleared

[Takashi Iwai]

On Tue, 28 Jan 2020 06:15:08 +0100,
Mohan Kumar wrote:
> 
> Tegra HDA has FIFO size which can hold upto 10 audio frames to support
> DVFS. When HDA DMA RUN bit is set to 0 to stop the stream, the DMA RUN
> bit will be cleared to 0 only after transferring all the remaining audio
> frames queued up in the fifo. This is not in sync with spec which states
> the controller will stop transmitting(output) in the beginning of the
> next frame for the relevant stream.
> 
> The above behavior with Tegra HDA was resulting in machine check error
> during the system suspend flow with active audio playback with below kernel
> error logs.
> [ 33.524583] mc-err: [mcerr] (hda) csr_hdar: EMEM address decode error
> [ 33.531088] mc-err: [mcerr] status = 0x20000015; addr = 0x00000000
> [ 33.537431] mc-err: [mcerr] secure: no, access-type: read, SMMU fault: none
> 
> This was due to the fifo has more than one audio frame when the DMA
> RUN bit is set to 0 during system suspend flow and the timeout handling in
> snd_hdac_stream_sync() was not designed to handle this scenario. So the
> DMA will continue running even after timeout hit until all remaining
> audio frames in the fifo are transferred, but the suspend flow will try
> to reset the controller and turn off the hda clocks without the knowledge
> of the DMA is still running and could result in mc-err.
> 
> The above issue can be resolved by doing stream reset with the help of
> snd_hdac_stream_reset() which would ensure the DMA RUN bit is cleared
> if the timeout was hit in snd_hdac_stream_sync().
> 
> Signed-off-by: Mohan Kumar <mkumard at nvidia.com>

Applied now.  Thanks.


Takashi