On 28/11/2023 13:58, Péter Ujfalusi wrote:
On 28/11/2023 12:48, Takashi Iwai wrote:
Well, it is a bit more 'interesting' from that angle. for patch two we needed: https://lore.kernel.org/linux-sound/20231124124015.15878-1-peter.ujfalusi@li...
Ouch, this kind of information has to be mentioned in the patch description. Otherwise one would take only this series and face a problem easily. I can imagine such a problem on the stable tree.
OK, I will update the commit message
I would rather not risk to move the hdac_hda as Intel only using address 2 as HDMI indication - which I'm still not sure if it is Intel only or generic HDA convention.
Sure, it doesn't sound right, either.
Can we then add DAPM widgets and routes later conditionally instead of having it in component driver definition?
The issue is with the DAIs. If I remove the dai registering from hdac_hda_dev_probe() to be done in hdac_hda_codec_probe() then the probe will not happen since we do not have the needed components/DAIs to probe the card.
If we don't have HDMI then the machine driver will substitute it with dummy-dai, but if we have HDMI then we are not going to probe at all.
It is a sort of chicken and egg situation, right?
I think I have found a workaround without the need to export a function, it is going to be a single patch and should be OK for non Intel platforms in the future.
struct hdac_hda_priv *hda_pvt = dev_get_drvdata(&hdev->dev); .. if (hda_pvt->need_display_power) /* HDMI/DP */ else /* Non HDMI */