alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Oder Chiou <oder_chiou@realtek.com>
Cc: jack.yu@realtek.com, alsa-devel@alsa-project.org,
	lgirdwood@gmail.com, john.lin@realtek.com,
	koro.chen@mediatek.com, pc.liao@mediatek.com,
	bardliao@realtek.com, flove@realtek.com
Subject: Re: [PATCH v2] ASoC: rt5514: add rt5514 SPI driver
Date: Tue, 29 Mar 2016 14:51:21 -0700	[thread overview]
Message-ID: <20160329215121.GP2350@sirena.org.uk> (raw)
In-Reply-To: <1457953101-19348-1-git-send-email-oder_chiou@realtek.com>


[-- Attachment #1.1: Type: text/plain, Size: 3093 bytes --]

On Mon, Mar 14, 2016 at 06:58:21PM +0800, Oder Chiou wrote:

This looks mostly good, a few relatively small things here that should
be simple to fix:

> +static void rt5514_spi_copy_work(struct work_struct *work)
> +{
> +	struct rt5514_dsp *rt5514_dsp =
> +		container_of(work, struct rt5514_dsp, copy_work.work);
> +	struct snd_pcm_runtime *runtime = rt5514_dsp->substream->runtime;
> +	size_t period_bytes, truncated_bytes = 0;
> +
> +	mutex_lock(&rt5514_dsp->dma_lock);

_copy_work() holds dma_lock for the entire time it runs...

> +static int rt5514_spi_hw_free(struct snd_pcm_substream *substream)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct rt5514_dsp *rt5514_dsp =
> +			snd_soc_platform_get_drvdata(rtd->platform);
> +
> +	mutex_lock(&rt5514_dsp->dma_lock);
> +	cancel_delayed_work_sync(&rt5514_dsp->copy_work);
> +	rt5514_dsp->substream = NULL;
> +	mutex_unlock(&rt5514_dsp->dma_lock);

...but _hw_free() tries to cancel the work while holding dma_lock.  This
means we've got a deadlock, if the work starts running after the mutex
is acquired in _hw_free() then it will block trying to get the mutex
which will never get released because we're waiting for the work to
complete.

Looks like the cancel needs to be after the unlock.

> +static struct spi_driver rt5514_spi_driver = {
> +	.driver = {
> +			.name = "rt5514",
> +			.of_match_table = of_match_ptr(rt5514_of_match),

Weird indentation here.

> +static void rt5514_enable_dsp_prepare(struct rt5514_priv *rt5514)
> +{
> +	/* Reset */
> +	regmap_write(rt5514->i2c_regmap, 0x18002000, 0x000010ec);

This is a *very* big table of magic numbers with what look like system
specific settings in there (there seem to be some things routing to and
from the ADC, and some clocking setup...).  Are you sure none of this
depends on the runtime configuration?

> +	if (rt5514->dsp_enabled) {
> +		rt5514_enable_dsp_prepare(rt5514);
> +
> +		request_firmware(&fw, RT5514_FIRMWARE1, codec->dev);
> +		if (fw) {
> +#if defined(CONFIG_SND_SOC_RT5514_SPI)
> +			rt5514_spi_burst_write(0x4ff60000, fw->data,
> +				((fw->size/8)+1)*8);
> +#endif

This will silently report success if SPI support is disabled, I'd expect
either the control would be entirely absent or we'd report an error.

> +		if (snd_soc_codec_get_bias_level(codec) ==
> +			SND_SOC_BIAS_STANDBY) {
> +			/**
> +			 * If the DSP is enabled in start of recording, the
> +			 * DSP should be disabled, and sync back to normal
> +			 * recording settings to make sure recording
> +			 * properly.
> +			*/
> +			if (rt5514->dsp_enabled) {
> +				rt5514->dsp_enabled = 0;
> +				regcache_mark_dirty(rt5514->i2c_regmap);
> +				regcache_mark_dirty(rt5514->regmap);
> +				regcache_sync(rt5514->i2c_regmap);
> +				regcache_sync(rt5514->regmap);
> +			}

This talks specifically about recording but this is in set_bias_level().
I'd expect something to do with the start/stop of recording to be
attached to something like a DAPM event for an ADC or DAI widget.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2016-03-29 21:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 10:58 [PATCH v2] ASoC: rt5514: add rt5514 SPI driver Oder Chiou
2016-03-29 21:51 ` Mark Brown [this message]
2016-03-31  6:29   ` Oder Chiou
2016-03-31 16:50     ` Mark Brown
2016-04-01  6:01       ` Oder Chiou
2016-04-01 14:17         ` Mark Brown
2016-04-06 11:30           ` Oder Chiou
2016-04-06 17:05             ` 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=20160329215121.GP2350@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bardliao@realtek.com \
    --cc=flove@realtek.com \
    --cc=jack.yu@realtek.com \
    --cc=john.lin@realtek.com \
    --cc=koro.chen@mediatek.com \
    --cc=lgirdwood@gmail.com \
    --cc=oder_chiou@realtek.com \
    --cc=pc.liao@mediatek.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).