linux-kernel - RE: [alsa-devel] [RESEND PATCH v2 1/1] ASoC: dwc: fix dma stop transferring issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01a501d0fcae$d47c9d70$7d75d850$@tangramtek.com>
Date:	Fri, 2 Oct 2015 09:08:19 +0800
From:	"yitian" <yitian.bu@...gramtek.com>
To:	"'Mark Brown'" <broonie@...nel.org>
Cc:	<alsa-devel@...a-project.org>, <wsa@...-dreams.de>,
	<linux-kernel@...r.kernel.org>, <Andrew.Jackson@....com>,
	<lgirdwood@...il.com>, <tiwai@...e.com>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [alsa-devel] [RESEND PATCH v2 1/1] ASoC: dwc: fix dma stop	transferring issue

Hi Mark:

> From: alsa-devel-bounces@...a-project.org
> [mailto:alsa-devel-bounces@...a-project.org] On Behalf Of yitian
> Sent: Thursday, October 1, 2015 10:25 AM
> To: 'Mark Brown' <broonie@...nel.org>
> Cc: alsa-devel@...a-project.org; wsa@...-dreams.de;
> linux-kernel@...r.kernel.org; Andrew.Jackson@....com;
> lgirdwood@...il.com; tiwai@...e.com;
> linux-arm-kernel@...ts.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@...ts.infradead.org] On Behalf Of
> Mark
> > Brown
> > Sent: Thursday, October 1, 2015 2:22 AM
> > To: yitian <yitian.bu@...gramtek.com>
> > Cc: alsa-devel@...a-project.org; wsa@...-dreams.de;
> > linux-kernel@...r.kernel.org; Andrew.Jackson@....com;
> tiwai@...e.com;
> > lgirdwood@...il.com; perex@...ex.cz;
> > linux-arm-kernel@...ts.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/