Haswell: Ensuring HDA codec pins refer to physical outputs

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1183125

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

the following two commits maybe can help you.

commit 17df3f55652f7ea8fb1197b5c32e227b3da9f215
Author: Takashi Iwai <email address hidden>
Date: Wed May 8 08:09:34 2013 +0200

    ALSA: hda - Apply pin-enablement workaround to all Haswell HDMI codecs

commit 1611a9c931e95fab871a33beba49cc9ea39bbba8
Author: Mengdong Lin <email address hidden>
Date: Fri Feb 8 17:09:52 2013 -0500

    ALSA: hda - Add fixup for Haswell to enable all pin and convertor widgets

Backport the following commit to Raring kernel, HDMI audio works fine on Haswell-mobile ad Haswell-ULT sdv.
I test boot, reboot, S3, hotplug, all works fine.

commit 17df3f55652f7ea8fb1197b5c32e227b3da9f215
Author: Takashi Iwai <email address hidden>
Date: Wed May 8 08:09:34 2013 +0200
    ALSA: hda - Apply pin-enablement workaround to all Haswell HDMI codecs

thanks

Latest from alsa-devel:

http://article.gmane.org/gmane.linux.alsa.devel/108866/match=ignore+default

I believe we're experiencing basically the same problem with the upcoming System76 Haswell desktop products.

The problem (for us) is that HDMI audio devices simply don't show up at all in the sound menu. We're able to fix this by cherry-picking these 3 commits from mainline:

9419ab6b72325e20789a61004cf68dc9e909a009
ALSA: hda - Add power state filtering

c88d4e84e639df9a9640ecff71de2501a84d1f48
ALSA: hda - Yet another fix for broken HSW HDMI pin connections

17df3f55652f7ea8fb1197b5c32e227b3da9f215
ALSA: hda - Apply pin-enablement workaround to all Haswell HDMI codecs

These 3 commits are already present in the Saucy tree, although it seems there is perhaps a regression currently in Saucy in that the HDMI device will only show up if connected at boot, wont show up if you plug in a different monitor after initially booting with a monitor that lacks HDMI audio.

Anyway, for reference here are the mainline commits, which you can cleanly cherry pick into the current Raring tree:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9419ab6b72325e20789a61004cf68dc9e909a009

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c88d4e84e639df9a9640ecff71de2501a84d1f48

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17df3f55652f7ea8fb1197b5c32e227b3da9f215

Hi Jason,

Thanks for your help. Ultimately, I think there is more too it than that. These are the latest comments from our audio developer, David Henningsson, about the issue:

I hope I can remember the situation correctly. This is essentially a
longer version of what I wrote before.

First, the unusual thing about these particular devices is that it seems
the integrated monitor is internally connected over HDMI.

This means that, seen from the driver's perspective, there are two HDMI
outputs. This has been less tested than one HDMI output (on Haswell),
but there are chances this works better in the 3.11 kernel - I'm not sure.

Second, the internal monitor does not have any audio capabilities (the
internal analog audio is connected to the ALC668 codec, not the HDMI
monitor), but still, the internal monitor advertises audio capabilities
(as seen in ELD info). This is something we could talk to the OSV about, to
see if they could change this: the monitor should not advertise being
able to play back audio, if it can't.

Third, (maybe meant as a workaround to the just mentioned issue about
ELD info?) some audio codec pins are marked as "not connected" by BIOS.
However, this workaround is not working, at least not on Linux. This is
where I've been trying to get clear answers from Intel, but still have
not received any, even though we have had long discussions and even
phone calls about it.

In short, there seem to be uncertainty on the Intel side how their
hardware actually works: First, how the audio codec pins are actually
connected to the available physical outputs, pipes or transcoders.
Second, if disabling pins in BIOS should be regarded as an error on the
Haswell platform or not. Some Intel developers think so, but we need a
clear statement from Intel that this is the case before we can tell the OEM
they should change BIOS.

I hope this clarifies the status of this issue.

It can be ensured that HDA codec pins refer to physical outputs.

Intel display audio HW owner confirmed that there are fixed mappings between audio codec pins and GPU ports, like this:
1st Pin (NID 5) = Port B
2nd Pin (NID 6) = Port C
3rd Pin (NID 7) = Port D
No matter Gfx driver connects what transcoder to a port, the above pin/port mapping won't change.

