[alsa-devel] [PATCH] ASoC: core: Add support for DAI driver DAI widgets.

[Mark Brown]

On Thu, Mar 08, 2012 at 12:07:00PM +0000, Liam Girdwood wrote:
> On Wed, 2012-03-07 at 20:37 +0000, Mark Brown wrote:

> > So what this is doing is the above which is really about synthesising a
> > name for streams where the driver didn't provide one.  This isn't
> > specific to CPU DAIs, it'll apply just as well to CODEC DAIs that don't
> > specify a per stream name for whatever reason.  

> yes, but it's more about creating a DAPM DAI widget for DAIs that are
> not named by their drivers. 

Yes, that's what I said :)  It just confused me because it applies to
any DAI.

> > > Also add a snd_soc_dai member to snd_soc_widget so that we dont have to
> > > use the widget private data.

> > If we're going to do that I think we should just drop the private data
> > field, this is exactly the sort of stuff it was added for.  Currently
> > it's only used by DAIs and regulator supplies.

> ok, we could add a regulator * in place of the void * in a separate
> patch

I guess.  If anything I'd rather be pulling stuff out of the core widget
into private per widget type data structures as we do end up with a fair
number of widgets but at this point we're a long way from doing that so
either way is fine.

> > Isn't this going to get complicated to use when building up the DAPM
> > routes?  The device is going to need to know its own dev_name() to
> > supply a table of routes which would mean you'd have to dynamically
> > create the routing table (or just specify a name and skip the whole
> > thing I guess).  

> I'm not needing to dynamically create the table, it all works as
> before :-

> This is the machine driver DAPM table. Here we are connecting the DAI
> widgets for twl6040 (using existing DAI widget codec code) to the ABE
> and the ABE to the Bluetooth device (using this patch).

This only works for the machine driver, not for the driver adding the
DAI itself.

> The intention here was for CPU DAIs only, the assumption was that the
> codecs would have a DAPM mapping to DAI or DAC/ADC by default. I can
> certainly change this to ignore the codec DAIs and leave them as is ?

Why not use the existing infrastructure?  It's more general in that it
covers other things like the regular controls which some CPUs have but
mostly don't currently use (digital gains and the like) as well as
allowing the DAI driver to map its own widgets if it wants to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120308/d5d25142/attachment.sig