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
