All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] ASoC: tpa6130a2: Define output pins with SND_SOC_DAPM_OUTPUT
Date: Thu, 20 May 2010 08:21:26 -0700	[thread overview]
Message-ID: <20100520152125.GA8357@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <201005200903.53926.peter.ujfalusi@nokia.com>

On Thu, May 20, 2010 at 09:03:53AM +0300, Peter Ujfalusi wrote:
> On Wednesday 19 May 2010 18:05:12 ext Mark Brown wrote:

> I guess my reasoning was to avoid the following DAPM route, which for me seamed 
> weird:
> soc codec                        |      tap6130a2        |   machine driver
> codec_DAC -> .. -> codec_OUTPUT -> tpa_PGA -> tpa_OUTPUT -> machine_HP

> It seamed wrong to have codec_OUTPUT and tpa_OUTPUT in the same DAPM route.

That seems absolutely fine to me - it's something I'd expect to happen
as we move into a multi-chip ASoC world, you'll have signals which go
out of one chip and into another before going to the edge of the system.
The output wigdget is the output of one chip but there's no reason you
can't use it as an input for another chip.

> > They may also wish to use the event that is available on the jack widget to
> > perform some board specific action when the headphone is activated.

> The event is _usually_ needed to toggle the power for the amp (enable/disable).
> The power for the tpa is managed within the driver, so no additional enable is 
> needed.

Well, usually the event is completely unused and the headphone widget is
entirely ornamental.

> > There's no actual requirement to define headphone widgets if they don't
> > have any other code associated with them - if the outputs are left
> > unconnected the effect will be the same as if a noop and unused
> > headphone widget were there.

> That is true, but in that case why would anyone add the tpa amp to their DAPM 
> route in the first place (when it is not connected)?

They wouldn't, I'm just saying that having the extra headphone widget on
the end is not a requirement for anything to function.

  reply	other threads:[~2010-05-20 15:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 10:55 [PATCH] ASoC: tpa6130a2: Define output pins with SND_SOC_DAPM_OUTPUT Jarkko Nikula
2010-05-19 12:00 ` Peter Ujfalusi
2010-05-19 13:46   ` Jarkko Nikula
2010-05-19 15:05   ` Mark Brown
2010-05-20  6:03     ` Peter Ujfalusi
2010-05-20 15:21       ` Mark Brown [this message]
2010-05-19 14:56 ` Mark Brown
2010-05-19 15:39 ` Liam Girdwood

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=20100520152125.GA8357@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=peter.ujfalusi@nokia.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.