Re: [PATCH 0/4] ALSA: hda: Expose codec organization functions

[Cezary Rojewski <cezary.rojewski@intel.com>]

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