[Bug 101793] New: [SKL] No HDMI audio on Intel NUC6i7KYK, experimental patch workaround

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jul 14 19:38:59 UTC 2017


https://bugs.freedesktop.org/show_bug.cgi?id=101793

            Bug ID: 101793
           Summary: [SKL] No HDMI audio on Intel NUC6i7KYK, experimental
                    patch workaround
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: jnuzman at gmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 132691
  --> https://bugs.freedesktop.org/attachment.cgi?id=132691&action=edit
Experimental patch that allows workaround

Hardware:  Skylake NUC6i7KYK connected to Samsung LCD television UA50F5000AR.  
Software: 4.10.0-26-generic x86_64 Ubuntu 17.04

Originally running Ubuntu Xenial (kernel 4.4 with backported i915 driver). 
HDMI audio output worked correctly.

Regression:  After upgrade to Ubuntu Yakkety (kernel 4.8), HDMI audio stopped
working (no sound output).  Rebooting to Xenial kernel restored working HDMI
audio.

HDMI also audio failed to work with Ubuntu Zesty (kernel 4.10), or on any of
several vanilla mainline kernels from 4.5.0 through 4.12.0.

Observation:  on all working kernels, audio connection type is detected as
"DisplayPort".  On failing kernels, audio connection type is "HDMI".

The connection type is specified by the i915 driver in a field of the ELD data
passed to the audio driver.  ALSA provides a proc interface to override the
connection type.  However, the value is overwritten when the ELD data is
reparsed, which seems to happen quite a bit.  The attached patch allows the
overridden value to persist.

With the patch applied, switching the audio connection type to DisplayPort
fixes the problem:

root at lago:~# cat /proc/asound/card0/eld#2.0
monitor_present         1
eld_valid               1
monitor_name            SAMSUNG
connection_type         HDMI
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0x2d4c
product_id              0xa7a
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0xe0] 32000 44100 48000
sad0_bits               [0xe0000] 16 20 24

root at lago:~# echo "connection_type 1" > /proc/asound/card0/eld#2.0
root at lago:~# cat /proc/asound/card0/eld#2.0
monitor_present         1
eld_valid               1
monitor_name            SAMSUNG
connection_type         DisplayPort
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0x2d4c
product_id              0xa7a
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0x1] FL/FR
sad_count               1
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0xe0] 32000 44100 48000
sad0_bits               [0xe0000] 16 20 24

And with this connection type, HDMI audio works again.

A bit about the hardware:  The TV is connected with an HDMI cable to a physical
HDMI connector on the back of the NUC.  However, it is a "DP" connection that
is enumerated in sysfs:
root at lago:~# grep . /sys/class/drm/card0-*/status
/sys/class/drm/card0-DP-1/status:connected
/sys/class/drm/card0-DP-2/status:disconnected
/sys/class/drm/card0-DP-3/status:disconnected
/sys/class/drm/card0-HDMI-A-1/status:disconnected
/sys/class/drm/card0-HDMI-A-2/status:disconnected

I suspect that on this NUC, the HDMI port sits behind an internal DP->HDMI
converter.  A snippet from dmesg:

[    1.901036] [drm:intel_ddi_init [i915]] VBT says port B has lspcon
[    1.901051] [drm:intel_dp_init_connector [i915]] Adding DP connector on port
B
[    1.901070] [drm:intel_dp_init_connector [i915]] using AUX B for port B
(VBT)
[    1.901864] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI
ID: DP-HDMI ADAPTOR\004 (err 0)
[    1.902520] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode
adaptor ID: a8 (err 0)
[    1.902539] [drm:lspcon_init [i915]] LSPCON detected
[    1.903209] [drm:lspcon_init [i915]] Current LSPCON mode PCON
[    1.904013] [drm:intel_dp_read_dpcd [i915]] DPCD: 12 14 c4 01 01 15 01 81 02
01 04 01 0f 00 01
[    1.904794] [drm:intel_dp_read_desc [i915]] DP branch: OUI 00-1c-f8 dev-ID
175IB0 HW-rev 1.0 SW-rev 7.32
[    1.904810] [drm:lspcon_init [i915]] Success: LSPCON init
[    1.904825] [drm:intel_ddi_init [i915]] LSPCON init success on port B

It seems that the code that determines whether i915 specifies DP or HDMI in the
ELD has changed quite a bit between 4.5 and 4.12, but no version seems to
detect the right thing for this setup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170714/99c10394/attachment.html>


More information about the intel-gfx-bugs mailing list