[Bug 90776] hdmi audio: spec violation for >=uhd-4k TMDS clock frequencies, no audio out in worst case

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Joe Konno <joe.konno at linux.intel.com> ---
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

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