On Tue, 04 Aug 2020 13:42:03 +0200,
Kai-Heng Feng wrote:
>
>
>
> > On Aug 4, 2020, at 17:48, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >
> > On Tue, 04 Aug 2020 11:31:59 +0200,
> > Kai-Heng Feng wrote:
> >>
> >>
> >>
> >>> On Aug 4, 2020, at 17:04, Takashi Iwai <tiwai@xxxxxxx> wrote:
> >>>
> >>> On Tue, 04 Aug 2020 09:29:25 +0200,
> >>> Kai-Heng Feng wrote:
> >>>>
> >>>> HDMI on some platforms doesn't enable audio support because its Port
> >>>> Connectivity [31:30] is set to AC_JACK_PORT_NONE:
> >>>> Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
> >>>> Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
> >>>> Amp-Out vals: [0x00 0x00]
> >>>> Pincap 0x0b000094: OUT Detect HBR HDMI DP
> >>>> Pin Default 0x58560010: [N/A] Digital Out at Int HDMI
> >>>> Conn = Digital, Color = Unknown
> >>>> DefAssociation = 0x1, Sequence = 0x0
> >>>> Pin-ctls: 0x40: OUT
> >>>> Unsolicited: tag=00, enabled=0
> >>>> Power states: D0 D3 EPSS
> >>>> Power: setting=D0, actual=D0
> >>>> Devices: 0
> >>>> Connection: 3
> >>>> 0x02 0x03* 0x04
> >>>>
> >>>> Those pins were filtered out by commit 116dcde63806 ("ALSA: HDA: Remove
> >>>> unconnected PCM devices for Intel HDMI"). However, jacks that support
> >>>> detection won't have the issues the commit addresses.
> >>>>
> >>>> So still add the pin if it supports jack detection.
> >>>>
> >>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
> >>>
> >>> Which platform did show the problem?
> >>
> >> An HP desktop.
> >
> > Well, what I meant was about which codec. And now I see it in the
> > below.
> >
> >>> I'm reluctant to apply this change as it would potentially break the
> >>> existing system. If we must to apply, maybe it's safer to apply it
> >>> conditionally to the limited devices.
> >>
> >> Hmm, I find it's a bit hard to match a specific device, because the ID seems to be rather generic:
> >> Codec: Intel Kabylake HDMI
> >> Address: 2
> >> AFG Function Id: 0x1 (unsol 0)
> >> Vendor Id: 0x8086280b
> >> Subsystem Id: 0x80860101
> >> Revision Id: 0x100000
> >>
> >> Should we use DMI string instead?
> >
> > So it's a Kabylake, and I presume that it's rather an old machine.
> > Is this for docking station or anything else?
>
> The system is Comet Lake CPU so it's fairly recent. I think most Comet Lake platforms still use "Kabylake HDMI".
OK.
> > Basically the pin capability is rather fixed by the chip design while
> > the pin configuration is set by BIOS. And we follow the BIOS setup
> > for determining which pins are actually alive. That said, the bug is
> > a BIOS bug.
>
> Yes but sometimes vendors are reluctant to fix it because "Windows doesn't have this issue".
Yes, and BIOS is always buggy, it's a fundamental rule of the world :)
So I'm not against adding the workaround itself. The problem is that
applying the workaround globally would cause another regression.
> > Note that PCI SSID bound with this codec might have a different
> > number, so we might be still able to use the standard quirk table to
> > pick up.
>
> Ok. Will send v2 with a quirk list.
Thanks. We can reconsider to widen the application of the workaround
once when we see the requirement (i.e. more machines with buggy BIOS
setup.)
Takashi
> Kai-Heng
>
> >
> >
> > thanks,
> >
> > Takashi
> >
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>> ---
> >>>> sound/pci/hda/patch_hdmi.c | 3 ++-
> >>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> >>>> index cd46247988e4..db3a5148bd40 100644
> >>>> --- a/sound/pci/hda/patch_hdmi.c
> >>>> +++ b/sound/pci/hda/patch_hdmi.c
> >>>> @@ -1701,7 +1701,8 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
> >>>> * all device entries on the same pin
> >>>> */
> >>>> config = snd_hda_codec_get_pincfg(codec, pin_nid);
> >>>> - if (get_defcfg_connect(config) == AC_JACK_PORT_NONE)
> >>>> + if ((get_defcfg_connect(config) == AC_JACK_PORT_NONE) &&
> >>>> + !(caps & AC_PINCAP_PRES_DETECT))
> >>>> return 0;
> >>>>
> >>>> /*
> >>>> --
> >>>> 2.17.1
>
