summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/host1x/syncpt.h
diff options
context:
space:
mode:
authorVille Syrjälä <ville.syrjala@linux.intel.com>2014-12-17 13:56:23 +0200
committerDaniel Vetter <daniel.vetter@ffwll.ch>2014-12-17 18:29:35 +0100
commitabc0b1447d4974963548777a5ba4a4457c82c426 (patch)
tree37d56dd85aefc2ec4f297268b11242e3ddbf89fa /drivers/gpu/host1x/syncpt.h
parent05acaec334fcc1132d1e48c5042e044651e0b75b (diff)
downloadtalos-obmc-linux-abc0b1447d4974963548777a5ba4a4457c82c426.tar.gz
talos-obmc-linux-abc0b1447d4974963548777a5ba4a4457c82c426.zip
drm: Perform basic sanity checks on probed modes
Make sure the timings of probed modes at least pass some very basic sanity checks. The checks include: - clock,hdisplay,vdisplay are non zero - sync pulse fits within the blanking period - htotal,vtotal are big enough I have not checked all the drivers to see if the modes the generate might violate these constraints. I'm hoping not, because that would mean either abandoning the idea of doing this from the core code, or fixing the drivers. I'm not entirely sure about limiting the sync pulse to the blanking period. Intel hardware doesn't support such things, but some other hardware might. However at least HDMI doesn't allow having sync pulse edges within the active period, so I'm thinking the check is probably OK to have in the common code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/host1x/syncpt.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud