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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
