Bug 90776

At a glance, looks like the spec has been clarified, and what we currently do (let the hardware figure out the N/CTS values based on the HDMI pixel clock) might only work reliably for CEA modes.

At the second glance, looks like we got ourselves a nice little catch-22 here. When we enable an audio capable output, we notify the audio driver about this (through hardware). At this point we don't know or care what the audio driver does about it. We go on enabling the output. However if the audio driver is in control of the sampling rate, and the N/CTS values need to be adjusted based on that, we'd need to disable the transcoder to make the change...

With a HDMI Protocol Analyzer and a bunch of audio files sampled at different rates, a bug can be seen--

Setup:
  * latest drm-intel-nightly
  * ideally a test sink HDMI Protocol Analyzer (or Acer B286HK 4K display)
  * Intel platform with HDA audio and Intel Graphics hardware (HSW or newer)

Steps:
  1. Boot system
  2. If not plugged already, plug HDMI display
  3. Set HDMI display resolution to 3840x2160
  4. Configure audio to play back over HDMI
  5. Play an audio file sampled at 48kHz, note N/CTS values in Analyzer or dump relevant registers-- they may not match spec; may not play back over stated display
  6. Play an audio file sampled at 44.1kHz, note N/CTS values in Analyzer or dump relevant registers-- they *will not* match spec; likely will not hear audio over stated display

Mileage varies substantially display to display. As of writing, Acer B286HK 4K display is especially sensitive to HDMI audio being out-of-spec.

Some audio examples:
* 44.1kHz: "Maroon 5 - 'Sugar'": https://www.youtube.com/watch?v=09R8_2nJtjg
* 48kHz seems to be the dominant sampling rate on high-profile youtube vids

I'll attempt to distill several discussions I've had with colleagues over the past week or so.

The take-away is, there needs to be a callback mechanism within the i915 driver to properly program N/CTS for all pixel clock rates-- those commonly associated with UHD-4K being one example, and the one I've personally tested with a HDMI protocol analyzer.

One of my colleagues floated the following interface additions to i915_audio_component to provide necessary communication between sound drivers and i915:

  /* set correct N/CTS values as specified in HDMI specification */
  void (*set_audio_rate)(struct device *, enum port port, int rate);

and

  /* the same, but in DP MST usage scenarios */
  void (*set_audio_rate)(struct device *, enum port port, int dev, int rate);

There are questions, of course:

  - surrounding the particulars of S/W programming the N/CTS registers on-the-fly at runtime while the user is using their audio player or watching a video;

  - about tackling this problem on a conditional basis (targeting the trouble spots), or if we want the i915 kernel driver to be the N/CTS S/W programmer 100% of the time;

  - whether buggy behavior is seen also with non-CEA modes at high pixel rates, not necessarily at the resolution cited in this ticket;

  - what to do about very low sampling rates defined in the HDMI spec, such as 32kHz and multiples thereof; and

  - how best to handle DP MST usage scenarios

Any updates on this?

I thought this one might be the fix:
http://lists.freedesktop.org/archives/intel-gfx/2015-September/076650.html

It's also in drm-intel-nightly via Takashi's sound tree [1]:

commit 7e8275c2f2bbb384e18af37066b8b2f32b7d092f
Author: Libin Yang <libin.yang@intel.com>
Date:   Fri Sep 25 09:36:12 2015 +0800

    drm/i915: set proper N/CTS in modeset

I am currently not sure if it's still to be merged to v4.3, or whether Takashi decided to postpone it until v4.4.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

AFAIK everything is upstream now, closing. Thanks for the report.

This patch is also needed:
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077476.html