From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jerry Wong <Jerry.Wong@maximintegrated.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: [PATCH 002/002] ASoC: Replace max98090 Device Driver
Date: Thu, 17 Jan 2013 02:53:33 +0000 [thread overview]
Message-ID: <20130117025333.GA12645@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <A453F1AE3B5DC14DB19666C506CE75A7108684F403@ITSVLEX06.it.maxim-ic.internal>
On Mon, Jan 14, 2013 at 07:13:30AM -0800, Jerry Wong wrote:
> I have updated most per the review comments, except...
> "External MIC Mux" is a mux with 0=power down, and exists in DAPM as well
> "Digital Sidetone Source", with a master SHDN has no power impact, so was left out of DAPM
Sidetone should have an impact on routing though? DAPM needs routing to
do power.
> "Quick Setup System Clock" was just a question what they do... they override the
> clock settings for common use cases.
> "VCM bandgap reference", with a master SHDN has no power impact, so was left out of DAPM
>
Please have this sort of discussion in line with the previous review -
discuss why you don't agree with the feedback rather than just sending a
new patch. That tends to be less time consuming and it's easier to
follow the discusssion.
> +static const char * max98090_extmic_mux_text[] = { "MIC1", "MIC2" };
> +
> +static const struct soc_enum max98090_extmic_mux_enum =
> + SOC_ENUM_SINGLE(M98090_REG_CFG_LINE, M98090_EXTMIC_SHIFT,
> + ARRAY_SIZE(max98090_extmic_mux_text),
> + max98090_extmic_mux_text);
This looks like routing control which I'd expect to be in DAPM - I'd not
expect duplication between DAPM and non-DAPM to work very well.
> +static const char * max98090_mixg_text[] = { "Normal", "6dB" };
> +static const struct soc_enum max98090_mixg135_enum =
> + SOC_ENUM_SINGLE(M98090_REG_LVL_LINE, M98090_MIXG135_SHIFT,
> + ARRAY_SIZE(max98090_mixg_text), max98090_mixg_text);
> +
> +static const struct soc_enum max98090_mixg246_enum =
> + SOC_ENUM_SINGLE(M98090_REG_LVL_LINE, M98090_MIXT246_SHIFT,
> + ARRAY_SIZE(max98090_mixg_text), max98090_mixg_text);
This looks like it should be a volume control with two steps of 0dB and
6dB?
> +static const char * max98090_enableddisabled_text[] =
> + { "Disabled", "Enabled" };
> +static const char * max98090_enableddisabled_inv_text[] =
> + { "Enabled", "Disabled" };
> +/* Note: Inverted Logic (0 = Enabled) */
> +
> +static const struct soc_enum max98090_eqclpn_enum =
> + SOC_ENUM_SINGLE(M98090_REG_DAI_LVL_EQ, M98090_DAI_LVL_EQCLPN_SHIFT,
> + ARRAY_SIZE(max98090_enableddisabled_inv_text),
> + max98090_enableddisabled_inv_text);
These look like they should be Switch controls (which will help UIs
render them).
> +static const struct snd_kcontrol_new max98090_snd_controls[] = {
> + SOC_SINGLE("MIC Bias VCM Bandgap", M98090_REG_BIAS_CNTL,
> + M98090_VCM_MODE_SHIFT, M98090_VCM_MODE_NUM - 1, 0),
Why is this a user visible control?
> + SOC_SINGLE("Quick Setup Sample Rate", M98090_REG_QCFG_RATE,
> + M98090_SR_ALL_SHIFT, M98090_SR_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup DAI Interface", M98090_REG_QCFG_DAI,
> + M98090_DAI_ALL_SHIFT, M98090_DAI_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup DAC Path", M98090_REG_QCFG_DAC,
> + M98090_DIG2_ALL_SHIFT, M98090_DIG2_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup MIC/Direct ADC", M98090_REG_QCFG_MIC_PATH,
> + M98090_MIC_ALL_SHIFT, M98090_MIC_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup Line ADC", M98090_REG_QCFG_LINE_PATH,
> + M98090_LINE_ALL_SHIFT, M98090_LINE_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup Analog MIC Loop", M98090_REG_QCFG_MIC_LOOP,
> + M98090_AMIC_ALL_SHIFT, M98090_AMIC_ALL_NUM - 1, 0),
> + SOC_SINGLE("Quick Setup Analog Line Loop",
> + M98090_REG_QCFG_LINE_LOOP, M98090_ALIN_ALL_SHIFT,
> + M98090_ALIN_ALL_NUM - 1, 0),
What do these controls do?
> + SOC_SINGLE("Rev ID", M98090_REG_REV_ID,
> + M98090_REVID_SHIFT, M98090_REVID_NUM - 1, 0),
Hrm, this needs to be read only I think but we don't support that via
standard macros. I'd expect exposing via a sysfs file rather than an
ALSA control, or just logging on startup - it'll be exposed via the
regmap debugfs interface anyway.
> +static const struct snd_soc_dapm_route max98090_dapm_routes[] = {
> +
> + {"MIC1 Input", NULL, "MIC1"},
> + {"MIC2 Input", NULL, "MIC2"},
> + {"MIC1 Input", NULL, "MICBIAS"},
> + {"MIC2 Input", NULL, "MICBIAS"},
Is this really an internal connection in the device and not something
that's done in the system?
> +/*
> + * This accommodates an inverted logic in the MAX98090 chip
> + * for Bit Clock Invert (BCI). The inverted logic is only seen
> + * for the case of TDM mode. The remaining cases have normal logic.
> + */
> + if (max98090->tdm_slots > 1) {
> + regval ^= M98090_DAI_BCI_MASK;
Coding style, your comment is misaligned.
> +
> + switch (reg & (M98090_LSNS_MASK | M98090_JKSNS_MASK)) {
> + case M98090_LSNS_MASK | M98090_JKSNS_MASK:
> + {
You don't need the { } and they make the code look unusual.
> + dev_info(codec->dev, "No Headset Detected\n");
> +
> + max98090->jack_state = M98090_JACK_STATE_NO_HEADSET;
> +
> + max98090_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
The issues I mentioned last time with the lack of sync between this code
and DAPM still apply - DAPM is likely to just come along and override
you here.
> + if (active & M98090_IRQ_ULK_MASK) {
> + dev_dbg(codec->dev, "M98090_IRQ_ULK_MASK\n");
> + }
Should things like this be dev_err() - they look like real error
reports from the device?
> + const struct i2c_device_id *id)
> +{
> + struct max98090_priv *max98090;
> + int ret;
> +
> + pr_info("max98090_i2c_probe\n");
No need for log messages like this - dev_dbg() at most.
> + max98090 = kzalloc(sizeof(struct max98090_priv), GFP_KERNEL);
> + if (max98090 == NULL)
> + return -ENOMEM;
devm_kzalloc() then you don't need to explicitly free() which will fix
leaks on error.
> +static int max98090_runtime_resume(struct device *dev)
> +{
> + struct max98090_priv *max98090 = dev_get_drvdata(dev);
> +
> + regcache_cache_only(max98090->regmap, false);
> +
> + max98090_reset(max98090);
> +
> + regcache_sync(max98090->regmap);
Do you realy need to reset the device here? If anything I'd expect it
on suspend since the reset state is probably the lowest power state.
next prev parent reply other threads:[~2013-01-17 2:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 15:13 [PATCH 002/002] ASoC: Replace max98090 Device Driver Jerry Wong
2013-01-17 2:53 ` Mark Brown [this message]
2013-01-23 17:33 ` Jerry Wong
[not found] ` <A453F1AE3B5DC14DB19666C506CE75A7108684F4C7@ITSVLEX06.it.maxim-ic.internal>
2013-01-25 7:21 ` Mark Brown
2013-01-25 15:39 ` Jerry Wong
2013-01-25 17:02 ` Jerry Wong
2013-01-26 7:15 ` Mark Brown
2013-01-26 7:12 ` Mark Brown
[not found] ` <A453F1AE3B5DC14DB19666C506CE75A7108684F4ED@ITSVLEX06.it.maxim-ic.internal>
2013-02-01 5:13 ` Jerry Wong
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=20130117025333.GA12645@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=Jerry.Wong@maximintegrated.com \
--cc=alsa-devel@alsa-project.org \
/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).