And since the connections between port and physical output are fixed for a specific machine. Thus HD-A codec pins always refer to fixed physical outputs of a machine.

So BIOS should always program a pin's 'Configuration Default' according to the actual usage of its mapped port.
Eg. If a port is physically connected to a DP/HDMI output on a machine board, the pin's "Port Connectivity" should be 00b (Jack).

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed' to 'verification-done'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

For what it's worth, I just tested the propose kernel on the System76 desktop products effected by this, and it fixes the problem.

I'm not adding the "verification-done" tag though, since I didn't file the bug and can't speak to whether this fix is correct for whatever hardware was originally in question.

I believe Jason's confirmation in comment #10, in combination with Mengdong's comment #8 - that there is a fixed mapping between pin nodes and physical outputs - is enough to say that it's verification-done at this point.

This bug was fixed in the package linux - 3.8.0-30.44

---------------
linux (3.8.0-30.44) raring; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #1215596

  [ Upstream Kernel Changes ]

  * Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
    - LP: #1215155

linux (3.8.0-30.43) raring; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #1215095

  [ Andy Whitcroft ]

  * [Packaging] supply perf with appropriate prefix to ensure use of local
    config
    - LP: #1206200
    - CVE-2013-1060

  [ Brad Figg ]

  * Start new release

  [ John Johansen ]

  * Revert "SAUCE: (no-up) AppArmor: Disable Add PR_{GET,SET}_NO_NEW_PRIVS
    to prevent execve from granting privs"
    - LP: #1202161

  [ Joseph Salisbury ]

  * SAUCE: (no-up) intel_ips: blacklist ASUSTek G60JX laptops
    - LP: #1210848

  [ Kamal Mostafa ]

  * SAUCE: (no-up) Revert "SAUCE: (no-up) drm/i915: quirk no PCH_PWM_ENABLE
    for Dell XPS13 backlight"

  [ Tim Gardner ]

  * [Config] Include rbd and kvm in the virtual inclusion list
    - LP: #1206961

  [ Upstream Kernel Changes ]

  * Revert "drm/i915: Workaround incoherence between fences and LLC across
    multiple CPUs"
    - LP: #1207977
  * xen/blkback: Check device permissions before allowing OP_DISCARD
    - LP: #1207977
  * ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL
    - LP: #1207977
  * ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK
    - LP: #1207977
  * drm/i915: Correct obj->mm_list link to
    dev_priv->dev_priv->mm.inactive_list
    - LP: #1207977
  * drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
    - LP: #1207977
  * Partially revert "drm/i915: unconditionally use mt forcewake on
    hsw/ivb"
    - LP: #1207977
  * drm/i915: Fix write-read race with multiple rings
    - LP: #1207977
  * drm/i915: merge {i965, sandybridge}_write_fence_reg()
    - LP: #1207977
  * drm/i915: Fix incoherence with fence updates on Sandybridge+
    - LP: #1207977
  * drm/i915: rename sdvox_reg to hdmi_reg on HDMI context
    - LP: #1207977
  * drm/i915: don't setup hdmi for port D edp in ddi_init
    - LP: #1207977
  * drm/i915: Preserve the DDI_A_4_LANES bit from the bios
    - LP: #1207977
  * drm/radeon/hdmi: make sure we have an afmt block assigned
    - LP: #1207977
  * drm/radeon: allocate SA bo in the requested domain
    - LP: #1207977
  * drm/radeon: allow selection of alignment in the sub-allocator
    - LP: #1207977
  * ACPI / memhotplug: Fix a stale pointer in error path
    - LP: #1207977
  * PM / Sleep: avoid 'autosleep' in shutdown progress
    - LP: #1207977
  * ext4: fix error handling in ext4_ext_truncate()
    - LP: #1207977
  * radeon kms: do not flush uninitialized hotplug work
    - LP: #1207977
  * ALSA: asihpi: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ALSA: atiixp: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ALSA: 6fire: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ALSA: ua101: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ALSA: usx2y: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ALSA: pxa2xx: Fix unlocked snd_pcm_stop() call
    - LP: #1207977
  * ASoC: atmel: Fix unl...

The machines that have this as a preinstall are shipping with a dkms, and as yet I have not seen any requests to fix this in Quantal. If you would like a Quantal fix, please fill out the sru template.