All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: alsa-devel@alsa-project.org, kyungmin.park@samsung.com
Subject: Re: [PATCH v2] ASoC: AK4671: add ak4671 codec driver
Date: Mon, 7 Sep 2009 11:23:12 +0100	[thread overview]
Message-ID: <20090907102312.GC29898@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <4AA47AE4.9080803@samsung.com>

On Mon, Sep 07, 2009 at 12:15:48PM +0900, Joonyoung Shim wrote:

> +static int ak4671_pll_event(struct snd_soc_dapm_widget *w,
> +		struct snd_kcontrol *kcontrol, int event)
> +{
> +	struct snd_soc_codec *codec = w->codec;
> +	u8 reg;
> +
> +	switch (event) {
> +	case SND_SOC_DAPM_PRE_PMU:
> +		reg = snd_soc_read(codec, AK4671_PLL_MODE_SELECT1);
> +		reg |= AK4671_PMPLL;
> +		snd_soc_write(codec, AK4671_PLL_MODE_SELECT1, reg);
> +		/* pll lock time: max 40ms */
> +		mdelay(40);
> +		break;
> +	case SND_SOC_DAPM_POST_PMD:
> +		reg = snd_soc_read(codec, AK4671_PLL_MODE_SELECT1);
> +		reg &= ~AK4671_PMPLL;
> +		snd_soc_write(codec, AK4671_PLL_MODE_SELECT1, reg);
> +		break;
> +	}

I think you need some reference counting or a supply widget here since
this event is there for all the DACs and ADCs:

> +	/* DAC */
> +	SND_SOC_DAPM_DAC_E("DAC Left", "Left HiFi Playback",
> +			AK4671_AD_DA_POWER_MANAGEMENT, 6, 0, ak4671_pll_event,
> +			SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
> +	SND_SOC_DAPM_DAC_E("DAC Right", "Right HiFi Playback",
> +			AK4671_AD_DA_POWER_MANAGEMENT, 7, 0, ak4671_pll_event,
> +			SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
> +
> +	/* ADC */
> +	SND_SOC_DAPM_ADC_E("ADC Left", "Left HiFi Capture",
> +			AK4671_AD_DA_POWER_MANAGEMENT, 4, 0, ak4671_pll_event,
> +			SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
> +	SND_SOC_DAPM_ADC_E("ADC Right", "Right HiFi Capture",
> +			AK4671_AD_DA_POWER_MANAGEMENT, 5, 0, ak4671_pll_event,
> +			SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),

This shouldn't be a problem if they all go on or off at once (except for
the extra latency from waiting for the PLL to go on) but unless I'm
missing something if capture and playback are stopped independantly I'd
expect that the PLL will get shut down when the first one happens,
causing problems for the still active stream.

  reply	other threads:[~2009-09-07 10:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-07  3:15 [PATCH v2] ASoC: AK4671: add ak4671 codec driver Joonyoung Shim
2009-09-07 10:23 ` Mark Brown [this message]
2009-09-07 10:41   ` Joonyoung Shim

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=20090907102312.GC29898@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=jy0922.shim@samsung.com \
    --cc=kyungmin.park@samsung.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 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.