On 02/18/2016 03:57 PM, Vaibhav Agarwal wrote:
On 18 February 2016 at 10:53, Mengdong Lin <mengdong.lin@xxxxxxxxxxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
