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
