public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Liam Girdwood <lrg@ti.com>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Dimitris Papastamos <dp@opensource.wolfsonmicro.com>,
	Mike Frysinger <vapier@gentoo.org>,
	Daniel Mack <zonque@gmail.com>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	qi.wang@intel.com, yong.y.wang@intel.com, joel.clark@intel.com,
	kok.howg.ewe@intel.com
Subject: Re: [PATCH v2] sound/soc/codecs: add LAPIS Semiconductor ML26124
Date: Fri, 25 Nov 2011 14:28:58 +0000	[thread overview]
Message-ID: <20111125142858.GE5315@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1322224743-15671-1-git-send-email-tomoya.rohm@gmail.com>

On Fri, Nov 25, 2011 at 09:39:03PM +0900, Tomoya MORINAGA wrote:

This is better than the previous version but the major issue is that the
driver isn't really fitting in with the subsystem - it's still relying
on hard coded register write sequences for example.

> ML26124-01HB/ML26124-02GD is 16bit monaural audio CODEC which has high
> resistance to voltage noise. On chip regulator realizes power supply rejection
> ratio (PSRR) be over 90dB so more than 50dB is improved than ever. ML26124-01HB/

You should fix the word wrapping in your commit message to be well
within 80 columns.

> +struct ml26124_priv {
> +	enum snd_soc_control_type control_type;

Since the device only supports I2C you should just unconditionally use
I2C.  You should also use regmap for register access.

> +static const struct snd_kcontrol_new ml26124_snd_controls[] = {
> +	SOC_SINGLE_TLV("Capture Digital Volume", ML26124_RECORD_DIG_VOL, 0, 0xff, 1, rec_play_digi_vol),
> +	SOC_SINGLE_TLV("Playback Digital Volume", ML26124_PLBAK_DIG_VOL, 0, 0xff, 1, rec_play_digi_vol),

> +	SOC_SINGLE("Digital Volume Switch", ML26124_FILTER_EN, 4, 1, 0),

This needs either a Playback or Capture in there to match up with the
above unless it genuinely does mute both which would be really weird.

> +	SND_SOC_DAPM_VMID("VMID"),

Remove this unless it's actually used in your routing.

> +	SND_SOC_DAPM_MICBIAS("MICBIAS", ML26124_PW_REF_PW_MNG, 0, 0),

This should be a supply widget, MICBIAS widgets are legacy.

> +	SND_SOC_DAPM_MIXER("Output Mixer", ML26124_PW_SPAMP_PW_MNG, 0x1f, 0, 
> +			   &ml26124_output_mixer_controls[0],
> +			   ARRAY_SIZE(ml26124_output_mixer_controls)),

Do you *really* have a shift of 0x1f for the enable bit?

> +static int ml26124_snd_card_codec_set(int number, struct ml26124_priv *priv,
> +				      struct snd_soc_codec *codec)
> +{
> +	unsigned char data;
> +	unsigned int rate = priv->rate;
> +	unsigned int channels = priv->ch;
> +
> +	data = snd_soc_read(codec, ML26124_PW_MICBIAS_VOL);
> +	snd_soc_update_bits(codec, ML26124_SW_RST, 0x01, 1);	/* soft reset assert */
> +	snd_soc_update_bits(codec, ML26124_SW_RST, 0x01, 0);	/* soft reset negate */
> +
> +	snd_soc_update_bits(codec, 0x0c, 0x1f, 0);	/* Stop clock  */

The same issue as with your previous submission applies to this function
- you shouldn't have hard coded register write sequences in your code,
the driver should use the facilities of the subsystem to allow the user
to configure it at runtime.  Given how big an issue this is I've stopped
reading at this point.

  parent reply	other threads:[~2011-11-25 14:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-25 12:39 [PATCH v2] sound/soc/codecs: add LAPIS Semiconductor ML26124 Tomoya MORINAGA
2011-11-25 13:04 ` Lars-Peter Clausen
2011-11-25 14:28 ` Mark Brown [this message]
2011-11-28  9:44   ` Tomoya MORINAGA
2011-11-28 11:34     ` 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=20111125142858.GE5315@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=dp@opensource.wolfsonmicro.com \
    --cc=joel.clark@intel.com \
    --cc=kok.howg.ewe@intel.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=perex@perex.cz \
    --cc=qi.wang@intel.com \
    --cc=tiwai@suse.de \
    --cc=tomoya.rohm@gmail.com \
    --cc=vapier@gentoo.org \
    --cc=yong.y.wang@intel.com \
    --cc=zonque@gmail.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