From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: "Koul, Vinod" <vinod.koul@intel.com>
Cc: "tiwai@suse.de" <tiwai@suse.de>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Harsha, Priya" <priya.harsha@intel.com>,
"lrg@slimlogic.co.uk" <lrg@slimlogic.co.uk>
Subject: Re: [RFC 1/4] ASoC SST: Add msic codec driver
Date: Tue, 28 Dec 2010 15:54:39 +0000 [thread overview]
Message-ID: <20101228155439.GA905@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <438BB0150E931F4B9CE701519A44630104C104CF80@bgsmsx502.gar.corp.intel.com>
On Tue, Dec 28, 2010 at 09:06:28PM +0530, Koul, Vinod wrote:
> On Tue, Dec 28, 2010 at 08:18:27PM +0530, Mark Brown wrote:
> > > sound/soc/codecs/msic.h | 102 +++++++
> > > 2 files changed, 823 insertions(+), 0 deletions(-)
> > Makefile and Kconfig too please.
> We added all make and kconfig changes in patch4, if you want this to be per
> driver basic, next time I will do that way
Certainly for the CODEC driver. For the platform stuff that's fine.
> Along with read and write the platform provides update bits api. So internally I
> call this when I want to update a bit (instead of soc_update which does and read
> and then write)
It'd still be easier to read the code if you used the standard APIs.
> On this I have a proposal if system provides a modify api can we add one more
> function and use that in update bits. Like:
> snd_soc_update_bits()
> {
> if (codec->modif)
> codec->modify(....)
> rest of current update logic...
> }
I'm not sure it's worth it; I'd be more worried about the drivers
implementing this badly than anything else. It's also not going to play
well with the register cache stuff.
> > > + /*adding pcm 2 here for a while*/
> > > + msic_modify(codec, MSIC_PCM2C2, BIT(0), BIT(0));
> > > + break;
> > Hrm?
> This is PCM enable which I initially added in codec map and caused problems,
> hence the comment. Does this look apt in this place?
At least explain what the code is doing and why it's temporary. The
comment isn't terribly clear.
> > Most of these look like they're just plain mute controls which would
> > more normally be represented as regular sound controls not related to
> > power, leaving these controls as PGAs (which is what they mostly appear
> > to be). That would make the sequencing better, I expect, and would give
> > stereo controls to the application layer which is more normal.
> So what you are proposing is to add these playback switches as PGAs?
> These are actually the output driver enable switches which should be turned on
> only when stream is active, hence added these as DAPM_SWITCH.
If they're power controls they shouldn't be user visible switches at all
and should be PGA widgets.
> > > + /*fix the initial volume at 0dB*/
> > > + msic_write(codec, MSIC_HSLVOLCTRL, 0x08);
> > > + msic_write(codec, MSIC_HSRVOLCTRL, 0x08);
> > > + msic_write(codec, MSIC_IHFLVOLCTRL, 0x08);
> > > + msic_write(codec, MSIC_IHFRVOLCTRL, 0x08);
> > Leave these at the hardware defaults; 0dB may not be appropriate for
> > other systems (it seems rather loud for a headphone output...).
> The h/w default is +9dB hence setting it to 0.
Fail; I'm assuming this is extremely loud - if it is then please add a
comment explaining what the problem with the hardware defaults is and
why you're working around it. It may be worth considering going to the
other extreme and muting by default.
> > > + /*dac mode and lo w/a*/
> > > + msic_write(codec, MSIC_SSR2, 0x10);
> > > + msic_write(codec, MSIC_SSR3, 0x40);
> > "lo w/a"?
> Lineout w/a, unless we program these they don't work as intended :(
"w/a" isn't very clear.
next prev parent reply other threads:[~2010-12-28 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-28 12:09 [RFC 1/4] ASoC SST: Add msic codec driver Koul, Vinod
2010-12-28 14:48 ` Mark Brown
2010-12-28 15:36 ` Koul, Vinod
2010-12-28 15:54 ` Mark Brown [this message]
2010-12-28 15:59 ` Koul, Vinod
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=20101228155439.GA905@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@slimlogic.co.uk \
--cc=priya.harsha@intel.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.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.