On Wed, Feb 15, 2012 at 04:02:54PM +0000, Liam Girdwood wrote:
Currently we map DAI streams to DAPM widgets based on a string stream name. This can lead to some limitations when working with lots of DAI links as there is a risk of naming collision with similar stream names.
This patch creates a 1:N mapping between a DAI and it's DAPM widgets. It's still string based, but we now directly reference the widget names with the DAI and bind the DAI to the widget ptrs at initialisation. The binding also tales into consideration the parent codec or platform that the DAI and widget belong to so that we can easily support multiple components with the same widget names.
This patch still works in conjunction with the stream based events, but it is intended to eventually replace the DAI stream name.
I was thinking about something close to this myself as part of the CODEC<->CODEC automatic DAPM stuff I keep mentioning. In order to make that work what I was going to do was instead of mapping the widgets directly onto the DAI was to add a DAPM widget that represented the stream and link the DAI to that, probably created automatically from the DAI definition. We'd then have the DAIs sitting in the DAPM graph and it gets much simpler to just connect the playback DAI on one device to the capture device on another (and vice versa).
In terms of the API and end result it's pretty similar to what you've got here except it'd probably end up with the DAI<->widget links specified through the DAPM map. What do you think? I'd rather not churn the API more often than we have to.