All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Oder Chiou <oder_chiou@realtek.com>
Cc: "Jack Yu" <jack.yu@realtek.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"Shuming [范書銘]" <shumingf@realtek.com>,
	"Bard Liao" <bardliao@realtek.com>, Flove <flove@realtek.com>
Subject: Re: [PATCH] ASoC: rt5660: add rt5660 codec driver
Date: Mon, 19 Sep 2016 10:23:13 +0100	[thread overview]
Message-ID: <20160919092313.GH10189@sirena.org.uk> (raw)
In-Reply-To: <7EB0DE829A537248AF2ED30C97D12694010056A8@RTITMBSV03.realtek.com.tw>


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

On Mon, Sep 19, 2016 at 03:11:00AM +0000, Oder Chiou wrote:
> > On Tue, Aug 23, 2016 at 01:33:43PM +0800, Oder Chiou wrote:

> > > +- realtek,use-ldo2

> > This would more normally be done by making LDO2 a regulator via the
> > normal regulator framework - look at how the arizona drivers handle
> > DCVDD for an example, it provides a default supply mapping which makes
> > things really easy for users.  Right now it's not clear to me looking at
> > the code that the driver works for systems that don't use an internal
> > LDO as there's nothing that enables MICVDD.

> The LDO2 is not a regulator, and it is an internal LDO of codec that
> controlled by register setting. Normally, the MICVDD is connected to 3.3V

It's an internal regulator in the CODEC.

> VDD directly, and it isn't controlled by regulator. The option
> "realtek,use-ldo2" is depend on the customer that can decide that the MICVDD
> is provided by external 3.3V VDD or internal LDO2 for it. If they used the
> internal LDO2, the pin of MICVDD can be floated.

Sure, that's exactly what it looks like so my comments above apply.

> > We do a reset when we unregister at the CODEC level - that'll overwrite
> > these settings won't it?

> We have done it in the function "rt5660_remove".

Right, and if the user removes and reloads the driver then the reset
will happen.

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

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



      parent reply	other threads:[~2016-09-19  9:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  5:33 [PATCH] ASoC: rt5660: add rt5660 codec driver Oder Chiou
2016-09-14 16:31 ` Mark Brown
     [not found]   ` <7EB0DE829A537248AF2ED30C97D12694010056A8@RTITMBSV03.realtek.com.tw>
2016-09-19  9:23     ` 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=20160919092313.GH10189@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bardliao@realtek.com \
    --cc=flove@realtek.com \
    --cc=jack.yu@realtek.com \
    --cc=lgirdwood@gmail.com \
    --cc=oder_chiou@realtek.com \
    --cc=shumingf@realtek.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.