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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox