From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751520AbbJBBJT (ORCPT ); Thu, 1 Oct 2015 21:09:19 -0400 Received: from smtpbg303.qq.com ([184.105.206.26]:54077 "EHLO smtpbg303.qq.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750762AbbJBBJS (ORCPT ); Thu, 1 Oct 2015 21:09:18 -0400 X-QQ-mid: bizesmtp3t1443748102t249t312 X-QQ-SSF: 01100000003000F0FG52B00A0000000 X-QQ-FEAT: zA6doese0mK4jQ3JZjFNlFPvg9YuIsay3vQZiK74mPqOeuJe21LKVTCRXxa1k PsAVopZEvlAPy6zG6j8LOow7tIg89nvVmeNv4TOom1mKZmW3a+pyoW3hrKGYECYVZ16yOs2 OaRcvaTnAI3xQjI+nn8AsYbhsBicmuDfqi/fnfNEBI8Lj3j7rVpra3QhgCb2S5Yux5ERQyT BhqMoGSnrNPcI9tnRhWqgIVWFnWneQRkO9z6Bfeo2cp2WLE9bLotPxkGYHzUa4h9Y7pJFqM wNMg== X-QQ-GoodBg: 0 From: "yitian" To: "'Mark Brown'" Cc: , , , , , , References: <006401d0fac5$2e4bb840$8ae328c0$@tangramtek.com> <20150930182219.GU15635@sirena.org.uk> <00f401d0fbf0$65f32220$31d96660$@tangramtek.com> In-Reply-To: <00f401d0fbf0$65f32220$31d96660$@tangramtek.com> Subject: RE: [alsa-devel] [RESEND PATCH v2 1/1] ASoC: dwc: fix dma stop transferring issue Date: Fri, 2 Oct 2015 09:08:19 +0800 Message-ID: <01a501d0fcae$d47c9d70$7d75d850$@tangramtek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQMDjbCfokFoqNr/3BMSHTOG5k8F/wIb/QnFAYLPbBGb1UuhcA== Content-Language: zh-cn X-QQ-SENDSIZE: 520 X-QQ-FName: C6785A0139E840FE9C999DB0BC03EF07 X-QQ-LocalIP: 112.95.241.173 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark: > From: alsa-devel-bounces@alsa-project.org > [mailto:alsa-devel-bounces@alsa-project.org] On Behalf Of yitian > Sent: Thursday, October 1, 2015 10:25 AM > To: 'Mark Brown' > Cc: alsa-devel@alsa-project.org; wsa@the-dreams.de; > linux-kernel@vger.kernel.org; Andrew.Jackson@arm.com; > lgirdwood@gmail.com; tiwai@suse.com; > linux-arm-kernel@lists.infradead.org > Subject: Re: [alsa-devel] [RESEND PATCH v2 1/1] ASoC: dwc: fix dma stop > transferring issue > > > From: linux-arm-kernel > > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of > Mark > > Brown > > Sent: Thursday, October 1, 2015 2:22 AM > > To: yitian > > Cc: alsa-devel@alsa-project.org; wsa@the-dreams.de; > > linux-kernel@vger.kernel.org; Andrew.Jackson@arm.com; > tiwai@suse.com; > > lgirdwood@gmail.com; perex@perex.cz; > > linux-arm-kernel@lists.infradead.org > > Subject: Re: [RESEND PATCH v2 1/1] ASoC: dwc: fix dma stop transferring > > issue > > > > On Tue, Sep 29, 2015 at 10:43:17PM +0800, yitian wrote: > > > Designware I2S uses tx empty and rx available signals as the DMA > > > handshaking signals. during music playing, if XRUN occurs, > > > i2s_stop() function will be executed and both tx and rx irq are > > > masked, when music continues to be played, i2s_start() is executed > > > but both tx and rx irq are not unmasked which cause I2S stop > > > sending DMA handshaking signal to DMA controller, and it finally > > > causes music playing will be stopped once XRUN occurs for the first > > > time. > > > > I'm a bit concerned about how this code ever worked given the above > > description - is there some race condition which allows things to work > > if we're lucky? > > Hi Mark: > > Thanks for your comments. > I think maybe two reasons: > 1. designware I2S IP in my chipset(new design) is using tx empty and rx > available signal as the DMA handshaking signal, but it may be not true > for all chipsets. If I2S has separate signal as DMA handshaking signal, mask > irq should not impact DMA transfer. But Synopsys's engineer recommend > us to > use > tx and rx irq signal as the DMA handshaking signal, meanwhile we cannot > find > separate DMA handshaking signal from designware's IP spec, that's why > tx/rx > irq > will impact DMA transfer. > > 2. I am using a FPGA for test, the cpu frequency of it is only 26MHz, that > means > XRUN is very easy to happen on my board. But I guess most of the > developers > are using real chipset which can have at least 600MHz frequency so XRUN > is > not easy to be reproduced. As my test, No XUN, no this bug... Do I need to provide anything else for this patch? Thanks.