<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - hdmi audio: spec violation for >=uhd-4k TMDS clock frequencies, no audio out in worst case"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=90776#c4">Comment # 4</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - hdmi audio: spec violation for >=uhd-4k TMDS clock frequencies, no audio out in worst case"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=90776">bug 90776</a>
              from <span class="vcard"><a class="email" href="mailto:joe.konno@linux.intel.com" title="Joe Konno <joe.konno@linux.intel.com>"> <span class="fn">Joe Konno</span></a>
</span></b>
        <pre>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</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>