Re: [alsa-devel] [RFC_iii/iv 1/2] ASoC: Rename dai_link as dev_map
On Fri, Oct 29, 2010 at 03:02:59PM +0300, Jarkko Nikula wrote:
Thus far the struct snd_soc_dai_link is used to tie together platform, codec and cpu dai drivers in a machine driver and all of these devices has been required for a link.
My main thought with this now that I see the change is that it'd be easier and probably clearer to add an explicit list of devices rather than to repurpose the DAI links. This will probably be simpler since we can avoid things like having to work out if we've seen and initialised a device before when it has multiple DAIs involved.
On Fri, 29 Oct 2010 14:22:49 -0700 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Oct 29, 2010 at 03:02:59PM +0300, Jarkko Nikula wrote:
Thus far the struct snd_soc_dai_link is used to tie together platform, codec and cpu dai drivers in a machine driver and all of these devices has been required for a link.
My main thought with this now that I see the change is that it'd be easier and probably clearer to add an explicit list of devices rather than to repurpose the DAI links. This will probably be simpler since we can avoid things like having to work out if we've seen and initialised a device before when it has multiple DAIs involved.
My concern was mostly that we end up having somewhat similar struct than snd_soc_dai_link and adding pointer to such table in snd_soc_card. But that's not necessary reduncandy at all if it makes cleanier move to other cases like codec-codec etc. I'll experiment that in next version.
On Sun, Oct 31, 2010 at 08:12:15PM +0200, Jarkko Nikula wrote:
Mark Brown broonie@opensource.wolfsonmicro.com wrote:
My main thought with this now that I see the change is that it'd be easier and probably clearer to add an explicit list of devices rather than to repurpose the DAI links. This will probably be simpler since we can avoid things like having to work out if we've seen and initialised a device before when it has multiple DAIs involved.
My concern was mostly that we end up having somewhat similar struct than snd_soc_dai_link and adding pointer to such table in snd_soc_card.
We probably want to be pulling stuff out of the DAI link if anything (for example, the CODEC is generally going to be implied by the CODEC DAI).
But that's not necessary reduncandy at all if it makes cleanier move to other cases like codec-codec etc. I'll experiment that in next version.
Please do - I'd rather have a series of small, clear descriptive lists than a single big list since I think that this will be much clearer and easier to work with.
participants (2)
-
Jarkko Nikula -
Mark Brown