[alsa-devel] [RFC 0/4] ASoC DSP topology

[Vinod Koul]

On Tue, Apr 21, 2015 at 05:39:42PM +0100, Mark Brown wrote:
> On Tue, Apr 21, 2015 at 04:23:51PM +0100, Liam Girdwood wrote:
> > On Tue, 2015-04-21 at 15:30 +0300, Peter Ujfalusi wrote:
> 
> > > We have discussed this with Liam in the past: in my view the DSP topology (or
> > > Dynamic FW) should be represented in the machine level and it would be the
> > > best if the same image could carry card level widgets routes and links. If you
> > > have big enough change in the FW and it's provided widgets/PCMs you would need
> > > separate machine driver or at least a way to have different set of machine
> > > level routes, widgets, links, etc for different DSP topology file.
> 
> > The component level allows us to target the physical component devices
> > that may have runtime definable topologies. This would include codecs
> > too, since some vendors are making codecs with built in FW (maybe TI
> > too ?). The machine level more represents the board HW topology and this
> > should be derived from ACPI or DT.
> 
> I tend to agree.  We should let each vendor provide their own topology
> information - if they need to do something with this (which does seem
> unlikely) system integrators should be on an equal footing with silicon
> vendors here, and we shouldn't be encouraging systems where we need
> per-board firmware definitions for the silicon components just because
> the board has differences.
One case which comes to my mind worth discussing here is PCMs.

We are trying to move FE dialink PCMs to toplogy as that is SW defined and
IMO not linked to HW.
So machine driver will not have dailinks to register at probe so we can't get
sound card created (other info like widgets map can get get registered after
probe though)

I was thinking that in core, a component should register with a toplogy bin
as well. Core can load (or with a callback) the toplogy binary and then parse it for
PCMs register them, and create sound card...

thoughts...

-- 
~Vinod
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150422/62c88cf1/attachment.sig>