From: Mark Brown <broonie@kernel.org>
To: Kevin Cernekee <cernekee@chromium.org>
Cc: lgirdwood@gmail.com, dgreid@chromium.org,
Andrew Bresticker <abrestic@chromium.org>,
Olof Johansson <olofj@chromium.org>,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers
Date: Sat, 18 Apr 2015 18:11:37 +0100 [thread overview]
Message-ID: <20150418171137.GY26185@sirena.org.uk> (raw)
In-Reply-To: <CAJzqFtYVd+jHesoNnG47ftoK9SWYUmXwDXpf2==s3Rv1ewpsYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]
On Sat, Apr 18, 2015 at 09:16:36AM -0700, Kevin Cernekee wrote:
> On Sat, Apr 18, 2015 at 4:36 AM, Mark Brown <broonie@kernel.org> wrote:
> >> +static int tas571x_set_sysclk(struct snd_soc_dai *dai,
> >> + int clk_id, unsigned int freq, int dir)
> > Remove empty functions, at best they waste space at worst they break
> > things.
> Without the empty function, we run into problems with drivers that
> abort when they get -ENOTSUPP here:
> sound/soc/atmel/atmel_wm8904.c: ret =
> snd_soc_dai_set_sysclk(codec_dai, WM8904_CLK_FLL,
> sound/soc/atmel/atmel_wm8904.c- 0, SND_SOC_CLOCK_IN);
> sound/soc/atmel/atmel_wm8904.c- if (ret < 0) {
> sound/soc/atmel/atmel_wm8904.c- pr_err("%s -failed to set
> wm8904 SYSCLK\n", __func__);
> sound/soc/atmel/atmel_wm8904.c- return ret;
> sound/soc/atmel/atmel_wm8904.c- }
Someone trying to use the atmel_wm8904 driver with something other than
a wm8904 shouldn't really be expecting a good experince...
> Is there a stub version that I can use instead? Nothing jumped out at
> me when looking at the other codec drivers.
No, such a stub would make no sense - why would we put a stub in all the
drivers rather than just making the core do the right thing?
> >> + /*
> >> + * The master volume defaults to 0x3ff (mute), but we ignore
> >> + * (zero) the LSB because the hardware step size is 0.125 dB
> >> + * and TLV_DB_SCALE_ITEM has a resolution of 0.01 dB.
> >> + */
> >> + if (regmap_write(priv->regmap, TAS571X_MVOL_REG, 0x3fe))
> >> + return -EIO;
> > I don't understand this - is the LSB a mute bit or sommething?
> The 10-bit master volume field on 5717/5719 works like:
> 0x3ff: MUTE (power-on default)
> 0x3fe: -103.750 dB
> 0x3fd: -103.625 dB
> [lots more options, in 0.125 dB increments]
> 0x001: 23.875 dB
> 0x000: 24.000 dB
> Since we only have a resolution of 0.01 dB, the driver forces the LSB
> to 0 and uses 0.25 dB increments instead of 0.125 dB. Mute is handled
> through the dedicated per-channel soft mute register bits instead of
> the 0x3ff volume setting.
It's not entirely clear to me why we need to reset the bit, or why if
we're just trying to update that one bit we write the entire register
value rather than use _update_bits(). If the goal is just to change
that one bit then _update_bits() would be a lot clearer.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-04-18 17:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 21:42 [PATCH 1/3] ASoC: tas571x: Add DT binding document Kevin Cernekee
2015-04-15 21:42 ` [PATCH 2/3] ASoC: tas571x: New driver for TI TAS571x power amplifiers Kevin Cernekee
2015-04-16 12:57 ` [alsa-devel] " Lars-Peter Clausen
2015-04-18 11:39 ` Mark Brown
2015-04-20 20:56 ` Kevin Cernekee
2015-04-20 21:14 ` Mark Brown
2015-04-18 11:36 ` Mark Brown
2015-04-18 16:16 ` Kevin Cernekee
2015-04-18 17:11 ` Mark Brown [this message]
2015-04-18 20:07 ` Kevin Cernekee
2015-04-20 12:21 ` Mark Brown
2015-04-20 15:12 ` Kevin Cernekee
2015-04-20 16:05 ` Andrew Bresticker
2015-04-20 20:14 ` Mark Brown
2015-04-24 0:47 ` Kevin Cernekee
2015-04-24 9:28 ` Mark Brown
2015-04-24 13:52 ` Kevin Cernekee
2015-04-24 16:50 ` Mark Brown
2015-04-15 21:42 ` [PATCH 3/3] MAINTAINERS: Add entry for tas571x ASoC codec driver Kevin Cernekee
2015-04-18 11:16 ` [PATCH 1/3] ASoC: tas571x: Add DT binding document Mark Brown
2015-04-20 21:16 ` Kevin Cernekee
2015-04-20 21:18 ` Kevin Cernekee
2015-04-20 22:03 ` Mark Brown
2015-04-20 22:48 ` Kevin Cernekee
2015-04-21 16:45 ` 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=20150418171137.GY26185@sirena.org.uk \
--to=broonie@kernel.org \
--cc=abrestic@chromium.org \
--cc=alsa-devel@alsa-project.org \
--cc=cernekee@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=dgreid@chromium.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olofj@chromium.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
all inboxes | Powered by JetHome®