[PATCH 0/4] ALSA: hda: Expose codec organization functions
Cezary Rojewski
cezary.rojewski at intel.com
Tue Feb 8 11:00:47 CET 2022
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
More information about the Alsa-devel
mailing list