On Tue, 28 Nov 2023 13:16:29 +0100, Péter Ujfalusi wrote: > > > > 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 */ Looks like a saner approach, yeah. thanks, Takashi
