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@xxxxxxxxxxxxxxx/ >> >> 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 */ -- Péter
