From: Joonyoung Shim <jy0922.shim@samsung.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, kyungmin.park@samsung.com
Subject: Re: [PATCH v2] ASoC: AK4671: add ak4671 codec driver
Date: Mon, 07 Sep 2009 19:41:58 +0900 [thread overview]
Message-ID: <4AA4E376.6000000@samsung.com> (raw)
In-Reply-To: <20090907102312.GC29898@rakim.wolfsonmicro.main>
On 9/7/2009 7:23 PM, Mark Brown wrote:
> 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.
>
OK. I was not far-sighted enough to think of that. I will do additional
try to handle it.
Thanks.
prev parent reply other threads:[~2009-09-07 10:42 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
2009-09-07 10:41 ` Joonyoung Shim [this message]
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=4AA4E376.6000000@samsung.com \
--to=jy0922.shim@samsung.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.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.