https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #15 from Pierre Ossman pierre-bugzilla@ossman.eu --- (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.