[alsa-devel] [RFC 0/4] Add support for DAI link addition dynamically

[Mengdong Lin]

On 02/18/2016 03:57 PM, Vaibhav Agarwal wrote:
> On 18 February 2016 at 10:53, Mengdong Lin <mengdong.lin at linux.intel.com> wrote:


>> Since the codec driver is generic and can be used for many machines so I
>> feel we should avoid adding too machine-specific code to it (e.g. the soc
>> card name) as much as possible.
>
> We are not adding any machine-specific code in generic codec driver.
> In case we are using generic codec driver (existing in
> sound/soc/codecs), it would need a helper driver to glue it to soc
> card dynamically. Otherwise, for a specific platform, we can have a
> wrapper codec driver that can fetch capabilities of removable codec
> (may be via binary data) and expose them to already known soc cards
> for that device.
>
>>
>> I think the machine driver can understand all use cases for a platform,
>> including static or removable connections between the SOC and codecs. So
>> it's able to specify the removable codec and the codec DAIs needed by the
>> machine, as well as these removable links. Please correct me if my
>> understanding is wrong.
>
> As per my opinion, in case a platform supports say I2S interface, then
> any removable codec module utilizing I2S mode should work with that
> platform. So, knowing complete info about the codec may not be
> possible.
>

Okay. Then the machine driver has no way to pre-define the removal codec 
and the BE links. Thanks for your clarification.

Can the machine driver leave the codec and codec dai empty in the 
removable BE links? When a compatible codec is registered, the ASoC core 
will fill these fields and bind the links. When the codec is removed, 
the ASoC will unbind the links and clear the fields.


>> Do you mean the machine driver has no idea about these removal codecs?
>> And could you share more info about the removal codec in your use case?
>>
>
> A removable codec can be of any manufacturer using xyz codec. As
> mentioned before, it may not have info about possible codec to be
> connected. But, it can definitely choose the functionality supported
> based on it own capabilities.


>>
>> But IMHO I hope we can avoid this. So I suggested let machine driver define
>> some 'removable' links and ASoC core can bind/unbind them automatically with
>> the registration/unregistration of the codec component. I think most of your
>> code for ASoC core can still be reused.
>
> I wonder, if we can extend snd_soc_add_dai_link() to perform complete
> binding as well, with a conditional check for (!card->instantiated) to
> exit early. This would enable us using this API itself for the purpose
> we intend too.  Any thoughts/suggestions?

Yes. I think we can extend this function like this if need.

Thanks
Mengdong

>
> Also, keeping in mind that we don't have codec & codec_dai info in
> advance, I can't see any value addition of keeping place holders for
> DAI link based on platform capability.
>
> --
> Thanks,
> ./va
>