All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Nikula <jarkko.nikula@nokia.com>
To: ext Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org
Subject: Re: [PATCH] ASoC: Clarify API for bias configuration
Date: Tue, 20 May 2008 12:53:25 +0300	[thread overview]
Message-ID: <20080520125325.b17ba0b3.jarkko.nikula@nokia.com> (raw)
In-Reply-To: <20080519183654.GB30712@sirena.org.uk>

On Mon, 19 May 2008 19:36:55 +0100
"ext Mark Brown" <broonie@opensource.wolfsonmicro.com> wrote:

> Bias here is being used to refer to general DC offset levels on the AC
> inputs and outputs of the chip - microphone bias is just one of these
> levels.  For a lot of codecs there's no or limited control of the
> baises but some do provide fine grained control.
> 
It came to my mind only afterwards but probably usual set_power
convention fits here well, doesn't confuse with DAPM and doesn't limit
to thinking only mic bias :-)

> The tlv320aicx driver is fairly unusual in controlling the PLL here,
> though it shouldn't cause any problems either.  Incidentally, it looks
> like this needs updating to reflect the support that was added for
> bypassing the PLL - presumably if the PLL is bypassed then enabling it
> during playback and record will consume power needlessly?
> 
Ah, you are right. There seems to be needless PLL power-up between
dapm_event and aic3x_hw_params in case of PLL bypass even the
aic3x_hw_parms disables it.

Also how on earth I was able to test my ASoC drivers for OMAP in case
of codec slave since driver is enabling PLL only for master case.
Hmm... what a hack I was using then.

Seems that some fixes are needed there.

> Most drivers expose clocking configuration like the PLL to machine
> drivers in order to allow use of clocks generated on the codec
> independently of the audio stream - if it's not needed outside of
>
Some integrated chips might require it as well if there is some
(undocumented) interdependencies inside the integrated chip. IRCC e.g.
TSC2301 keypad and touchscreen were using audio clock in some occasions.


Jarkko

  reply	other threads:[~2008-05-20  9:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-19 10:20 [PATCH] ASoC: Remove in-code changelogs Mark Brown
2008-05-19 10:20 ` [PATCH] ASoC: Clarify API for bias configuration Mark Brown
2008-05-19 10:20   ` [PATCH] ASoC: Make CPU and codec DAI operations have same type Mark Brown
2008-05-19 10:20     ` [PATCH] ASoC: core checkpatch cleanups Mark Brown
2008-05-19 14:15   ` [PATCH] ASoC: Clarify API for bias configuration Jarkko Nikula
2008-05-19 18:36     ` Mark Brown
2008-05-20  9:53       ` Jarkko Nikula [this message]
2008-05-22 23:34         ` Mark Brown
2008-05-23  8:01           ` Jarkko Nikula
2008-05-26 10:07             ` Mark Brown
2008-05-19 10:26 ` [PATCH] ASoC: Remove in-code changelogs Ben Dooks
2008-05-19 10:37 ` Takashi Iwai

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=20080520125325.b17ba0b3.jarkko.nikula@nokia.com \
    --to=jarkko.nikula@nokia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=tiwai@suse.de \
    /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.