Re: [PATCH 1/2] ALSA: hda/hdmi: Add helper function to check if a device is HDMI codec

Takashi Iwai
2023-11-28T13:02:18Z

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@linux.intel.com/
> >>
> >> 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