Re: [RFC 1/6] video: hdmi: add helper function for N and CTS

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Jan 20, 2016 at 02:26:08PM +0100, Arnaud Pouliquen wrote:
> 
> 
> On 01/19/2016 05:54 PM, Russell King - ARM Linux wrote:
> > However, some of the values given in the HDMI specs for CTS are actually
> > two values, because a single value does not specify the audio clock even
> > with the N values given.  For these, the values returned will not give
> > an accurate clock - this should also be noted.
>
> In HDMI specs i only see a double value for 32 kHz with TMDS clock at
> 74.324  MHz. I can add a  alt_CTS params in hdmi_audio_n_cts that will
> be not null if alternate a value is needed. Is this something reasonable
> for you?

They aren't "alternatives".  They give two values because, in order to
generate that audio sample rate, you need to switch between the two
values to achieve an average audio sample rate that matches the requested
rate.  I suspect that unless you have special hardware which does that
for you automatically, these values are less than ideal.

For example, for 32kHz:

74.25 / 1.001              11648               210937-210938*

which is:

 74250000 / (1.001 * 210937 * 128) * 11648 = 32000.076
 74250000 / (1.001 * 210938 * 128) * 11648 = 31999.924

So, alternating between each for 50% of the time gives 32kHz.

For my other points:

  Section 7.2.3:
  It is recommended that Sources with non-coherent clocks use the
  values listed for a TMDS clock of "Other".

As you have non-coherent clocks, and your CTS value is measured by
the hardware, using the "Other" N values seems to be recommended by
the standard.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.