On 2022-02-07 1:35 PM, Pierre-Louis Bossart wrote:
On 2/7/22 05:49, Cezary Rojewski wrote:
Changes expose several function that are currently unavailable for HDA-DSP drivers for use. Those functions are:
snd_hda_codec_cleanup_for_unbind() snd_hda_codec_set_power_save() snd_hda_codec_register() snd_hda_codec_unregister() snd_hda_codec_device_init()
It would be useful to explain why a platform driver would need to make use of codec-management related routines, which would typically be needed only in a codec or machine driver, or hidden as part of a generic bus layer.
In addition, both the Skylake and SOF/HDA drivers make use of e.g., snd_hdac_ext_bus_device_init(), what was wrong with this approach that's been used since 2018?
Thanks for chiming in! So, all HDA drivers currently available in ASoC are _assuming_ codec resources, they are not _reading_ them. To be efficient and only create DAIs and other components when needed, codec's ->pcm_list_head need to be filled in with data before ASoC sound card can be fully enumerated.
Initialization routines for HDA device require pointer to instance of struct snd_card upfront whereas ASoC framework gives you such pointer only once all components are accounted for. Also, component granulation seen in ASoC causes need for adjustment for order of operations when registering/probing codec device to achieve correctness (resource wise) I'd mentioned above. We could have coded that logic ourselves but that's a duplication as the logic is already there.
Regards, Czarek