From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Prchal Jiří" <jiri.prchal@aksignal.cz>
Cc: vbarinov@embeddedalley.com, alsa-devel@alsa-project.org,
sudhakar.raj@ti.com, nsekhar@ti.com, peter.ujfalusi@ti.com,
mr.swami.reddy@ti.com, lrg@ti.com
Subject: Re: [PATCH] ASoC: tlv320aic3x: add AGC, MIC_BIAS
Date: Wed, 27 Jun 2012 12:25:23 +0100 [thread overview]
Message-ID: <20120627112523.GE308@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FEABABC.9040309@aksignal.cz>
[-- Attachment #1.1: Type: text/plain, Size: 3666 bytes --]
On Wed, Jun 27, 2012 at 09:48:12AM +0200, Prchal Jiří wrote:
Please fix your mailer to word wrap within paragraphs, I've reflowed
your text for legibility.
> Dne 26.6.2012 15:17, Mark Brown napsal(a):
> >On Tue, Jun 26, 2012 at 03:04:27PM +0200, Prchal Jiří wrote:
> >Please move everything out of the big array or if you insist on having
> >the array then use the indexes in the assignments. Otherwise the code
> >is just error prone and hard to read.
> I just add some elements to big array.
> As I see in other codec drivers (e.g. wm9713) there are big arrays too.
> I think it's more readable to use symbolic names instead of indexes.
I'm saying it's even better not to use an enormous array at all and you
should fix that up rather than extend it (especially given that you're
using a different style to the existing controls). Only a few old
drivers still use the magic array indexes.
> >>+ SOC_ENUM("Mic Bias", aic3x_enum[MIC_BIAS_ENUM]),
> >No, this should be platform data or done with a callback from the
> >machine driver. It's very unlikely that it's sensible to vary at
> >runtime without coordination with other driver code.
> I don't know how, can you, please, suggest me. There are three levels of voltage.
There are numerous examples of platform data in the kernel...
> >>+ /* set to avoid artifacts on the audio output during power-on/off */
> >>+ snd_soc_write(codec, AIC3X_HEADSET_DETECT_CTRL_B, 0x80); /*ac-coupled*/
> >>+ snd_soc_write(codec, HPOUT_POP_REDUCTION, 0x4e); /* 10 + 4 ms, reference*/
> >>+ /* short circuit protection */
> >>+ snd_soc_write(codec, HPRCOM_CFG, 0x04);
> >This appears to be unrelated to the change. What is it for?
> This sets default values and I think it would be nice to have
> defaultly reduced pops-up and short circuit protection.
So it is as I said totally unrelated to the rest of your change and
should be sent separately. As covered in SubmittingPatches don't make
multiple unrelated changes in a single commit, it is especially bad if
you don't even mention some of them.
> >> /* DAC to Mono Line Out default volume and route to Output mixer */
> >>- snd_soc_write(codec, DACL1_2_MONOLOPM_VOL, DEFAULT_VOL | ROUTE_ON);
> >>- snd_soc_write(codec, DACR1_2_MONOLOPM_VOL, DEFAULT_VOL | ROUTE_ON);
> >>+ /* mix both channels with -6dB level */
> >>+ snd_soc_write(codec, DACL1_2_MONOLOPM_VOL, (DEFAULT_VOL + 12) | ROUTE_ON);
> >>+ snd_soc_write(codec, DACR1_2_MONOLOPM_VOL, (DEFAULT_VOL + 12) | ROUTE_ON);
> >This is also an unrelated change to the chip defaults (which we were
> >overriding anyway when we shouldn't be...). Code like this should just
> >be removed completely.
> No, correct mixing two channels to one is 1/2 + 1/2. 1/2 = -6dB.
I'm not sure how that follows on from what I said? To repeat, the code
you're changing shouldn't be here in the first place and what you're
doing is unrelated to the rest of your change.
> >>+ /* AGC to -10dB, 20 / 500ms, no clip stepping, noise gate -90dB, hysteresis 3dB*/
> >>+ snd_soc_write(codec, LAGC_CTRL_A, 0x2f);
> >>+ snd_soc_write(codec, RAGC_CTRL_A, 0x2f);
> >>+ snd_soc_write(codec, LAGC_CTRL_C, 0xbe);
> >>+ snd_soc_write(codec, RAGC_CTRL_C, 0xbe);
> >Again, just use the chip defaults and let the user override.
> Originally the driver sets many defaults to hear playback, because
> after reset defaults won't hear anything and user need to set many
> switches and volumes. Maybe is not necessary to set AGC here.
All this code in the driver should be removed, the driver should leave
the device in the default state for the most part.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2012-06-27 11:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 13:04 [PATCH] ASoC: tlv320aic3x: add AGC, MIC_BIAS Prchal Jiří
2012-06-26 13:17 ` Mark Brown
2012-06-27 7:48 ` Prchal Jiří
2012-06-27 11:25 ` Mark Brown [this message]
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=20120627112523.GE308@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=jiri.prchal@aksignal.cz \
--cc=lrg@ti.com \
--cc=mr.swami.reddy@ti.com \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=sudhakar.raj@ti.com \
--cc=vbarinov@embeddedalley.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.