summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHans de Goede <hdegoede@redhat.com>2013-01-16 14:07:30 +0400
committerAlejandro Mery <amery@geeks.cl>2013-01-24 20:28:55 +0400
commitd0488684a800827ae73f90af6f23d1c6939b4597 (patch)
tree83f32731e1f1dbb1064c0bf9f754f47485956772
parentb8307d3ab21afdefec4478a766a4ff053f2c1b90 (diff)
downloadlinux-sunxi-d0488684a800827ae73f90af6f23d1c6939b4597.tar.xz
sunxi-hdmi: Fix pixelclock conversion harder
The pixelclock in hz -> picoseconds -> hz conversions loosing precision first fixed by "sunxi-hdmi: Fix some modes no longer working with X", is still a problem with some modes :| For example 130000000 becomes 130010000, and X does not work. We can only do pixelclocks which are a divider of 1 - 15 of a multiple of 3 MHz. Combining this with EDID's granularity of 10 Khz, all clocks must have been a multiple of 100 or 250 KHz before the conversion. Therefore this patch changes the rounding in fb_videomode_pixclock_to_hdmi_pclk from rounding to 10Khz to rounding to 50Khz, which should hopefullly be enough to get rid of any imprecision introduced by the conversion process. Reported-by: Daniel Veillard <veillard@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
-rw-r--r--drivers/video/sunxi/disp/disp_hdmi.c14
1 files changed, 8 insertions, 6 deletions
diff --git a/drivers/video/sunxi/disp/disp_hdmi.c b/drivers/video/sunxi/disp/disp_hdmi.c
index 028a75b1e368..bccaa8ae9358 100644
--- a/drivers/video/sunxi/disp/disp_hdmi.c
+++ b/drivers/video/sunxi/disp/disp_hdmi.c
@@ -194,13 +194,15 @@ __s32 BSP_disp_hdmi_set_mode(__u32 sel, __disp_tv_mode_t mode)
__u32 fb_videomode_pixclock_to_hdmi_pclk(__u32 pixclock)
{
/*
- * The conversions loose precision, which *is* a problem, luckily
- * all hdmi clocks are always a multiple of 10000 (the EDID base
- * unit for a pixelclock), so round to the nearest multiple of
- * 10000 to undo the precision loss.
+ * The pixelclock -> picoseconds -> pixelclock conversions we do
+ * lose precision, which *is* a problem.
+ * We can only do pixelclocks which are a divider of 1 - 15 of
+ * a multiple of 3 MHz. So all clocks must have been a multiple of
+ * 100 or 250 KHz before the conversion -> round to the nearest
+ * multiple of 50 KHz to undo the precision loss.
*/
- __u32 pclk = (PICOS2HZ(pixclock) + 5000) / 10000;
- return pclk * 10000;
+ __u32 pclk = (PICOS2HZ(pixclock) + 25000) / 50000;
+ return pclk * 50000;
}
void videomode_to_video_timing(struct __disp_video_timing *video_timing,