From 3397cc6a7199993150d09d9bf055ae130058a684 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Thu, 9 Apr 2015 13:51:30 +0300 Subject: OMAPDSS: DISPC: work-around for errata i631 Errata i631 description: "When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when fetching Chroma sampling." Workaround: "If YUV4:2:0-1D burst is required: Set DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3" The description is somewhat confusing, but testing has shown that DSS fetches extra rows from memory when using NV12 format in 1D mode. If the memory after the framebuffer is inaccessible, this leads to OCP errors. The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only need to handle the ROTATION part. The issue exist on all OMAP4 and OMAP5 based DSS IPs. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index f4fc77d9d3bf..a074d8b70591 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -1741,6 +1741,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation, row_repeat = false; } + /* + * OMAP4/5 Errata i631: + * NV12 in 1D mode must use ROTATION=1. Otherwise DSS will fetch extra + * rows beyond the framebuffer, which may cause OCP error. + */ + if (color_mode == OMAP_DSS_COLOR_NV12 && + rotation_type != OMAP_DSS_ROT_TILER) + vidrot = 1; + REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), vidrot, 13, 12); if (dss_has_feature(FEAT_ROWREPEATENABLE)) REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), -- cgit v1.2.3 From c4661b33181708cddb96c72f629eae9cdeea271f Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 27 Feb 2015 13:07:58 +0200 Subject: OMAPDSS: DISPC: fix predecimation for YUV modes DISPC needs even input buffer width for YUV modes. The DISPC driver doesn't check this at the moment (although omapdrm does), but worse, when DISPC driver does x predecimation the result may be uneven. This causes sometimes sync losts, underflows, or just visual errors. This patch makes DISPC driver return an error if the user gives uneven input width for a YUV buffer. It also makes the input width even in case of predecimation. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 36 +++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index a074d8b70591..db60aa98f661 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2542,6 +2542,21 @@ static int dispc_ovl_setup_common(enum omap_plane plane, if (paddr == 0 && rotation_type != OMAP_DSS_ROT_TILER) return -EINVAL; + switch (color_mode) { + case OMAP_DSS_COLOR_YUV2: + case OMAP_DSS_COLOR_UYVY: + case OMAP_DSS_COLOR_NV12: + if (in_width & 1) { + DSSERR("input width %d is not even for YUV format\n", + in_width); + return -EINVAL; + } + break; + + default: + break; + } + out_width = out_width == 0 ? width : out_width; out_height = out_height == 0 ? height : out_height; @@ -2572,6 +2587,27 @@ static int dispc_ovl_setup_common(enum omap_plane plane, in_width = in_width / x_predecim; in_height = in_height / y_predecim; + if (x_predecim > 1 || y_predecim > 1) + DSSDBG("predecimation %d x %x, new input size %d x %d\n", + x_predecim, y_predecim, in_width, in_height); + + switch (color_mode) { + case OMAP_DSS_COLOR_YUV2: + case OMAP_DSS_COLOR_UYVY: + case OMAP_DSS_COLOR_NV12: + if (in_width & 1) { + DSSDBG("predecimated input width is not even for YUV format\n"); + DSSDBG("adjusting input width %d -> %d\n", + in_width, in_width & ~1); + + in_width &= ~1; + } + break; + + default: + break; + } + if (color_mode == OMAP_DSS_COLOR_YUV2 || color_mode == OMAP_DSS_COLOR_UYVY || color_mode == OMAP_DSS_COLOR_NV12) -- cgit v1.2.3 From f5a734827b07dc907ae95698f91d4b1eaafe9a8a Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 17 Mar 2015 15:31:09 +0200 Subject: OMAPDSS: DISPC: fix check_horiz_timing_omap3 args After calculating the required decimation for scaling, the dispc driver checks once more if the resulting configuration is valid by calling check_horiz_timing_omap3(). Earlier calls to this function have correctly used in_width and in_height as parameters, but the last call uses width and height. This causes the driver to possibly reject scaling that would work. This patch fixes the parameters. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index db60aa98f661..cc61513afdb4 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2338,8 +2338,8 @@ again: } } while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error); - if (check_horiz_timing_omap3(pclk, lclk, mgr_timings, pos_x, width, - height, out_width, out_height, *five_taps)) { + 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"); return -EINVAL; } -- cgit v1.2.3 From ab6b2582b8f931f8f324fbf7bcb8338b8fc1eded Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 17 Mar 2015 15:31:10 +0200 Subject: OMAPDSS: DISPC: add check for scaling limits On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After studying this, I found that sometimes the driver uses three-tap scaling with downscaling factor smaller than x0.5. This causes issues, as x0.5 is the limit for three-tap scaling. The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for five-tap scaling, which allows scaling down to x0.25. This patch adds checks for both horizontal and vertical scaling. For horizontal the HW always uses 5 taps, so the limit is x0.25. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index cc61513afdb4..ddce8fcfc5c1 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2326,6 +2326,21 @@ again: error = (error || in_width > maxsinglelinewidth * 2 || (in_width > maxsinglelinewidth && *five_taps) || !*core_clk || *core_clk > dispc_core_clk_rate()); + + if (!error) { + /* verify that we're inside the limits of scaler */ + if (in_width / 4 > out_width) + error = 1; + + if (*five_taps) { + if (in_height / 4 > out_height) + error = 1; + } else { + if (in_height / 2 > out_height) + error = 1; + } + } + if (error) { if (*decim_x == *decim_y) { *decim_x = min_factor; -- cgit v1.2.3 From f2aee319d95fcba3d29424aeaf6d39d4c2a7890a Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 10 Apr 2015 12:48:34 +0300 Subject: OMAPDSS: DISPC: fix row_inc for OMAP3 pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the line, after the last pixel, whereas on OMAP4+ it is. The driver currently works for OMAP4+, but does not handle OMAP2/3 correctly, which leads to tilted image when row_inc is used. This patch adds a flag to DISPC driver so that the pixel_inc is added when required. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index ddce8fcfc5c1..4488d9367bd3 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -95,6 +95,9 @@ struct dispc_features { bool mstandby_workaround:1; bool set_max_preload:1; + + /* PIXEL_INC is not added to the last pixel of a line */ + bool last_pixel_inc_missing:1; }; #define DISPC_MAX_NR_FIFOS 5 @@ -2692,6 +2695,9 @@ static int dispc_ovl_setup_common(enum omap_plane plane, dispc_ovl_set_ba1_uv(plane, p_uv_addr + offset1); } + if (dispc.feat->last_pixel_inc_missing) + row_inc += pix_inc - 1; + dispc_ovl_set_row_inc(plane, row_inc); dispc_ovl_set_pix_inc(plane, pix_inc); @@ -3769,6 +3775,7 @@ static const struct dispc_features omap24xx_dispc_feats __initconst = { .num_fifos = 3, .no_framedone_tv = true, .set_max_preload = false, + .last_pixel_inc_missing = true, }; static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = { @@ -3789,6 +3796,7 @@ static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = { .num_fifos = 3, .no_framedone_tv = true, .set_max_preload = false, + .last_pixel_inc_missing = true, }; static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = { @@ -3809,6 +3817,7 @@ static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = { .num_fifos = 3, .no_framedone_tv = true, .set_max_preload = false, + .last_pixel_inc_missing = true, }; static const struct dispc_features omap44xx_dispc_feats __initconst = { -- cgit v1.2.3 From c582935c00227b4efc79630b149b1f077d7716b2 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 10 Apr 2015 12:48:36 +0300 Subject: OMAPDSS: DISPC: fix 64 bit issue in 5-tap The DISPC driver uses 64 bit arithmetic to calculate the required clock rate for scaling. The code does not seem to work correctly, and instead calculates with 32 bit numbers, giving wrong result. Fix the code by typecasting values to u64 first, so that the calculations do happen in 64 bits. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index 4488d9367bd3..2db1c986e989 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2166,7 +2166,7 @@ static unsigned long calc_core_clk_five_taps(unsigned long pclk, if (height > out_height) { unsigned int ppl = mgr_timings->x_res; - tmp = pclk * height * out_width; + tmp = (u64)pclk * height * out_width; do_div(tmp, 2 * out_height * ppl); core_clk = tmp; @@ -2174,14 +2174,14 @@ static unsigned long calc_core_clk_five_taps(unsigned long pclk, if (ppl == out_width) return 0; - tmp = pclk * (height - 2 * out_height) * out_width; + tmp = (u64)pclk * (height - 2 * out_height) * out_width; do_div(tmp, 2 * out_height * (ppl - out_width)); core_clk = max_t(u32, core_clk, tmp); } } if (width > out_width) { - tmp = pclk * width; + tmp = (u64)pclk * width; do_div(tmp, out_width); core_clk = max_t(u32, core_clk, tmp); -- cgit v1.2.3 From 3ce17b48da85d89769609c4302a016a1af63cfda Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 10 Apr 2015 12:48:37 +0300 Subject: 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 --- drivers/video/fbdev/omap2/dss/dispc.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'drivers/video') 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"); -- cgit v1.2.3 From 7059e3d8d8f0d716f8a6664f365bcbef9d147905 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 10 Apr 2015 12:48:38 +0300 Subject: OMAPDSS: DISPC: do only y decimation on OMAP3 The current driver does both x and y decimation on OMAP3 DSS. Testing shows that x decimation rarely works, leading to underflows. The exact reason for this is unclear, as the underflows seem to happen even with low pixel clock rates, and I would presume that if the DSS can manage a display with 140MHz pixel clock, it could manage x decimation with factor 2 with a low pixel clock (~30MHz). So it is possible that there is a problem somewhere else, in memory management, or DSS DMA, or similar. I have not found anything that would help this. So, to fix the downscaling scaling, this patch removes x decimation for OMAP3. This will limit some of the more demanding downscaling scenarios, but one could argue that using DSS to downscale such a large amount is insane in the first place, as the produced image is rather bad quality. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index 0bdb587cb48c..646d94a71a79 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2300,7 +2300,6 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long pclk, unsigned long lclk, { int error; u16 in_width, in_height; - int min_factor = min(*decim_x, *decim_y); const int maxsinglelinewidth = dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH); @@ -2349,16 +2348,8 @@ again: } } - if (error) { - if (*decim_x == *decim_y) { - *decim_x = min_factor; - ++*decim_y; - } else { - swap(*decim_x, *decim_y); - if (*decim_x < *decim_y) - ++*decim_x; - } - } + if (error) + ++*decim_y; } while (*decim_x <= *x_predecim && *decim_y <= *y_predecim && error); if (error) { -- cgit v1.2.3 From e4c5ae7fdfa6cae39b458abb99ed669ba3c19af0 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Fri, 10 Apr 2015 12:48:39 +0300 Subject: OMAPDSS: DISPC: scaler debug print Improve the DISPC debug print for scaling. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/dispc.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index 646d94a71a79..f8c9115cdb4b 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2418,6 +2418,9 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long pclk, unsigned long lclk, return 0; } +#define DIV_FRAC(dividend, divisor) \ + ((dividend) * 100 / (divisor) - ((dividend) / (divisor) * 100)) + static int dispc_ovl_calc_scaling(unsigned long pclk, unsigned long lclk, enum omap_overlay_caps caps, const struct omap_video_timings *mgr_timings, @@ -2477,8 +2480,19 @@ static int dispc_ovl_calc_scaling(unsigned long pclk, unsigned long lclk, if (ret) return ret; - DSSDBG("required core clk rate = %lu Hz\n", core_clk); - DSSDBG("current core clk rate = %lu Hz\n", dispc_core_clk_rate()); + DSSDBG("%dx%d -> %dx%d (%d.%02d x %d.%02d), decim %dx%d %dx%d (%d.%02d x %d.%02d), taps %d, req clk %lu, cur clk %lu\n", + width, height, + out_width, out_height, + out_width / width, DIV_FRAC(out_width, width), + out_height / height, DIV_FRAC(out_height, height), + + decim_x, decim_y, + width / decim_x, height / decim_y, + out_width / (width / decim_x), DIV_FRAC(out_width, width / decim_x), + out_height / (height / decim_y), DIV_FRAC(out_height, height / decim_y), + + *five_taps ? 5 : 3, + core_clk, dispc_core_clk_rate()); if (!core_clk || core_clk > dispc_core_clk_rate()) { DSSERR("failed to set up scaling, " -- cgit v1.2.3 From 9bba13f0d74cea808f417370961bb3421a09bcb6 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 24 Mar 2015 15:46:33 +0200 Subject: OMAPDSS: HDMI4: fix error handling Error handling in hdmi_power_on_full() is not correct, and could leave resources unfreed. Fix this by arranging the error labels correctly. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/hdmi4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 916d47978f41..e1345abd41bb 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -229,9 +229,9 @@ static int hdmi_power_on_full(struct omap_dss_device *dssdev) err_mgr_enable: hdmi_wp_video_stop(&hdmi.wp); err_vid_enable: -err_phy_cfg: hdmi_wp_set_phy_pwr(&hdmi.wp, HDMI_PHYPWRCMD_OFF); err_phy_pwr: +err_phy_cfg: err_pll_cfg: dss_pll_disable(&hdmi.pll.pll); err_pll_enable: -- cgit v1.2.3 From a9fad6886f5229fc9989ac6cdd7ddecbf570a58f Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Tue, 24 Mar 2015 15:46:34 +0200 Subject: OMAPDSS: HDMI: wait for framedone when stopping video At the moment when HDMI video output is stopped, we just clear the enable bit and return. While it's unclear if this can cause any issues, I think it's still better to wait for FRAMEDONE interrupt after clearing the enable bit so that we're sure the HDMI IP has finished. As we don't have any ready-made irq handling for HDMI, and this only needs to be done when disabling the HDMI output, this patch implements a simple loop with sleep, polling the FRAMEDONE bit. Signed-off-by: Tomi Valkeinen --- drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'drivers/video') diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c index c15377e242cc..7c544bc56fb5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c @@ -110,7 +110,23 @@ int hdmi_wp_video_start(struct hdmi_wp_data *wp) void hdmi_wp_video_stop(struct hdmi_wp_data *wp) { + int i; + + hdmi_write_reg(wp->base, HDMI_WP_IRQSTATUS, HDMI_IRQ_VIDEO_FRAME_DONE); + REG_FLD_MOD(wp->base, HDMI_WP_VIDEO_CFG, false, 31, 31); + + for (i = 0; i < 50; ++i) { + u32 v; + + msleep(20); + + v = hdmi_read_reg(wp->base, HDMI_WP_IRQSTATUS_RAW); + if (v & HDMI_IRQ_VIDEO_FRAME_DONE) + return; + } + + DSSERR("no HDMI FRAMEDONE when disabling output\n"); } void hdmi_wp_video_config_format(struct hdmi_wp_data *wp, -- cgit v1.2.3