drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Mon, 16 Nov 2015 19:05:12 +0000 (21:05 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 1 Dec 2015 06:57:14 +0000 (07:57 +0100)
commit4c6bcf44549907cb50b67f98eb13717a4adc6b33
tree1b2d0b895c0c6a2891359526455637eba1a5649f
parent6753ba97e78bb0ed5c0ed35c21c1e2a31f7299a0
drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz clock difference

Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.

drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.

Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?

Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/drm_edid.c
drivers/gpu/drm/drm_modes.c
include/drm/drm_modes.h