From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jarkko Nikula <jhnikula@gmail.com>
Cc: alsa-devel@alsa-project.org,
Peter Ujfalusi <peter.ujfalusi@nokia.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 13:41:52 +0000 [thread overview]
Message-ID: <20101126134151.GF30360@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20101126153548.a5a5f3c6.jhnikula@gmail.com>
On Fri, Nov 26, 2010 at 03:35:48PM +0200, Jarkko Nikula wrote:
> Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> > 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.
> Actually these are already well separated in current ASoC. Like my RFC
> patch didn't not need touch soc-dapm.c at all and efectively other
> changes were around codec probing/removal and by not registering the
> PCM.
That's pretty much where I'm coming from - we already have most of the
infrastructure, we just need to get the devices into the system but once
we do that we should be able to cope with everything already.
> > > 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?
> Yeah, true. Looks like wm9090.c doesn't need any conversion after we
> are able to register dailess codecs but those three can be then
> converted to use standard probing mechanism and let them register itself
> own widgets and controls. I.e. machine drivers don't need to call those
> tailored _add_controls functions.
Yup, WM9090 is a DAIless CODEC already as it's using the register cache.
The systems where it's typically deployed have a stub CODEC normally so
this happens to work as-is, it wouldn't work as-is otherwise.
next prev parent reply other threads:[~2010-11-26 13:42 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
2010-11-26 13:35 ` Jarkko Nikula
2010-11-26 13:41 ` Mark Brown [this message]
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=20101126134151.GF30360@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=jhnikula@gmail.com \
--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.