Comment # 15 on bug 69675 from Pierre Ossman

(In reply to comment #4)
> Something like this:
> 
> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
> b/drivers/gpu/drm/radeon/r600_hdmi.c
> index b0fa600..f7d2766 100644
> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
> @@ -63,7 +63,7 @@ static const struct radeon_hdmi_acr
> r600_hdmi_predefined_acr[] = {
>      {  27027,  4096,  27027,  6272,  30030,  6144,  27027 }, /* 
> 27.00*1.001 MHz */
>      {  54000,  4096,  54000,  6272,  60000,  6144,  54000 }, /*  54.00     
> MHz */
>      {  54054,  4096,  54054,  6272,  60060,  6144,  54054 }, /* 
> 54.00*1.001 MHz */
> -    {  74175, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 
> 74.25/1.001 MHz */
> +    {  74180, 11648, 210937, 17836, 234375, 11648, 140625 }, /* 
> 74.25/1.001 MHz */
>      {  74250,  4096,  74250,  6272,  82500,  6144,  74250 }, /*  74.25     
> MHz */
>      { 148351, 11648, 421875,  8918, 234375,  5824, 140625 }, /*
> 148.50/1.001 MHz */
>      { 148500,  4096, 148500,  6272, 165000,  6144, 148500 }, /* 148.50     
> MHz */

This however does not improve things. But that was because the frequency was
actually 74176, not 74180 (damn all that rounded output).

With that fixed, it *seems* to work. But doing the numbers, the audio clock is
slightly off as those numbers assume a perfect 74.25/1.001 video clock, not the
74.176 approximation. And 33 kHz audio needs a changing CTS even with that. So
it doesn't seem like a robust approach IHMO. I vote for letting the hardware do
its magic.

Somewhat related, the calculation in r600_hdmi_calc_cts() is not very good as
it loses a tonne of precision (roughly ten bits' worth). Given the range of the
inputs, you might need to do the calculations in a 64-bit space.