[alsa-devel] dev_* output functions and ASoC codecs

[Barry Song]

On Mon, Oct 12, 2009 at 6:48 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Mon, Oct 12, 2009 at 06:34:56PM +0800, Barry Song wrote:
>> On Mon, Oct 12, 2009 at 5:36 PM, Mark Brown
>
>> In codec:
>> "static struct snd_soc_codec *wm8903_codec" is a global variable to
>> describe a codec.  The global variable limit the codec driver can only
>> support one to work.
>
> Right, currently the WM8903 driver only allows one instance - this will
> be addressed in the future but for now the core doesn't really support
> this.  Addressing this is the main reason why the drivers need to be
> converted away from the old style of probing to using the device model
> and supplying struct deviecs - without doing that it's not possible to
> support more than one instance of the same CODEC.
>
>> In CPU dai:
>> in case there are two same I2S interfaces connecting two same wm8903,
>> then an array with two elements for CPU dai is needed.
>
> I'm sorry, I can't quite parse what you're saying here.  If you have two
> CPU DAIs then you need an array to hold them but that seems self evident
> so is presumably not what you mean?
>
>> In machin driver:
>> snd_soc_dai_link connect the multi same CPU dai and codec dai together.
>>
>> If we don't use num_links =2, we need to call
>> platform_device_alloc("soc-audio",...)/platform_device_add() twice
>> with duplicated struct snd_soc_device.
>
> Again, I'm not 100% clear what you're saying here.  If you have a CODEC
> with two DAIs which you need to connect to two CPU drivers then you will
> need two dai_links.  If you have two unrelated sound subsystems in your
> system then you should end up with two separate sound devices at the
> ALSA level.  I understand that this currently works OK, though it's not
> really supported.
>
Thanks a lot. Fortunately, You parsed my meaning well. I just want to
say it seems not too economic to have arrays with almost same members
while CPU interfaces and codecs are same for all dai_links. dai[0] and
dai[1] in array are just same.  It seems that will make more sense if
we can dynamically probe multi same devices with one DAI information
but not several repeated DAIs just as other bus/device/driver
framework probes multi-instances by matching. In case we can provide a
way to match and bind cpu DAI and codec DAI dynamically, for example
placing cpu and codec dai name wit an index in dai_link but not
referring C variables directly, then one DAI will support multi
instances while matching happens. And it will also eliminate the
compiling dependency that the current mach driver is accessing
cpu/codec variables directly.

Of course I think the current way is clear too. But people maybe feel
strange if they see completely same elements in DAI arrays :-)