summaryrefslogtreecommitdiff
path: root/drivers/video
diff options
context:
space:
mode:
authorTomi Valkeinen <tomi.valkeinen@ti.com>2015-04-10 12:48:37 +0300
committerTomi Valkeinen <tomi.valkeinen@ti.com>2015-06-17 15:44:28 +0300
commit3ce17b48da85d89769609c4302a016a1af63cfda (patch)
tree1628bcb8d33d4742ad714bdf57ebf008d55c156a /drivers/video
parentc582935c00227b4efc79630b149b1f077d7716b2 (diff)
downloadlinux-3ce17b48da85d89769609c4302a016a1af63cfda.tar.xz
OMAPDSS: DISPC: check if scaling setup failed
The DISPC's scaling code seems to presume that decimation always succeeds, and so we always do find a suitable downscaling setup. However, this is not the case, and the algorithm can fail. When that happens, the code just proceeds with wrong results, causing issues later. Add the necessary checks to bail out if the scaling algorithm failed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Diffstat (limited to 'drivers/video')
-rw-r--r--drivers/video/fbdev/omap2/dss/dispc.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c
index 2db1c986e989..0bdb587cb48c 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2279,6 +2279,11 @@ static int dispc_ovl_calc_scaling_24xx(unsigned long pclk, unsigned long lclk,
}
} while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error);
+ if (error) {
+ DSSERR("failed to find scaling settings\n");
+ return -EINVAL;
+ }
+
if (in_width > maxsinglelinewidth) {
DSSERR("Cannot scale max input width exceeded");
return -EINVAL;
@@ -2356,6 +2361,11 @@ again:
}
} while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error);
+ if (error) {
+ DSSERR("failed to find scaling settings\n");
+ return -EINVAL;
+ }
+
if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, in_width,
in_height, out_width, out_height, *five_taps)) {
DSSERR("horizontal timing too tight\n");