From: Christian Glindkamp <christian.glindkamp@taskit.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, lrg@slimlogic.co.uk
Subject: Re: [PATCH] ASoC: Add MAX9850 codec driver
Date: Tue, 8 Mar 2011 10:51:49 +0100 [thread overview]
Message-ID: <20110308095149.GA6623@taskit.de> (raw)
In-Reply-To: <20110307151536.GG1829@sirena.org.uk>
On 2011-03-07 15:15, Mark Brown wrote:
> On Mon, Mar 07, 2011 at 01:45:13PM +0100, Christian Glindkamp wrote:
> > +static int max9850_set_bias_level(struct snd_soc_codec *codec,
> > + enum snd_soc_bias_level level)
> > +{
> > + switch (level) {
> > + case SND_SOC_BIAS_ON:
> > + break;
> > + case SND_SOC_BIAS_PREPARE:
> > + snd_soc_update_bits(codec, MAX9850_ENABLE, MAX9850_SHDN,
> > + MAX9850_SHDN);
> > + break;
> > + case SND_SOC_BIAS_STANDBY:
> > + snd_soc_update_bits(codec, MAX9850_ENABLE, MAX9850_SHDN, 0);
> > + break;
> > + case SND_SOC_BIAS_OFF:
> > + break;
>
> This pattern looks awfully like you should set idle_bias_off for the
> CODEC and then move the code blocks down one power level - _SHDN sounds
> like a general power down for the device which fits better with the _OFF
> state.
>
> Or use DAPM like Dimitris suggested.
I've done so, because it seemed that after the first use, the codec is
hold in standby (when not entering suspend) for the whole time. So I
thought by moving shutdown to standby might save some milliamps. But I
think I will go the DAPM route.
> > + /* enable slew-rate control */
> > + snd_soc_update_bits(codec, MAX9850_VOLUME, 0x40, 0x40);
> > + /* set slew-rate 125ms */
> > + snd_soc_update_bits(codec, MAX9850_CHARGE_PUMP, 0xff, 0xc0);
>
> If this is for the charge pump this is fine but the _VOLUME makes it
> sound like this should perhaps be user visibile?
These bits control, whether the volume is set immediately or smoothly
slewn between levels. I don't see a real reason a user would want to
change it.
>
> > +static int max9850_remove(struct snd_soc_codec *codec)
> > +{
> > + return 0;
> > +}
>
> Just delete this if not required, all ASoC functions should be optional.
Will do this, even though Dimitris suggested setting the bias level to
off, because it would still be a nop.
next prev parent reply other threads:[~2011-03-08 9:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 12:45 [PATCH] ASoC: Add MAX9850 codec driver Christian Glindkamp
2011-03-07 13:48 ` Dimitris Papastamos
2011-03-07 17:04 ` Christian Glindkamp
2011-03-07 17:14 ` Mark Brown
2011-03-08 10:14 ` Dimitris Papastamos
2011-03-08 11:52 ` Christian Glindkamp
2011-03-08 12:09 ` Dimitris Papastamos
2011-03-07 15:15 ` Mark Brown
2011-03-08 9:51 ` Christian Glindkamp [this message]
2011-03-07 16:40 ` Seungwhan Youn
2011-03-08 10:21 ` Dimitris Papastamos
2011-03-09 10:20 ` [PATCH v2] " Christian Glindkamp
2011-03-09 14:31 ` Dimitris Papastamos
2011-03-11 11:06 ` Liam Girdwood
2011-03-11 12:09 ` 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=20110308095149.GA6623@taskit.de \
--to=christian.glindkamp@taskit.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@slimlogic.co.uk \
/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).