All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: KaiChieh Chuang <kaichieh.chuang@mediatek.com>
Cc: alsa-devel@alsa-project.org, garlic.tseng@mediatek.com,
	linux-mediatek@lists.infradead.org, chipeng.chang@mediatek.com,
	wsd_upstream@mediatek.com
Subject: Re: [PATCH v2 1/5] ASoC: add mt6351 codec driver
Date: Wed, 18 Apr 2018 17:40:40 +0100	[thread overview]
Message-ID: <20180418164040.GG10061@sirena.org.uk> (raw)
In-Reply-To: <20180416003252.4177-2-kaichieh.chuang@mediatek.com>


[-- Attachment #1.1: Type: text/plain, Size: 3244 bytes --]

On Mon, Apr 16, 2018 at 08:32:48AM +0800, KaiChieh Chuang wrote:

This looks pretty good, a couple of small things but nothing major here:

> +	offset = idx > old_idx ? idx - old_idx : old_idx - idx;
> +	reg_idx = old_idx;

These ternery statements would probably be clearer as regular if
statements.

> +/* dl pga gain */
> +static const char *const dl_pga_gain[] = {
> +	"8Db", "7Db", "6Db", "5Db", "4Db",
> +	"3Db", "2Db", "1Db", "0Db", "-1Db",
> +	"-2Db", "-3Db", "-4Db", "-5Db", "-6Db",
> +	"-7Db", "-8Db", "-9Db", "-10Db", "-40Db",
> +};

These gains should be put in TLVs rather than an enum so userspace can
handle them (also it should be dB not Db).  You can handle irregular
step sizes like these with DECLARE_TLV_DB_SCALE(), there's several
examples in the code already.

> +static int dl_pga_get(struct snd_kcontrol *kcontrol,
> +		      struct snd_ctl_elem_value *ucontrol)
> +{
> +	struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> +	struct mt6351_priv *priv = snd_soc_codec_get_drvdata(codec);
> +
> +	ucontrol->value.integer.value[0] = priv->ana_gain[kcontrol->id.device];
> +
> +	if (ucontrol->value.integer.value[0] == 0x1f)	/* reg idx for -40dB*/
> +		ucontrol->value.integer.value[0] = ARRAY_SIZE(dl_pga_gain) - 1;

Why do this rewriting?

> +/* ul pga gain */
> +static const char *const ul_pga_gain[] = {
> +	"0Db", "6Db", "12Db", "18Db", "24Db", "30Db",
> +};

This should be a regular control with a TLV too.

> +static const struct snd_kcontrol_new mt6351_snd_ul_controls[] = {
> +	MT_SOC_ENUM_EXT_ID("Audio_PGA1_Setting", ul_pga_enum[0],
> +			   ul_pga_get, ul_pga_set,
> +			   AUDIO_ANALOG_VOLUME_MICAMP1),

Volume controls should have names ending with " Volume" so userspace
knows how to handle them.

> +static int mt6351_codec_probe(struct snd_soc_codec *codec)
> +{
> +	struct mt6351_priv *priv = snd_soc_codec_get_drvdata(codec);
> +
> +	/* add codec controls */
> +	snd_soc_add_codec_controls(codec,
> +				   mt6351_snd_controls,
> +				   ARRAY_SIZE(mt6351_snd_controls));
> +	snd_soc_add_codec_controls(codec,
> +				   mt6351_snd_ul_controls,
> +				   ARRAY_SIZE(mt6351_snd_ul_controls));
> +
> +	mt6351_codec_init_reg(codec);
> +
> +	priv->ana_gain[AUDIO_ANALOG_VOLUME_HPOUTL] = 8;
> +	priv->ana_gain[AUDIO_ANALOG_VOLUME_HPOUTR] = 8;
> +	priv->ana_gain[AUDIO_ANALOG_VOLUME_MICAMP1] = 3;
> +	priv->ana_gain[AUDIO_ANALOG_VOLUME_MICAMP2] = 3;
> +
> +	return 0;
> +}

Can we read the configuration of the device back from the hardware?
It's better to just use the defaults rather than set things up for a
particular use case, that way there's a standard that can be agreed even
if it's not good for every use case.

> +static struct snd_soc_codec_driver mt6351_soc_codec_driver = {
> +	.probe = mt6351_codec_probe,
> +	.get_regmap = mt6351_get_regmap,

We're just about to remove CODEC drivers entirely and replace them with
components - nothing else is using the get_regmap() callback.  Do you
really need that callback, if you do we should just add it to the
component interface?

> +	priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +	if (IS_ERR(priv->regmap))
> +		return PTR_ERR(priv->regmap);

This should be the default behaviour so I'm guessing you don't need the
callback?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2018-04-18 16:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16  0:32 [PATCH v2 0/5] ASoC: mediatek: add support for mt6797 SoC KaiChieh Chuang
     [not found] ` <20180416003252.4177-1-kaichieh.chuang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2018-04-16  0:32   ` [PATCH v2 1/5] ASoC: add mt6351 codec driver KaiChieh Chuang
2018-04-18 16:40     ` Mark Brown [this message]
2018-04-19  1:58       ` KaiChieh Chuang
2018-04-19 14:41         ` Mark Brown
2018-04-20  6:54           ` KaiChieh Chuang
2018-04-20 23:49       ` KaiChieh Chuang
2018-04-23 11:39         ` Mark Brown
2018-04-16  0:32   ` [PATCH v2 2/5] ASoC: mt6797: add structure define and clock control function for 6797 KaiChieh Chuang
2018-04-16  0:32   ` [PATCH v2 3/5] ASoC: mt6797: add mt6797 platform driver KaiChieh Chuang
2018-04-18 16:46     ` Mark Brown
2018-04-19  1:51       ` KaiChieh Chuang
2018-04-19 11:29         ` Mark Brown
2018-04-16  0:32   ` [PATCH v2 4/5] ASoC: add mt6797-mt6351 driver and config option KaiChieh Chuang
2018-04-16  0:32 ` [PATCH v2 5/5] ASoC: mediatek: add documents for mt6797 KaiChieh Chuang
2018-04-18 16:46 ` [PATCH v2 0/5] ASoC: mediatek: add support for mt6797 SoC 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=20180418164040.GG10061@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=chipeng.chang@mediatek.com \
    --cc=garlic.tseng@mediatek.com \
    --cc=kaichieh.chuang@mediatek.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=wsd_upstream@mediatek.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.