Linux Framebuffer Layer development
 help / color / mirror / Atom feed
* [PATCH v2 9/9] staging: sm7xxfb: fix camelcase
From: Sudip Mukherjee @ 2015-06-17 11:36 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: linux-fbdev, devel, linux-kernel, Joe Perches, Sudip Mukherjee
In-Reply-To: <1434540288-8289-1-git-send-email-sudipm.mukherjee@gmail.com>

Fix the checkpatch warning about CamelCase.

Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
 drivers/staging/sm7xxfb/sm7xx.h   | 2 +-
 drivers/staging/sm7xxfb/sm7xxfb.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index fc28429..4bed094 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -98,7 +98,7 @@ static inline unsigned int smtc_seqr(int reg)
 /* The next structure holds all information relevant for a specific video mode.
  */
 
-struct ModeInit {
+struct modeinit {
 	int mmsizex;
 	int mmsizey;
 	int bpp;
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 24688a3..b906305 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -114,7 +114,7 @@ static const struct vesa_mode vesa_mode_table[] = {
 /**********************************************************************
 			 SM712 Mode table.
  **********************************************************************/
-static const struct ModeInit vgamode[] = {
+static const struct modeinit vgamode[] = {
 	{
 		/*  mode#0: 640 x 480  16Bpp  60Hz */
 		640, 480, 16, 60,
-- 
1.8.1.2


^ permalink raw reply related

* Re: [PATCH 7/8] staging: sm7xxfb: move mode table
From: Sudip Mukherjee @ 2015-06-17 11:42 UTC (permalink / raw)
  To: Joe Perches; +Cc: Greg Kroah-Hartman, linux-fbdev, devel, linux-kernel
In-Reply-To: <1434529234.2689.69.camel@perches.com>

On Wed, Jun 17, 2015 at 01:20:34AM -0700, Joe Perches wrote:
> On Wed, 2015-06-17 at 13:45 +0530, Sudip Mukherjee wrote:
> > On Tue, Jun 16, 2015 at 10:33:57AM -0700, Joe Perches wrote:
> > > On Tue, 2015-06-16 at 19:12 +0530, Sudip Mukherjee wrote:
> > > > move vgamode table from the header file to the C file and mark it
> > > > as const.
> > > 
> > > The slightly odd indentation could be fixed here too.
> > Ok. I am sending v2. But if I am reviewing it I will say
> > "you are doing too many things in one patch" :( .
> > so i will fix the indention the other patch which is fixing indention.
> 
> You could send a follow-up patch to fix it rather than send
> a v3 of everything.

v2 already sent and seeing your mail after sending. No problem,
everything will be fixed at a time.

regards
sudip
> 
> cheers, Joe
> 

^ permalink raw reply

* [PATCH 00/11] OMAPDSS: scaling & misc fixes
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen

Hi,

Here are some mostly scaling related fixes for omapdss, forward ported from
TI's kernel (i.e. they've seen quite a bit of testing there).

 Tomi

Tomi Valkeinen (11):
  OMAPDSS: DISPC: work-around for errata i631
  OMAPDSS: DISPC: fix predecimation for YUV modes
  OMAPDSS: DISPC: fix check_horiz_timing_omap3 args
  OMAPDSS: DISPC: add check for scaling limits
  OMAPDSS: DISPC: fix row_inc for OMAP3
  OMAPDSS: DISPC: fix 64 bit issue in 5-tap
  OMAPDSS: DISPC: check if scaling setup failed
  OMAPDSS: DISPC: do only y decimation on OMAP3
  OMAPDSS: DISPC: scaler debug print
  OMAPDSS: HDMI4: fix error handling
  OMAPDSS: HDMI: wait for framedone when stopping video

 drivers/video/fbdev/omap2/dss/dispc.c   | 114 +++++++++++++++++++++++++++-----
 drivers/video/fbdev/omap2/dss/hdmi4.c   |   2 +-
 drivers/video/fbdev/omap2/dss/hdmi_wp.c |  16 +++++
 3 files changed, 116 insertions(+), 16 deletions(-)

-- 
2.1.4


^ permalink raw reply

* [PATCH 01/11] OMAPDSS: DISPC: work-around for errata i631
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

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),
-- 
2.1.4


^ permalink raw reply related

* [PATCH 02/11] OMAPDSS: DISPC: fix predecimation for YUV modes
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 36 +++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

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)
-- 
2.1.4


^ permalink raw reply related

* [PATCH 03/11] OMAPDSS: DISPC: fix check_horiz_timing_omap3 args
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

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;
 	}
-- 
2.1.4


^ permalink raw reply related

* [PATCH 04/11] OMAPDSS: DISPC: add check for scaling limits
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

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;
-- 
2.1.4


^ permalink raw reply related

* [PATCH 05/11] OMAPDSS: DISPC: fix row_inc for OMAP3
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

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 = {
-- 
2.1.4


^ permalink raw reply related

* [PATCH 06/11] OMAPDSS: DISPC: fix 64 bit issue in 5-tap
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

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);
 
-- 
2.1.4


^ permalink raw reply related

* [PATCH 07/11] OMAPDSS: DISPC: check if scaling setup failed
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

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");
-- 
2.1.4


^ permalink raw reply related

* [PATCH 08/11] OMAPDSS: DISPC: do only y decimation on OMAP3
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

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) {
-- 
2.1.4


^ permalink raw reply related

* [PATCH 09/11] OMAPDSS: DISPC: scaler debug print
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

Improve the DISPC debug print for scaling.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/dispc.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

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, "
-- 
2.1.4


^ permalink raw reply related

* [PATCH 10/11] OMAPDSS: HDMI4: fix error handling
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/hdmi4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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:
-- 
2.1.4


^ permalink raw reply related

* [PATCH 11/11] OMAPDSS: HDMI: wait for framedone when stopping video
From: Tomi Valkeinen @ 2015-06-17 12:54 UTC (permalink / raw)
  To: Laurent Pinchart, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1434545675-477-1-git-send-email-tomi.valkeinen@ti.com>

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 <tomi.valkeinen@ti.com>
---
 drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

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,
-- 
2.1.4


^ permalink raw reply related

* [PATCH] nvidia/noveau: Fix color mask
From: Michael Büsch @ 2015-06-17 17:05 UTC (permalink / raw)
  To: dri-devel, David Airlie, Antonino Daplas, linux-fbdev

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

The expression (~0 >> x) will always yield all-ones, because the right
shift is an arithmetic right shift that will always shift ones in.
Accordingly ~(~0 >> x) will always be zero.
Hence 'mask' will always be zero in this case.

Fix this by forcing a logical right shift instead of an arithmetic
right shift by using an unsigned int constant.

Signed-off-by: Michael Buesch <m@bues.ch>

---

This patch is untested, because I do not have the hardware.


Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
===================================================================
--- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
@@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
 	struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
 	struct nouveau_channel *chan = drm->channel;
 	uint32_t width, dwords, *data = (uint32_t *)image->data;
-	uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+	uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
 	uint32_t *palette = info->pseudo_palette;
 	int ret;
 
Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
===================================================================
--- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
+++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
@@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
 	struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
 	struct nouveau_channel *chan = drm->channel;
 	uint32_t width, dwords, *data = (uint32_t *)image->data;
-	uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+	uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
 	uint32_t *palette = info->pseudo_palette;
 	int ret;
 
Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
===================================================================
--- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
+++ linux/drivers/video/fbdev/nvidia/nv_accel.c
@@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
 				       const struct fb_image *image)
 {
 	struct nvidia_par *par = info->par;
-	u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
+	u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
 	u32 dsize, width, *data = (u32 *) image->data, tmp;
 	int j, k = 0;
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [Cocci] [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-06-17 17:32 UTC (permalink / raw)
  To: cocci
In-Reply-To: <55810E42.4080500@ti.com>

On Wed, Jun 17, 2015 at 09:05:54AM +0300, Tomi Valkeinen wrote:
> Hi Luis,
> 
> On 16/06/15 22:05, Luis R. Rodriguez wrote:
> 
> > Can the fbdev parts go through Bjorn's tree? We last discussed if the series
> > was important to be fully merged or not by v4.2 and I recentlty provided a
> > long winded review of the entire series to help maintainers pick and choose
> > and decide [1].
> > 
> > Based on this can the fbdev patches from both of these series go through Bjorn's tree?
> 
> Yes, they can go through Bjorn's tree if there are no non-trivial
> conflicts with the main fbdev stuff. linux-next should contain all the
> fbdev patches going for 4.2.

Great, thanks Tomi.

  Luis

^ permalink raw reply

* [PATCH] framebuffer: disable vgacon on microblaze arch
From: Nicolai Stange @ 2015-06-17 19:40 UTC (permalink / raw)
  To: Jean-Christophe Plagniol-Villard; +Cc: Geert Uytterhoeven

Fix an allmodconfig link failer on microblaze:
  drivers/built-in.o: In function `vgacon_save_screen':
  drivers/video/console/.tmp_vgacon.o:(.text+0x8fc10):
    undefined reference to `screen_info'

Disable vgacon on microblaze because the symbol
  struct screen_info screen_info;
is not defined for the microblaze arch.

Signed-off-by: Nicolai Stange <nicstange@gmail.com>
---
 Note that this patch does not apply to the framebuffer maintainer repo
   kernel/git/plagnioj/linux-fbdev.git
 listed in MAINTAINERS since that one has not got
 ee23794b8668 ("video: vgacon: Don't build on arm64").
 This prerequisite patch has been merged from
   kernel/git/tomba/linux.git  fbdev-3.14
 into mainline in b788769e0641.

 The attached diff applies to both, the mainline tree and
 Tomi Valkeinen's tree (branch baseline-2015).

 drivers/video/console/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index ba97efc..e0dc0fe 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -9,7 +9,7 @@ config VGA_CONSOLE
 	depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && \
 		!SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
 		(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) && \
-		!ARM64
+		!ARM64 && !MICROBLAZE
 	default y
 	help
 	  Saying Y here will allow you to use Linux in text mode through a
-- 
2.4.3


^ permalink raw reply related

* Re: [PATCH] nvidia/noveau: Fix color mask
From: Ilia Mirkin @ 2015-06-18  0:47 UTC (permalink / raw)
  To: Michael Büsch
  Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Antonino Daplas, David Airlie,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Ben Skeggs
In-Reply-To: <20150617190508.5205e8af@wiggum>

On Wed, Jun 17, 2015 at 1:05 PM, Michael Büsch <m@bues.ch> wrote:
> The expression (~0 >> x) will always yield all-ones, because the right
> shift is an arithmetic right shift that will always shift ones in.
> Accordingly ~(~0 >> x) will always be zero.
> Hence 'mask' will always be zero in this case.
>
> Fix this by forcing a logical right shift instead of an arithmetic
> right shift by using an unsigned int constant.
>
> Signed-off-by: Michael Buesch <m@bues.ch>

Confirmed that this does indeed happen with

#include <stdio.h>
int main(int argc, char *argv[]) {
  unsigned mask = ~(~0 >> (32 - (argv[1][0] - '0')));
  printf("%08x\n", mask);
}

I guess fbdev/nvidia/nv_accel.c was the source of all this, as the
code is identical, and it probably came first.

FWIW this is

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>


>
> ---
>
> This patch is untested, because I do not have the hardware.
>
>
> Index: linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
> =================================> --- linux.orig/drivers/gpu/drm/nouveau/nv50_fbcon.c
> +++ linux/drivers/gpu/drm/nouveau/nv50_fbcon.c
> @@ -96,7 +96,7 @@ nv50_fbcon_imageblit(struct fb_info *inf
>         struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
>         struct nouveau_channel *chan = drm->channel;
>         uint32_t width, dwords, *data = (uint32_t *)image->data;
> -       uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> +       uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
>         uint32_t *palette = info->pseudo_palette;
>         int ret;
>
> Index: linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> =================================> --- linux.orig/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> +++ linux/drivers/gpu/drm/nouveau/nvc0_fbcon.c
> @@ -96,7 +96,7 @@ nvc0_fbcon_imageblit(struct fb_info *inf
>         struct nouveau_drm *drm = nouveau_drm(nfbdev->dev);
>         struct nouveau_channel *chan = drm->channel;
>         uint32_t width, dwords, *data = (uint32_t *)image->data;
> -       uint32_t mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> +       uint32_t mask = ~(~0U >> (32 - info->var.bits_per_pixel));
>         uint32_t *palette = info->pseudo_palette;
>         int ret;
>
> Index: linux/drivers/video/fbdev/nvidia/nv_accel.c
> =================================> --- linux.orig/drivers/video/fbdev/nvidia/nv_accel.c
> +++ linux/drivers/video/fbdev/nvidia/nv_accel.c
> @@ -351,7 +351,7 @@ static void nvidiafb_mono_color_expand(s
>                                        const struct fb_image *image)
>  {
>         struct nvidia_par *par = info->par;
> -       u32 fg, bg, mask = ~(~0 >> (32 - info->var.bits_per_pixel));
> +       u32 fg, bg, mask = ~(~0U >> (32 - info->var.bits_per_pixel));
>         u32 dsize, width, *data = (u32 *) image->data, tmp;
>         int j, k = 0;
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

^ permalink raw reply

* Re: [PATCH v2 0/9] fix sm7xxfb
From: Greg Kroah-Hartman @ 2015-06-18  4:43 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: devel, Joe Perches, linux-fbdev, linux-kernel
In-Reply-To: <1434540288-8289-1-git-send-email-sudipm.mukherjee@gmail.com>

On Wed, Jun 17, 2015 at 04:54:39PM +0530, Sudip Mukherjee wrote:
> fixing the few remaining issues of sm7xxfb before sending the patch to
> remove it from staging.
> Also attempted to setup a tree and all the patches of this series are
> available there for you.
> 
> 
> The following changes since commit f0feeaff9c60bfb3dbadf09da15d70cf35700f29:
> 
>   staging: wilc1000: remove unwanted code (2015-06-16 19:23:25 -0700)
> 
> are available in the git repository at:
> 
>   git://git.vectorindia.net/staging staging-testing

Sorry, I don't take git pulls for staging patches.


^ permalink raw reply

* Re: [PATCH v2 0/9] fix sm7xxfb
From: Greg Kroah-Hartman @ 2015-06-18  4:45 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: devel, Joe Perches, linux-fbdev, linux-kernel
In-Reply-To: <20150618044351.GA26238@kroah.com>

On Wed, Jun 17, 2015 at 09:43:51PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jun 17, 2015 at 04:54:39PM +0530, Sudip Mukherjee wrote:
> > fixing the few remaining issues of sm7xxfb before sending the patch to
> > remove it from staging.

Oh, the BIG_ENDIAN defines need to be fixed up, surely that can be done
in a more "correct" way.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v2 0/9] fix sm7xxfb
From: Sudip Mukherjee @ 2015-06-18  8:49 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: devel, Joe Perches, linux-fbdev, linux-kernel
In-Reply-To: <20150618044540.GA3779@kroah.com>

On Wed, Jun 17, 2015 at 09:45:40PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jun 17, 2015 at 09:43:51PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Jun 17, 2015 at 04:54:39PM +0530, Sudip Mukherjee wrote:
> > > fixing the few remaining issues of sm7xxfb before sending the patch to
> > > remove it from staging.
> 
> Oh, the BIG_ENDIAN defines need to be fixed up, surely that can be done
> in a more "correct" way.
sure. I wanted to, but I can only check the modification on a
little-endian system so I didnot dare to.

regards
sudip

^ permalink raw reply

* [PATCH] staging: sm750fb: convert pr_err to pr_info
From: Gujulan Elango, Hari Prasath (H.) @ 2015-06-18 12:56 UTC (permalink / raw)
  To: linux-fbdev

From: Hari Prasath Gujulan Elango <hgujulan@visteon.com>

This patch modifies few debug prints from pr_err() to pr_info() as they
fall under that category.

Signed-off-by: Hari Prasath Gujulan Elango <hgujulan@visteon.com>
---
 drivers/staging/sm750fb/sm750.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 6b642d7..3f30bc0 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -338,7 +338,7 @@ static int lynxfb_ops_set_par(struct fb_info *info)
 	line_length = var->xres_virtual * var->bits_per_pixel / 8;
 	line_length = PADDING(crtc->line_pad, line_length);
 	fix->line_length = line_length;
-	pr_err("fix->line_length = %d\n", fix->line_length);
+	pr_info("fix->line_length = %d\n", fix->line_length);
 
 	/* var->red,green,blue,transp are need to be set by driver
 	 * and these data should be set before setcolreg routine
@@ -1021,8 +1021,8 @@ static void sm750fb_setup(struct lynx_share *share, char *src)
 	}
 
 	while ((opt = strsep(&src, ":")) != NULL && *opt != 0) {
-		pr_err("opt=%s\n", opt);
-		pr_err("src=%s\n", src);
+		pr_info("opt=%s\n", opt);
+		pr_info("src=%s\n", src);
 
 		if (!strncmp(opt, "swap", strlen("swap")))
 			swap = 1;
-- 
1.9.1

^ permalink raw reply related

* [PATCH] fbdev: remove unnecessary memset in vfb
From: Marcin Chojnacki @ 2015-06-18 13:01 UTC (permalink / raw)
  To: plagnioj; +Cc: tomi.valkeinen, linux-fbdev, linux-kernel, Marcin Chojnacki

In vfb_probe memory is allocated using rvmalloc which automatically
sets the allocated memory to zero. This patch removes the second
unnecessary memset in vfb_probe.

Signed-off-by: Marcin Chojnacki <marcinch7@gmail.com>
---
 drivers/video/fbdev/vfb.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/video/fbdev/vfb.c b/drivers/video/fbdev/vfb.c
index 70a897b..b2d38b7 100644
--- a/drivers/video/fbdev/vfb.c
+++ b/drivers/video/fbdev/vfb.c
@@ -490,14 +490,6 @@ static int vfb_probe(struct platform_device *dev)
 	if (!(videomemory = rvmalloc(videomemorysize)))
 		return retval;
 
-	/*
-	 * VFB must clear memory to prevent kernel info
-	 * leakage into userspace
-	 * VGA-based drivers MUST NOT clear memory if
-	 * they want to be able to take over vgacon
-	 */
-	memset(videomemory, 0, videomemorysize);
-
 	info = framebuffer_alloc(sizeof(u32) * 256, &dev->dev);
 	if (!info)
 		goto err;
-- 
2.1.4


^ permalink raw reply related

* Re: [PATCH] nvidia/noveau: Fix color mask
From: Michael Büsch @ 2015-06-18 15:31 UTC (permalink / raw)
  To: Ilia Mirkin
  Cc: linux-fbdev, nouveau@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, Ben Skeggs
In-Reply-To: <CAKb7UvjUdOSrYE4L3AqE3Q06mXyyon42U26o9t3M5XLYz2aJmw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On Wed, 17 Jun 2015 20:47:17 -0400
Ilia Mirkin <imirkin@alum.mit.edu> wrote:

> On Wed, Jun 17, 2015 at 1:05 PM, Michael Büsch <m@bues.ch> wrote:
> > The expression (~0 >> x) will always yield all-ones, because the right
> > shift is an arithmetic right shift that will always shift ones in.
> > Accordingly ~(~0 >> x) will always be zero.
> > Hence 'mask' will always be zero in this case.
> >
> > Fix this by forcing a logical right shift instead of an arithmetic
> > right shift by using an unsigned int constant.
> >
> > Signed-off-by: Michael Buesch <m@bues.ch>
> 
> Confirmed that this does indeed happen with
> 
> #include <stdio.h>
> int main(int argc, char *argv[]) {
>   unsigned mask = ~(~0 >> (32 - (argv[1][0] - '0')));
>   printf("%08x\n", mask);
> }
> 
> I guess fbdev/nvidia/nv_accel.c was the source of all this, as the
> code is identical, and it probably came first.


If anybody is able to help me in creating a working semantic patch
(coccinelle) for this, that would be great.

I found this using a very hacky and incorrect spatch (some
version is attached). It throws many false positives, doesn't find all
such bugs and does not create correct patch output (especially the
#define related rule is just meant as a hint).

Some basic thoughts that come to mind that could possibly be statically
checked somehow are:

- right shift of promoted variables. That is stuff like this:
  u8 x, y = 0x0F;
  x = ~y >> 1;
  /* x is 0xF8, not 0x78 as someone might expect. */
- Also check this for typedef'ed types where promotion takes place (that
  are smaller than int)?
- right shift of signed constants (like in this case). That probably is
  wrong in most cases.
  How to check signedness of constants in spatch? (123 vs 123U)
  Is that even possible?
- Also detect this stuff, if variables/constants are hidden via #define
  or such:
  #define REGVAL	0x0F
  writereg(REGISTER, ~REGVAL >> 1);

Probably more stuff could be checked. Ideas are welcome. :)

-- 
Michael



@@
u8 e;
expression s;
@@
- ~e >> s
+ (u8)~e >> s

@@
s8 e;
expression s;
@@
- ~e >> s
+ (s8)~e >> s

@@
u16 e;
expression s;
@@
- ~e >> s
+ (u16)~e >> s

@@
s16 e;
expression s;
@@
- ~e >> s
+ (s16)~e >> s

@@
char e;
expression s;
@@
- ~e >> s
+ (char)~e >> s

@@
unsigned char e;
expression s;
@@
- ~e >> s
+ (unsigned char)~e >> s

@@
short e;
expression s;
@@
- ~e >> s
+ (short)~e >> s

@@
unsigned short e;
expression s;
@@
- ~e >> s
+ (unsigned short)~e >> s




@@
constant c;
expression s;
@@
- ~c >> s
+ (unsigned int)~c >> s





@sh expression@
identifier val;
expression shift;
@@
val >> shift


@@
expression e;
identifier sh.val;
@@
- #define val ~e
+ #define val e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* [PATCH] drivers: staging: sm750fb: Fix "'foo * bar' should be 'foo *bar'" errors
From: Greg Donald @ 2015-06-18 20:06 UTC (permalink / raw)
  To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman, linux-fbdev,
	devel, linux-kernel
  Cc: Greg Donald

Fix checkpatch.pl "'foo * bar' should be 'foo *bar'" errors

Signed-off-by: Greg Donald <gdonald@gmail.com>
---
 drivers/staging/sm750fb/ddk750_chip.c  |  2 +-
 drivers/staging/sm750fb/ddk750_help.c  |  4 ++--
 drivers/staging/sm750fb/ddk750_help.h  |  2 +-
 drivers/staging/sm750fb/ddk750_mode.c  |  4 ++--
 drivers/staging/sm750fb/sm750.c        |  2 +-
 drivers/staging/sm750fb/sm750.h        | 26 +++++++++++++-------------
 drivers/staging/sm750fb/sm750_accel.c  | 16 ++++++++--------
 drivers/staging/sm750fb/sm750_accel.h  |  8 ++++----
 drivers/staging/sm750fb/sm750_cursor.c | 14 +++++++-------
 drivers/staging/sm750fb/sm750_cursor.h | 14 +++++++-------
 drivers/staging/sm750fb/sm750_hw.c     | 18 +++++++++---------
 11 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 981736f..f4975d2 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -433,7 +433,7 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
 	unsigned int RN, quo, rem, fl_quo;
 	unsigned int input, request;
 	unsigned int tmpClock, ret;
-	pllcalparam * xparm;
+	pllcalparam *xparm;
 
 #if 1
 	if (getChipType() = SM750LE) {
diff --git a/drivers/staging/sm750fb/ddk750_help.c b/drivers/staging/sm750fb/ddk750_help.c
index 96c18eb..1adcafc 100644
--- a/drivers/staging/sm750fb/ddk750_help.c
+++ b/drivers/staging/sm750fb/ddk750_help.c
@@ -1,11 +1,11 @@
 #include "ddk750_help.h"
 
-void __iomem * mmio750 = NULL;
+void __iomem *mmio750 = NULL;
 char revId750 = 0;
 unsigned short devId750 = 0;
 
 /* after driver mapped io registers, use this function first */
-void ddk750_set_mmio(void __iomem * addr, unsigned short devId, char revId)
+void ddk750_set_mmio(void __iomem *addr, unsigned short devId, char revId)
 {
 	mmio750 = addr;
 	devId750 = devId;
diff --git a/drivers/staging/sm750fb/ddk750_help.h b/drivers/staging/sm750fb/ddk750_help.h
index f99f907..4285b05 100644
--- a/drivers/staging/sm750fb/ddk750_help.h
+++ b/drivers/staging/sm750fb/ddk750_help.h
@@ -19,7 +19,7 @@
 #define POKE32(addr, data) writel(data, addr + mmio750)
 #endif
 
-extern void __iomem * mmio750;
+extern void __iomem *mmio750;
 extern char revId750;
 extern unsigned short devId750;
 #else
diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c
index a054747..74313ff 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -75,7 +75,7 @@ static unsigned long displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
 
 
 /* only timing related registers will be  programed */
-static int programModeRegisters(mode_parameter_t * pModeParam, pll_value_t * pll)
+static int programModeRegisters(mode_parameter_t *pModeParam, pll_value_t *pll)
 {
 	int ret = 0;
 	int cnt = 0;
@@ -185,7 +185,7 @@ static int programModeRegisters(mode_parameter_t * pModeParam, pll_value_t * pll
 	return ret;
 }
 
-int ddk750_setModeTiming(mode_parameter_t * parm, clock_type_t clock)
+int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock)
 {
 	pll_value_t pll;
 	unsigned int uiActualPixelClk;
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 6b642d7..8c35302 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -1087,7 +1087,7 @@ NO_PARAM:
 }
 
 static int lynxfb_pci_probe(struct pci_dev *pdev,
-			    const struct pci_device_id * ent)
+			    const struct pci_device_id *ent)
 {
 	struct fb_info *info[] = {NULL, NULL};
 	struct lynx_share *share = NULL;
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 273882f..cc80580 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -45,8 +45,8 @@ struct lynx_share{
 	/* common members */
 	u16 devid;
 	u8 revid;
-	struct pci_dev * pdev;
-	struct fb_info * fbinfo[2];
+	struct pci_dev *pdev;
+	struct fb_info *fbinfo[2];
 	struct lynx_accel accel;
 	int accel_off;
 	int dual;
@@ -59,8 +59,8 @@ struct lynx_share{
 	unsigned long vidreg_start;
 	__u32 vidmem_size;
 	__u32 vidreg_size;
-	void __iomem * pvReg;
-	unsigned char __iomem * pvMem;
+	void __iomem *pvReg;
+	unsigned char __iomem *pvMem;
 	/* locks*/
 	spinlock_t slock;
 	/* function pointers */
@@ -77,12 +77,12 @@ struct lynx_cursor{
 	int maxW;
 	int maxH;
 	/* base virtual address and offset  of cursor image */
-	char __iomem * vstart;
+	char __iomem *vstart;
 	int offset;
 	/* mmio addr of hw cursor */
 	volatile char __iomem * mmio;
 	/* the lynx_share of this adaptor */
-	struct lynx_share * share;
+	struct lynx_share *share;
 	/* proc_routines */
 	void (*enable)(struct lynx_cursor *);
 	void (*disable)(struct lynx_cursor *);
@@ -93,8 +93,8 @@ struct lynx_cursor{
 };
 
 struct lynxfb_crtc{
-	unsigned char __iomem * vCursor; /* virtual address of cursor */
-	unsigned char __iomem * vScreen; /* virtual address of on_screen */
+	unsigned char __iomem *vCursor; /* virtual address of cursor */
+	unsigned char __iomem *vScreen; /* virtual address of on_screen */
 	int oCursor; /* cursor address offset in vidmem */
 	int oScreen; /* onscreen address offset in vidmem */
 	int channel;/* which channel this crtc stands for*/
@@ -106,7 +106,7 @@ struct lynxfb_crtc{
 	u16 ypanstep;
 	u16 ywrapstep;
 
-	void * priv;
+	void *priv;
 
 	int(*proc_setMode)(struct lynxfb_crtc*,
 						struct fb_var_screeninfo*,
@@ -132,13 +132,13 @@ struct lynxfb_output{
 		paths=3:means output for both panel and crt paths
 	*/
 
-	int * channel;
+	int *channel;
 	/* 	which channel these outputs linked with,for sm750:
 		*channel=0 means primary channel
 		*channel=1 means secondary channel
 		output->channel => &crtc->channel
 	*/
-	void * priv;
+	void *priv;
 
 	int(*proc_setMode)(struct lynxfb_output*,
 						struct fb_var_screeninfo*,
@@ -155,8 +155,8 @@ struct lynxfb_par{
 	unsigned int pseudo_palette[256];
 	struct lynxfb_crtc crtc;
 	struct lynxfb_output output;
-	struct fb_info * info;
-	struct lynx_share * share;
+	struct fb_info *info;
+	struct lynx_share *share;
 };
 
 #ifndef offsetof
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index a2baffd..6eee4cd 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -18,22 +18,22 @@
 #include "sm750.h"
 #include "sm750_accel.h"
 #include "sm750_help.h"
-static inline void write_dpr(struct lynx_accel * accel, int offset, u32 regValue)
+static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
 {
 	writel(regValue, accel->dprBase + offset);
 }
 
-static inline u32 read_dpr(struct lynx_accel * accel, int offset)
+static inline u32 read_dpr(struct lynx_accel *accel, int offset)
 {
 	return readl(accel->dprBase + offset);
 }
 
-static inline void write_dpPort(struct lynx_accel * accel, u32 data)
+static inline void write_dpPort(struct lynx_accel *accel, u32 data)
 {
 	writel(data, accel->dpPortBase);
 }
 
-void hw_de_init(struct lynx_accel * accel)
+void hw_de_init(struct lynx_accel *accel)
 {
 	/* setup 2d engine registers */
 	u32 reg, clr;
@@ -79,7 +79,7 @@ void hw_de_init(struct lynx_accel * accel)
  * but if you need dual framebuffer driver,need call set2dformat
  * every time you use 2d function */
 
-void hw_set2dformat(struct lynx_accel * accel, int fmt)
+void hw_set2dformat(struct lynx_accel *accel, int fmt)
 {
 	u32 reg;
 	
@@ -89,7 +89,7 @@ void hw_set2dformat(struct lynx_accel * accel, int fmt)
 	write_dpr(accel, DE_STRETCH_FORMAT, reg);
 }
 
-int hw_fillrect(struct lynx_accel * accel,
+int hw_fillrect(struct lynx_accel *accel,
 				u32 base, u32 pitch, u32 Bpp,
 				u32 x, u32 y, u32 width, u32 height,
 				u32 color, u32 rop)
@@ -137,7 +137,7 @@ int hw_fillrect(struct lynx_accel * accel,
 }
 
 int hw_copyarea(
-struct lynx_accel * accel,
+struct lynx_accel *accel,
 unsigned int sBase,  /* Address of source: offset in frame buffer */
 unsigned int sPitch, /* Pitch value of source surface in BYTE */
 unsigned int sx,
@@ -303,7 +303,7 @@ unsigned int rop2)   /* ROP value */
     return 0;
 }
 
-static unsigned int deGetTransparency(struct lynx_accel * accel)
+static unsigned int deGetTransparency(struct lynx_accel *accel)
 {
     unsigned int de_ctrl;
 
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index 57e20fb..d3d256c 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -234,17 +234,17 @@
 #define BOTTOM_TO_TOP 1
 #define RIGHT_TO_LEFT 1
 
-void hw_set2dformat(struct lynx_accel * accel, int fmt);
+void hw_set2dformat(struct lynx_accel *accel, int fmt);
 
-void hw_de_init(struct lynx_accel * accel);
+void hw_de_init(struct lynx_accel *accel);
 
-int hw_fillrect(struct lynx_accel * accel,
+int hw_fillrect(struct lynx_accel *accel,
 				u32 base, u32 pitch, u32 Bpp,
 				u32 x, u32 y, u32 width, u32 height,
 				u32 color, u32 rop);
 
 int hw_copyarea(
-struct lynx_accel * accel,
+struct lynx_accel *accel,
 unsigned int sBase,  /* Address of source: offset in frame buffer */
 unsigned int sPitch, /* Pitch value of source surface in BYTE */
 unsigned int sx,
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index cb37ea3..405e24b 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -58,7 +58,7 @@ writel((data), cursor->mmio + (addr))
 
 
 /* hw_cursor_xxx works for voyager,718 and 750 */
-void hw_cursor_enable(struct lynx_cursor * cursor)
+void hw_cursor_enable(struct lynx_cursor *cursor)
 {
 	u32 reg;
 	reg = FIELD_VALUE(0, HWC_ADDRESS, ADDRESS, cursor->offset)|
@@ -66,18 +66,18 @@ void hw_cursor_enable(struct lynx_cursor * cursor)
 			FIELD_SET(0, HWC_ADDRESS, ENABLE, ENABLE);
 	POKE32(HWC_ADDRESS, reg);
 }
-void hw_cursor_disable(struct lynx_cursor * cursor)
+void hw_cursor_disable(struct lynx_cursor *cursor)
 {
 	POKE32(HWC_ADDRESS, 0);
 }
 
-void hw_cursor_setSize(struct lynx_cursor * cursor,
+void hw_cursor_setSize(struct lynx_cursor *cursor,
 						int w, int h)
 {
 	cursor->w = w;
 	cursor->h = h;
 }
-void hw_cursor_setPos(struct lynx_cursor * cursor,
+void hw_cursor_setPos(struct lynx_cursor *cursor,
 						int x, int y)
 {
 	u32 reg;
@@ -85,14 +85,14 @@ void hw_cursor_setPos(struct lynx_cursor * cursor,
 			FIELD_VALUE(0, HWC_LOCATION, X, x);
 	POKE32(HWC_LOCATION, reg);
 }
-void hw_cursor_setColor(struct lynx_cursor * cursor,
+void hw_cursor_setColor(struct lynx_cursor *cursor,
 						u32 fg, u32 bg)
 {
 	POKE32(HWC_COLOR_12, (fg<<16)|(bg&0xffff));
 	POKE32(HWC_COLOR_3, 0xffe0);
 }
 
-void hw_cursor_setData(struct lynx_cursor * cursor,
+void hw_cursor_setData(struct lynx_cursor *cursor,
 			u16 rop, const u8* pcol, const u8* pmsk)
 {
 	int i, j, count, pitch, offset;
@@ -183,7 +183,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
 }
 
 
-void hw_cursor_setData2(struct lynx_cursor * cursor,
+void hw_cursor_setData2(struct lynx_cursor *cursor,
 			u16 rop, const u8* pcol, const u8* pmsk)
 {
 	int i, j, count, pitch, offset;
diff --git a/drivers/staging/sm750fb/sm750_cursor.h b/drivers/staging/sm750fb/sm750_cursor.h
index be58868..e1716a6 100644
--- a/drivers/staging/sm750fb/sm750_cursor.h
+++ b/drivers/staging/sm750fb/sm750_cursor.h
@@ -2,16 +2,16 @@
 #define LYNX_CURSOR_H__
 
 /* hw_cursor_xxx works for voyager,718 and 750 */
-void hw_cursor_enable(struct lynx_cursor * cursor);
-void hw_cursor_disable(struct lynx_cursor * cursor);
-void hw_cursor_setSize(struct lynx_cursor * cursor,
+void hw_cursor_enable(struct lynx_cursor *cursor);
+void hw_cursor_disable(struct lynx_cursor *cursor);
+void hw_cursor_setSize(struct lynx_cursor *cursor,
 						int w, int h);
-void hw_cursor_setPos(struct lynx_cursor * cursor,
+void hw_cursor_setPos(struct lynx_cursor *cursor,
 						int x, int y);
-void hw_cursor_setColor(struct lynx_cursor * cursor,
+void hw_cursor_setColor(struct lynx_cursor *cursor,
 						u32 fg, u32 bg);
-void hw_cursor_setData(struct lynx_cursor * cursor,
+void hw_cursor_setData(struct lynx_cursor *cursor,
 			u16 rop, const u8* data, const u8* mask);
-void hw_cursor_setData2(struct lynx_cursor * cursor,
+void hw_cursor_setData2(struct lynx_cursor *cursor,
 			u16 rop, const u8* data, const u8* mask);
 #endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index e70961e..84381bc 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -27,7 +27,7 @@
 int hw_sm750_map(struct lynx_share* share, struct pci_dev* pdev)
 {
 	int ret;
-	struct sm750_share * spec_share;
+	struct sm750_share *spec_share;
 	
 
 	spec_share = container_of(share, struct sm750_share, share);
@@ -100,10 +100,10 @@ exit:
 
 
 
-int hw_sm750_inithw(struct lynx_share* share, struct pci_dev * pdev)
+int hw_sm750_inithw(struct lynx_share *share, struct pci_dev *pdev)
 {
-	struct sm750_share * spec_share;
-	struct init_status * parm;
+	struct sm750_share *spec_share;
+	struct init_status *parm;
 	
 	spec_share = container_of(share, struct sm750_share, share);
 	parm = &spec_share->state.initParm;
@@ -199,7 +199,7 @@ int hw_sm750_inithw(struct lynx_share* share, struct pci_dev * pdev)
 }
 
 
-resource_size_t hw_sm750_getVMSize(struct lynx_share * share)
+resource_size_t hw_sm750_getVMSize(struct lynx_share *share)
 {
 	resource_size_t ret;
 	
@@ -265,7 +265,7 @@ void hw_sm750_output_clear(struct lynxfb_output* output)
 
 int hw_sm750_crtc_checkMode(struct lynxfb_crtc* crtc, struct fb_var_screeninfo* var)
 {
-	struct lynx_share * share;
+	struct lynx_share *share;
 	
 
 	share = container_of(crtc, struct lynxfb_par, crtc)->share;
@@ -300,8 +300,8 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc* crtc,
 	u32 reg;
 	mode_parameter_t modparm;
 	clock_type_t clock;
-	struct lynx_share * share;
-	struct lynxfb_par * par;
+	struct lynx_share *share;
+	struct lynxfb_par *par;
 
 	
 	ret = 0;
@@ -549,7 +549,7 @@ int hw_sm750_setBLANK(struct lynxfb_output* output, int blank)
 }
 
 
-void hw_sm750_initAccel(struct lynx_share * share)
+void hw_sm750_initAccel(struct lynx_share *share)
 {
 	u32 reg;
 	enable2DEngine(1);
-- 
1.9.1


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox