On 2022-02-08 6:14 PM, Takashi Iwai wrote:
Hmm, but snd_hda_codec_device_new() also does the actual hardware initialization including the power-up sequence, and there is a call snd_component_add() with the card instance. How the function would work properly before the card instantiation? You seem to have handled only snd_device_new() and not touching other code where the card (or the hardware access) is involved.
If the purpose is to get the fields of snd_hda_codec to be initialized, those init code can be factored out to another function, so that it works certainly without card.
I was anticipating snd_hda_codec_device_init() related question so much and was so ready for it that I answered like an autobot, regardless of fact that people were not asking about snd_hda_codec_device_init() vs snd_hda_codec_device_new() directly and that's not even the patch where the change is added. And I wasn't even drinking coffee for the past few days..
Meh.. In regard to snddev_managed, If I'm not mistaken, the problem is connected to the 'dev_ops' (.dev_register, .dev_free) provided for snd_device_new(). To have basically 0% custom HDA logic in our code, rely solely on code found in sound/hda and sound/pci/hda ability to control when snd_hda_codec_register() and snd_hda_codec_unregister() is called was needed.
snd_soc_bind_card() invokes snd_card_register() which in consequence leads to snd_device_register_all() and that to automatic ->dev_register call. That call involves PM operations, and at that moment, codec is not ready for it. In the end, ability to call these in correct order allowed all codecs that communicate with avs-driver to remain on HDA_DEV_LEGACY level.
To answer the remaining question found in your message: The purpose of the change was not to get the fields of snd_hda_codec out of the function and have them initialized elsewhere. All other operations found in the snd_hda_codec_device_new() are required and their ordering is not problematic so they have been left untouched.
Regards, Czarek