alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Mark Brown <broonie@kernel.org>, Yitian Bu <yitian.bu@tangramtek.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Problem with commit 924eb47512 ("ASoC: dwc: fix dma stop transferring issue")
Date: Thu, 21 Jan 2016 14:24:07 +0000	[thread overview]
Message-ID: <1453386247.2858.58.camel@linaro.org> (raw)

Hi

In trying to work out why audio stopped working on ARM's Juno board I
bisected the problem to $subject commit and reverting this fixed things.
The symptoms of broken audio was that alsa-utils' speaker-test produced
very short duration 'churps' rather than the voice sample naming each
speaker channel. (Additional note, audio on Juno is routed through a
HDMI transmitter and the patches to support that aren't in the mainline
kernel tree.)

Now, I don't have any documentation for the Designware I2S device so the
following is my speculation from looking at the code and guessing what's
going on...

1. $subject patch makes i2s_start() unmask interrupts for all four
hardware channels. 

2. i2s_stop masks interrupts for all four channels.

3. dw_i2s_hw_params unmasks interrupts for only the number of hardware
channels as required for the specified audio stream format.

So, playing stereo sound (one hardware channel) on my Juno board is
going wrong because i2s_start() now unmasks interrupts for the other 3
unused hardware channels and these are immediately generating
interrupts, making the code think the buffer has finished transmission
(or underflowed, or something like that, remember I'm speculating here).

Now, if audio playback/capture is always achieved by using this sequence
of calls:

dw_i2s_hw_params
i2s_start
i2s_stop

then it seems to me that $subject patch is redundant and should be
reverted. However, if this is allowed (possibly is, depends on how
dw_i2s_trigger can be called) ...

dw_i2s_hw_params
i2s_start
i2s_stop
i2s_start
i2s_stop

then we need to change i2s_start to unmask interrupts for just the
hardware channels being used. I can have a go at producing a patch for
that if that's deemed the correct solution. (Looks like we'd need to
stash the number of used hardware channels in struct dw_i2s_dev).

-- 
Tixy

             reply	other threads:[~2016-01-21 14:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 14:24 Jon Medhurst (Tixy) [this message]
2016-01-27 13:21 ` Problem with commit 924eb47512 ("ASoC: dwc: fix dma stop transferring issue") Mark Brown

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=1453386247.2858.58.camel@linaro.org \
    --to=tixy@linaro.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yitian.bu@tangramtek.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).