On Thu, 2018-05-03 at 09:10 +0800, zhigangw wrote:
On 2018年05月02日 21:09, Pan, Xiuli wrote:
On 5/2/2018 18:11, Liam Girdwood wrote:
On Wed, 2018-05-02 at 09:56 +0000, Jie, Yang wrote:
-----Original Message----- From: sound-open-firmware-bounces@alsa-project.org [mailto:sound-open- firmware-bounces@alsa-project.org] On Behalf Of Wu Zhigang Sent: Wednesday, May 2, 2018 5:34 PM To: sound-open-firmware@alsa-project.org Cc: Wu Zhigang zhigang.wu@linux.intel.com; Wu, Zhigang zhigang.wu@intel.com Subject: [Sound-open-firmware] [PATCH] FIX: Add dma_stop when receive trigger stop cmd in host
when ALSA lib detect xrun issue, it will send stop and start command to DSP without reset. it will hit error in hds_dma_start, if we did not add the dma_stop in
Small typo. Should be 'hda_dma_start'.
Others looks good to me.
Can someone confirm on BYT too.
BYT did not need this handler. The host dma for BYT is also GP-DMA and need to assign the DMA every host copy. When we trigger the host comp stop, there will no more host DMA. This problem is only shown on the APL/CNL platforms.
BTW, this bug is hit by the ALSA pcm lib xrun recovery. When ALSA trace the dma pointer position, it will wrongly though the DSP is in xrun and try to recover it by STOP/START pattern. Will the DSP be recovered from this kind of STOP/START?
Thanks Xiuli
Actually, It should be added. Because we cannot confirm the ALSA lib will not happen XRUN. In this situation, we have to recovered from this case. In the real environment, no one can confirm NO XRUN in ALSA. we have to make sure our DSP is rebust.
after fix this, there is still a xrun issue in the DSP. thanks
Ok, does this mean I should apply or is there another fix coming ?
Thanks
Liam