Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: alsa-devel@alsa-project.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs
Date: Fri, 26 Nov 2010 14:19:42 +0200	[thread overview]
Message-ID: <201011261419.42933.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <20101126092524.ea7cf74d.jhnikula@gmail.com>

Hi,

On Friday 26 November 2010 09:25:24 ext Jarkko Nikula wrote:
> And codecs can be used as an amplifer only by not connecting the DAI.
> Like if codec chip is cheaper or better available than amplifier or if
> multicodec package saves board space compared to separate codec and
> amplifier chips.

We could as well see these things as components on the audio path.
A standard CODEC would have DAI + DAPM (analog/digital routings, amps) + gain 
controls.
In case of an external amplifier we only have the DAPM part + gain control.

If a component has DAI, than the normal PCM operations would apply to them, if 
the component does not have DAI, than those are not applicable.
I'm not sure, but I think we do have some level of separation of DAPM and PCM 
operations, right? So why not to utilize, and extend that route?
All component drivers would use the same registration, core would knows which 
component has DAI, and which does not. Machine driver could specify a list of 
components, provides the DAPM connection between the components.

If DAPM core knows which widget belongs to which component, than I see no real 
problem with this method. The DAPM would work just fine. The PCM operatins would 
only apply to component with DAI.

> If I counted correctly we have currently only three amplifier drivers:
> tpa6130a2.c, wm2000.c and wm9090.c so separation doesn't sound worth of
> trouble at this point as the core serves well those cases also.

One more: max9877, if I recall correctly that was the first amp driver?

-- 
Péter

  reply	other threads:[~2010-11-26 12:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 15:47 [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs Jarkko Nikula
2010-11-25 19:18 ` Liam Girdwood
2010-11-25 21:32   ` Mark Brown
2010-11-26  7:25     ` Jarkko Nikula
2010-11-26 12:19       ` Peter Ujfalusi [this message]
2010-11-26 13:35         ` Jarkko Nikula
2010-11-26 13:41           ` Mark Brown
2010-11-26 13:55             ` Peter Ujfalusi
2010-11-26 13:59               ` Mark Brown
2010-11-26 14:14               ` Jarkko Nikula
2010-11-28 11:50 ` Mark Brown
2010-11-30 14:43   ` Mark Brown

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=201011261419.42933.peter.ujfalusi@nokia.com \
    --to=peter.ujfalusi@nokia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@slimlogic.co.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox