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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




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




[Index of Archives]     [Pulseaudio]     [Linux Audio Users]     [ALSA Devel]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux