On 02/18/2016 03:57 PM, Vaibhav Agarwal wrote:
On 18 February 2016 at 10:53, Mengdong Lin mengdong.lin@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