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.