Bug 101793

Created attachment 132691 [details] [review]
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@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@lago:~# echo "connection_type 1" > /proc/asound/card0/eld#2.0
root@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@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.