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

Message

Cezary Rojewski Feb. 7, 2022, 11:49 a.m. UTC

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()

This allows upcoming AVS driver [1] to re-use even mode of HDA related
code that is currently available in sound/pci/hda and sound/hda and
prevent any code duplication within avs-driver that would otherwise had
to happen.

Last patch in the series provides snd_hdac_ext_bus_link_at() - a helper
function which allows for retrieval of HDA segment (link) based on codec
address directly. This is simpler than parsing codec-name first to
extract the address what is the case for snd_hdac_ext_bus_get_link().
The latter function is updated to re-use newly added one so core logic
is not duplicated after the addition.

[1]: https://lore.kernel.org/all/[e-mail]/


Cezary Rojewski (4):
  ALSA: hda: Add snd_hdac_ext_bus_link_at() helper
  ALSA: hda: Update and expose snd_hda_codec_device_init()
  ALSA: hda: Update and expose codec register procedures
  ALSA: hda: Expose codec cleanup and power-save functions

 include/sound/hda_codec.h           | 11 +++-
 include/sound/hdaudio_ext.h         |  1 +
 sound/hda/ext/hdac_ext_controller.c | 31 +++++++---
 sound/pci/hda/hda_codec.c           | 94 ++++++++++++++++++++---------
 sound/pci/hda/hda_local.h           |  2 -
 sound/soc/codecs/hdac_hda.c         |  2 +-
 6 files changed, 100 insertions(+), 41 deletions(-)

Comments

Pierre-Louis Bossart Feb. 7, 2022, 12:35 p.m. UTC | #1

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?

Cezary Rojewski Feb. 8, 2022, 10 a.m. UTC | #2

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