All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Matt Porter <mporter@konsulko.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ASoC: add tda7419 audio processor driver
Date: Wed, 28 Feb 2018 11:00:38 +0000	[thread overview]
Message-ID: <20180228110038.GA6722@sirena.org.uk> (raw)
In-Reply-To: <20180227225128.17815-3-mporter@konsulko.com>

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

On Tue, Feb 27, 2018 at 05:51:28PM -0500, Matt Porter wrote:

> +static bool tda7419_writeable_reg(struct device *dev, unsigned int reg)
> +{
> +	return true;
> +}

This is the default behaviour, may as well omit it (but equally it does
no harm).

> +static inline int tda7419_vol_get_value(int val, unsigned int mask,
> +					int thresh, unsigned int invert)
> +{
> +	val &= mask;
> +	if (val < thresh) {
> +		if (invert)
> +			val = 0 - val;
> +	} else if (val > thresh) {

This feels like something some other device might want to use so might
warrant pulling out into a general control at some point but I'd not
insist on doing it now.

> +static struct snd_kcontrol_new tda7419_controls[] = {
> +SOC_ENUM("Main Source Select", soc_enum_main_src_sel),

Should this be a DAPM route?

> +SOC_SINGLE("Main Source AutoZero", TDA7419_MAIN_SRC_REG,
> +	   TDA7419_MAIN_SRC_AUTOZERO, 1, 1),

There's a lot of on/off switches for various things in here - these
should all have Switch at the end of their names so that userspace can
see how it's expected to display them.  Most of the controls with a max
value of 1 probably fall into this category.

> +SOC_SINGLE("Clock Fast Mode", TDA7419_MUTE_CLK_REG,
> +	   TDA7419_CLK_FAST_MODE, 1, 1),

What does this do - should it be in set_sysclk() or something?

> +	/* Configure registers */
> +	regmap_write(tda7419->regmap, TDA7419_VOLUME_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_MIXING_GAIN_REG, 0x0f);
> +	regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LF_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RF_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_LR_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_RR_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_MIXING_LEVEL_REG, 0xe0);
> +	regmap_write(tda7419->regmap, TDA7419_ATTENUATOR_SUB_REG, 0xe0);

This looks like it's setting default volumes - just leave those at the
chip defaults and let userspace handle setting them, what works for one
board may be totally inappropriate on another board and using the chip
default means we've got some fixed thing we don't need to discuss.

> +static int tda7419_remove(struct i2c_client *i2c)
> +{
> +	int i;
> +	struct tda7419_data *tda7419 = i2c_get_clientdata(i2c);
> +
> +	/* Reset registers to defaults */
> +	for (i = 0; i < ARRAY_SIZE(tda7419_regmap_defaults); i++)
> +		regmap_write(tda7419->regmap,
> +			     tda7419_regmap_defaults[i].reg,
> +			     tda7419_regmap_defaults[i].def);

Why are we doing this?  Other drivers don't do it...  if anything I'd
expect a reset on probe in case the bootloader or something left the
chip configured.

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

  reply	other threads:[~2018-02-28 11:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-27 22:51 [PATCH 0/2] TDA7419 audio processor driver Matt Porter
2018-02-27 22:51 ` [PATCH 1/2] ASoC: add tda7419 audio processor binding Matt Porter
2018-03-05 22:29   ` Rob Herring
2018-03-09 14:39     ` Matt Porter
2018-03-09 14:39       ` Matt Porter
2018-02-27 22:51 ` [PATCH 2/2] ASoC: add tda7419 audio processor driver Matt Porter
2018-02-28 11:00   ` Mark Brown [this message]
2018-03-09 14:35     ` Matt Porter
2018-03-09 14:35       ` Matt Porter
2018-03-09 15:29       ` Mark Brown
2018-03-18 17:21         ` Matt Porter
2018-03-18 17:21           ` Matt Porter
2018-03-02 22:48   ` kbuild test robot
2018-03-02 22:48   ` [PATCH] ASoC: fix boolreturn.cocci warnings kbuild test robot

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=20180228110038.GA6722@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mporter@konsulko.com \
    --cc=perex@perex.cz \
    --cc=robh+dt@kernel.org \
    --cc=tiwai@suse.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.