From: Nicolin Chen <b42378@freescale.com>
To: Markus Pargmann <mpa@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@freescale.com>,
alsa-devel@alsa-project.org, Lars-Peter Clausen <lars@metafoo.de>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
shawn.guo@linaro.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] ASoC: fsl-ssi: Missing DMA-Request workaround
Date: Tue, 12 Nov 2013 10:30:34 +0800 [thread overview]
Message-ID: <20131112023033.GA23243@MrMyself> (raw)
In-Reply-To: <20131112014913.GE11083@S2101-09.ap.freescale.net>
Hi Markus,
On Tue, Nov 12, 2013 at 09:49:16AM +0800, Shawn Guo wrote:
> Copy Nicolin.
>
> Shawn
>
> On Mon, Nov 11, 2013 at 05:03:36PM +0100, Markus Pargmann wrote:
> > There is a hardware issue when using capture and playback at the same
> > time. In the tested scenario, the capture stream was started slightly
> > before the playback stream. The first time the application starts after
> > a powerup, there is a high probability that the SSI unit does not send a
> > request to the SDMA unit. The playback does not work. I tested this on
> > i.MX53 with SSI unit 2 kernel 3.10.10.
I've been tested SSI with WM8962 on i.MX6 series for a while, and never met
this issue, well, not with 3.10.10 original code and i.MX53 though.
Could you please provide me a reproducible flow?
If playback first and capture later, would this also reproduce the issue?
Is there any command must be executed before the arecord | aplay, or just
run it after system boot-up?
By trying to reproduce it on i.MX6, we can confirm if it's a common issue
to the IP or its driver, or just a hardware defect within i.MX53.
Thank you,
Nicolin Chen
---
> >
> > Here is a register dump of the situation:
> > SDMA
> > 0x63fb0000
> > 00000000: c0040000 00000000 0000001e 00000000
> > 00000010: 00000001 ffffffff 00000000 e03efa41
> > 00000020: 00000000 00000000 00000000 00000000
> > 00000030: 00000064 00000000 00000003 00000000
> > 00000040: 00000000 00000000 00000000 00006000
> > 00000050: 00000000 00000000 00000001 00004050
> > 00000060: 01208000 00000000 00000000 00000000 /* 0x60: EVT_MIRROR showing all received DMA requests */
> > ^ This should be a 3 instead. Bits 24 and 25 are the DMA requests for
> > RX and TX. Bit 25 is not set, DMA request 25 is missing.
> >
> > SSI
> > 0x50014000
> > 00000000: 00000000 00000000 0000005f 00000000
> > 00000010: 00000457 000050c1 01f80f00 0000028d /* 0x14: ISR Interrupt status register */
> > ^
> > At 0x14 we can clearly see the last bit is set (0x1) which
> > is TFE0, Transmit FIFO 0 empty. So it should automatically
> > request data from the DMA engine, but it doesn't.
> >
> > 00000020: 0000028d 0004e000 00040000 000010dd
> > 00000030: 00001f1f 00000000 00000000 00000000
> > 00000040: 00000000 00000000 00000000 00000000
> > 00000050: 00000000 00000000 ........
> > STATS (/sys/bus/platform/devices/50014000.ssi/statistics)
> > rfrc=0
> > tfrc=0
> > roe1=0
> > roe0=0
> > tue1=0
> > tue0=1094475
> >
> > I could solve this issue by filling the transmit FIFO with data. After
> > that, the SDMA unit receives DMA request 25 again and audio playback
> > works.
> >
> > This patch adds TUE0 interrupt handler which fills FIFO0 with arbitrary data.
> >
> > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > ---
> >
> > Hi,
> >
> > does anyone have an idea why the SSI unit does not request DMA by its own at
> > the beginning? Or is it a hardware errata that is not listed yet?
> >
> > Regards,
> >
> > Markus Pargmann
> >
> >
> > sound/soc/fsl/fsl_ssi.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> > index 6b81d0c..8faf2b5 100644
> > --- a/sound/soc/fsl/fsl_ssi.c
> > +++ b/sound/soc/fsl/fsl_ssi.c
> > @@ -269,9 +269,14 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
> > }
> >
> > if (sisr & CCSR_SSI_SISR_TUE0) {
> > + int i;
> > +
> > ssi_private->stats.tue0++;
> > sisr2 |= CCSR_SSI_SISR_TUE0;
> > ret = IRQ_HANDLED;
> > +
> > + for (i = 0; i != ssi_private->fifo_depth; ++i)
> > + write_ssi(0x0, &ssi->stx0);
> > }
> >
> > if (sisr & CCSR_SSI_SISR_TFS) {
> > --
> > 1.8.4.2
> >
WARNING: multiple messages have this Message-ID (diff)
From: b42378@freescale.com (Nicolin Chen)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] ASoC: fsl-ssi: Missing DMA-Request workaround
Date: Tue, 12 Nov 2013 10:30:34 +0800 [thread overview]
Message-ID: <20131112023033.GA23243@MrMyself> (raw)
In-Reply-To: <20131112014913.GE11083@S2101-09.ap.freescale.net>
Hi Markus,
On Tue, Nov 12, 2013 at 09:49:16AM +0800, Shawn Guo wrote:
> Copy Nicolin.
>
> Shawn
>
> On Mon, Nov 11, 2013 at 05:03:36PM +0100, Markus Pargmann wrote:
> > There is a hardware issue when using capture and playback at the same
> > time. In the tested scenario, the capture stream was started slightly
> > before the playback stream. The first time the application starts after
> > a powerup, there is a high probability that the SSI unit does not send a
> > request to the SDMA unit. The playback does not work. I tested this on
> > i.MX53 with SSI unit 2 kernel 3.10.10.
I've been tested SSI with WM8962 on i.MX6 series for a while, and never met
this issue, well, not with 3.10.10 original code and i.MX53 though.
Could you please provide me a reproducible flow?
If playback first and capture later, would this also reproduce the issue?
Is there any command must be executed before the arecord | aplay, or just
run it after system boot-up?
By trying to reproduce it on i.MX6, we can confirm if it's a common issue
to the IP or its driver, or just a hardware defect within i.MX53.
Thank you,
Nicolin Chen
---
> >
> > Here is a register dump of the situation:
> > SDMA
> > 0x63fb0000
> > 00000000: c0040000 00000000 0000001e 00000000
> > 00000010: 00000001 ffffffff 00000000 e03efa41
> > 00000020: 00000000 00000000 00000000 00000000
> > 00000030: 00000064 00000000 00000003 00000000
> > 00000040: 00000000 00000000 00000000 00006000
> > 00000050: 00000000 00000000 00000001 00004050
> > 00000060: 01208000 00000000 00000000 00000000 /* 0x60: EVT_MIRROR showing all received DMA requests */
> > ^ This should be a 3 instead. Bits 24 and 25 are the DMA requests for
> > RX and TX. Bit 25 is not set, DMA request 25 is missing.
> >
> > SSI
> > 0x50014000
> > 00000000: 00000000 00000000 0000005f 00000000
> > 00000010: 00000457 000050c1 01f80f00 0000028d /* 0x14: ISR Interrupt status register */
> > ^
> > At 0x14 we can clearly see the last bit is set (0x1) which
> > is TFE0, Transmit FIFO 0 empty. So it should automatically
> > request data from the DMA engine, but it doesn't.
> >
> > 00000020: 0000028d 0004e000 00040000 000010dd
> > 00000030: 00001f1f 00000000 00000000 00000000
> > 00000040: 00000000 00000000 00000000 00000000
> > 00000050: 00000000 00000000 ........
> > STATS (/sys/bus/platform/devices/50014000.ssi/statistics)
> > rfrc=0
> > tfrc=0
> > roe1=0
> > roe0=0
> > tue1=0
> > tue0=1094475
> >
> > I could solve this issue by filling the transmit FIFO with data. After
> > that, the SDMA unit receives DMA request 25 again and audio playback
> > works.
> >
> > This patch adds TUE0 interrupt handler which fills FIFO0 with arbitrary data.
> >
> > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > ---
> >
> > Hi,
> >
> > does anyone have an idea why the SSI unit does not request DMA by its own at
> > the beginning? Or is it a hardware errata that is not listed yet?
> >
> > Regards,
> >
> > Markus Pargmann
> >
> >
> > sound/soc/fsl/fsl_ssi.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> > index 6b81d0c..8faf2b5 100644
> > --- a/sound/soc/fsl/fsl_ssi.c
> > +++ b/sound/soc/fsl/fsl_ssi.c
> > @@ -269,9 +269,14 @@ static irqreturn_t fsl_ssi_isr(int irq, void *dev_id)
> > }
> >
> > if (sisr & CCSR_SSI_SISR_TUE0) {
> > + int i;
> > +
> > ssi_private->stats.tue0++;
> > sisr2 |= CCSR_SSI_SISR_TUE0;
> > ret = IRQ_HANDLED;
> > +
> > + for (i = 0; i != ssi_private->fifo_depth; ++i)
> > + write_ssi(0x0, &ssi->stx0);
> > }
> >
> > if (sisr & CCSR_SSI_SISR_TFS) {
> > --
> > 1.8.4.2
> >
next prev parent reply other threads:[~2013-11-12 2:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 16:03 [RFC] ASoC: fsl-ssi: Missing DMA-Request workaround Markus Pargmann
2013-11-11 16:03 ` Markus Pargmann
2013-11-11 16:07 ` Fabio Estevam
2013-11-11 16:07 ` Fabio Estevam
2013-11-11 16:26 ` Markus Pargmann
2013-11-11 16:26 ` Markus Pargmann
2013-11-12 1:49 ` Shawn Guo
2013-11-12 1:49 ` Shawn Guo
2013-11-12 2:30 ` Nicolin Chen [this message]
2013-11-12 2:30 ` Nicolin Chen
2013-11-12 10:57 ` Markus Pargmann
2013-11-12 10:57 ` Markus Pargmann
2013-11-12 10:42 ` Nicolin Chen
2013-11-12 10:42 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131112023033.GA23243@MrMyself \
--to=b42378@freescale.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=fabio.estevam@freescale.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mpa@pengutronix.de \
--cc=shawn.guo@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.