Linux Framebuffer Layer development
 help / color / mirror / Atom feed

* [PATCH 04/10] fblog: implement fblog_redraw()
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>

This mostly copies the functionality from drivers/video/console/bitblit.c
so we can draw the console content on all available framebuffers.

All speed optimizations have been removed for simplicity. The original
code depends heavily on CONFIG_VT so we cannot share the codebase here.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
 drivers/video/console/fblog.c |  126 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 8038dcc..e790971 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -197,6 +197,131 @@ static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
 	}
 }
 
+static void fblog_redraw_aligned(struct fblog_fb *fb, const char *s, u32 cnt,
+				 u32 d_pitch, u32 s_pitch, u32 cellsize,
+				 struct fb_image *image, u8 *dst)
+{
+	struct fb_info *info = fb->info;
+	const struct font_desc *font = fb->font;
+	u32 idx = font->width >> 3;
+	u8 *src;
+
+	while (cnt--) {
+		src = (void*)(font->data + (*s++ & 0xff) * cellsize);
+		fb_pad_aligned_buffer(dst, d_pitch, src, idx, image->height);
+		dst += s_pitch;
+	}
+
+	info->fbops->fb_imageblit(info, image);
+}
+
+static void fblog_redraw_unaligned(struct fblog_fb *fb, const char *s, u32 cnt,
+				   u32 d_pitch, u32 s_pitch, u32 cellsize,
+				   struct fb_image *image, u8 *dst)
+{
+	struct fb_info *info = fb->info;
+	const struct font_desc *font = fb->font;
+	u32 shift_low = 0, mod = font->width % 8;
+	u32 shift_high = 8;
+	u32 idx = font->width >> 3;
+	u8 *src;
+
+	while (cnt--) {
+		src = (void*)(font->data + (*s++ & 0xff) * cellsize);
+		fb_pad_unaligned_buffer(dst, d_pitch, src, idx,
+					image->height, shift_high,
+					shift_low, mod);
+		shift_low += mod;
+		dst += (shift_low >= 8) ? s_pitch : s_pitch - 1;
+		shift_low &= 7;
+		shift_high = 8 - shift_low;
+	}
+
+	info->fbops->fb_imageblit(info, image);
+}
+
+static void fblog_redraw_line(struct fblog_fb *fb, size_t line,
+			      const char *str, size_t len)
+{
+	struct fb_info *info = fb->info;
+	const struct font_desc *font = fb->font;
+	struct fb_image image;
+	u32 width = DIV_ROUND_UP(font->width, 8);
+	u32 cellsize = width * font->height;
+	u32 maxcnt = info->pixmap.size / cellsize;
+	u32 scan_align = info->pixmap.scan_align - 1;
+	u32 buf_align = info->pixmap.buf_align - 1;
+	u32 mod = font->width % 8;
+	u32 cnt, pitch, size;
+	u8 *dst;
+
+	image.fg_color = 7;
+	image.bg_color = 0;
+	image.dx = 0;
+	image.dy = line * font->height;
+	image.height = font->height;
+	image.depth = 1;
+
+	while (len) {
+		if (len > maxcnt)
+			cnt = maxcnt;
+		else
+			cnt = len;
+
+		image.width = font->width * cnt;
+		pitch = DIV_ROUND_UP(image.width, 8) + scan_align;
+		pitch &= ~scan_align;
+		size = pitch * image.height + buf_align;
+		size &= ~buf_align;
+		dst = fb_get_buffer_offset(info, &info->pixmap, size);
+		image.data = dst;
+
+		if (!mod)
+			fblog_redraw_aligned(fb, str, cnt, pitch, width,
+					     cellsize, &image, dst);
+		else
+			fblog_redraw_unaligned(fb, str, cnt, pitch, width,
+					       cellsize, &image, dst);
+
+		image.dx += cnt * font->width;
+		len -= cnt;
+		str += cnt;
+	}
+}
+
+static void fblog_redraw_clear(struct fblog_fb *fb)
+{
+	struct fb_fillrect region;
+	struct fb_info *info = fb->info;
+
+	region.color = 0;
+	region.dx = 0;
+	region.dy = 0;
+	region.width = info->var.xres;
+	region.height = info->var.yres;
+	region.rop = ROP_COPY;
+
+	info->fbops->fb_fillrect(info, &region);
+}
+
+static void fblog_redraw(struct fblog_fb *fb)
+{
+	size_t i, len;
+
+	if (!fb || !fb->font || test_bit(FBLOG_KILLED, &fb->flags) ||
+	    test_bit(FBLOG_SUSPENDED, &fb->flags) ||
+	    test_bit(FBLOG_BLANKED, &fb->flags))
+		return;
+
+	fblog_redraw_clear(fb);
+
+	for (i = 0; i < fb->buf.height; ++i) {
+		len = strnlen(fb->buf.lines[i], fb->buf.width);
+		if (len)
+			fblog_redraw_line(fb, i, fb->buf.lines[i], len);
+	}
+}
+
 static struct fblog_fb *fblog_info2fb(struct fb_info *info)
 {
 	if (!info || info->node < 0 || info->node >= FB_MAX ||
@@ -244,6 +369,7 @@ static void fblog_register(struct fb_info *info)
 		width = info->var.xres / fb->font->width;
 		height = info->var.yres / fb->font->height;
 		fblog_buf_resize(&fb->buf, width, height);
+		fblog_redraw(fb);
 	}
 
 	return;
-- 
1.7.10.4


^ permalink raw reply related

* [PATCH 03/10] fblog: register framebuffer objects
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>

We register each available framebuffer in the system with the fblog driver
so we always know all active devices. We directly open the fb-driver,
initialize the buffer and load a font so we are ready for drawing
operations. If a device cannot be opened, we mark it as dead and ignore it
in all other functions.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
 drivers/video/console/fblog.c |  108 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index 1504ba9..8038dcc 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -39,6 +39,14 @@
 #include <linux/font.h>
 #include <linux/module.h>
 
+#define FBLOG_STR(x) x, sizeof(x) - 1
+
+enum fblog_flags {
+	FBLOG_KILLED,
+	FBLOG_SUSPENDED,
+	FBLOG_BLANKED,
+};
+
 /**
  * struct fblog_buf: Console text buffer
  *
@@ -61,6 +69,30 @@ struct fblog_buf {
 	size_t pos_y;
 };
 
+/**
+ * struct fblog_fb: Framebuffer object
+ *
+ * For each framebuffer we register this object. It contains all data we need to
+ * display the console log on it. The index of a framebuffer in registered_fb[]
+ * is the same as in fblog_fbs[]. So the following must always be true if the
+ * pointers are non-NULL:
+ *     registered_fb[idx] = fblog_fbs[idx]->info
+ *     fblog_fbs[idx]->info->node = idx
+ *
+ * flags: Framebuffer flags (see fblog_flags)
+ * info: Pointer to the associated framebuffer device
+ * font: Currently used font
+ * buf: Console text buffer
+ */
+struct fblog_fb {
+	unsigned long flags;
+	struct fb_info *info;
+	const struct font_desc *font;
+	struct fblog_buf buf;
+};
+
+static struct fblog_fb *fblog_fbs[FB_MAX];
+
 static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
 			     size_t height)
 {
@@ -165,6 +197,82 @@ static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
 	}
 }
 
+static struct fblog_fb *fblog_info2fb(struct fb_info *info)
+{
+	if (!info || info->node < 0 || info->node >= FB_MAX ||
+	    !registered_fb[info->node])
+		return NULL;
+
+	return fblog_fbs[info->node];
+}
+
+static void fblog_register(struct fb_info *info)
+{
+	struct fblog_fb *fb;
+	struct fb_var_screeninfo var;
+	const struct fb_videomode *mode;
+	unsigned int width, height;
+
+	if (!info || info->node < 0 || info->node >= FB_MAX)
+		return;
+	if (!registered_fb[info->node] || fblog_fbs[info->node])
+		return;
+
+	fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+	if (!fb)
+		return;
+
+	fblog_fbs[info->node] = fb;
+	fb->info = info;
+	fblog_buf_init(&fb->buf);
+	fblog_buf_write(&fb->buf, FBLOG_STR("Framebuffer log initialized\n"));
+
+	if (!try_module_get(info->fbops->owner))
+		goto out_killed;
+	if (info->fbops->fb_open && info->fbops->fb_open(info, 0))
+		goto out_unref;
+
+	var = info->var;
+	mode = fb_find_best_mode(&var, &info->modelist);
+	var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+	fb_set_var(info, &var);
+
+	fb->font = get_default_font(info->var.xres, info->var.yres,
+				    info->pixmap.blit_x,
+				    info->pixmap.blit_y);
+	if (fb->font) {
+		width = info->var.xres / fb->font->width;
+		height = info->var.yres / fb->font->height;
+		fblog_buf_resize(&fb->buf, width, height);
+	}
+
+	return;
+
+out_unref:
+	module_put(info->fbops->owner);
+out_killed:
+	set_bit(FBLOG_KILLED, &fb->flags);
+}
+
+static void fblog_unregister(struct fblog_fb *fb)
+{
+	struct fb_info *info;
+
+	if (!fb)
+		return;
+
+	info = fb->info;
+	if (!test_bit(FBLOG_KILLED, &fb->flags)) {
+		if (info->fbops->fb_release)
+			info->fbops->fb_release(info, 0);
+		module_put(info->fbops->owner);
+	}
+
+	fblog_buf_deinit(&fb->buf);
+	fblog_fbs[info->node] = NULL;
+	kfree(fb);
+}
+
 static int __init fblog_init(void)
 {
 	return 0;
-- 
1.7.10.4


^ permalink raw reply related

* [PATCH 02/10] fblog: implement buffer management
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>

Each available framebuffer can have a different font and buffer size
inside of fblog. Therefore, we need to remember all the log messages that
are currently printed on screen. We save them as an array of lines which
can be rotated and traversed very fast.

This also implements a very trivial way of resizing the buffer but still
keeping the content. As there is no need to improve this for speed, we can
keep it this way.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
 drivers/video/console/fblog.c |  126 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)

diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index ea83643..1504ba9 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -39,6 +39,132 @@
 #include <linux/font.h>
 #include <linux/module.h>
 
+/**
+ * struct fblog_buf: Console text buffer
+ *
+ * Each framebuffer has its own text buffer which contains all characters that
+ * are currently printed on screen. The buffers might have different sizes and
+ * can be resized during runtime. When the buffer content changes, we redraw the
+ * screen.
+ *
+ * width: Width of buffer in characters
+ * height: Height of buffer in characters
+ * lines: Array of lines
+ * pos_x: Cursor x-position
+ * pos_y: Cursor y-position
+ */
+struct fblog_buf {
+	size_t width;
+	size_t height;
+	char **lines;
+	size_t pos_x;
+	size_t pos_y;
+};
+
+static void fblog_buf_resize(struct fblog_buf *buf, size_t width,
+			     size_t height)
+{
+	char **lines = NULL;
+	size_t i, j, minw, minh;
+
+	if (buf->height = height && buf->width = width)
+		return;
+
+	if (width && height) {
+		lines = kzalloc(height * sizeof(char*), GFP_KERNEL);
+		if (!lines)
+			return;
+
+		for (i = 0; i < height; ++i) {
+			lines[i] = kzalloc(width * sizeof(char), GFP_KERNEL);
+			if (!lines[i]) {
+				while (i--)
+					kfree(lines[i]);
+				return;
+			}
+		}
+
+		/* copy old lines */
+		minw = min(width, buf->width);
+		minh = min(height, buf->height);
+		if (height >= buf->height)
+			i = 0;
+		else
+			i = buf->height - height;
+
+		for (j = 0; j < minh; ++i, ++j)
+			memcpy(lines[j], buf->lines[i], minw * sizeof(char));
+	} else {
+		width = 0;
+		height = 0;
+	}
+
+	for (i = 0; i < buf->height; ++i)
+		kfree(buf->lines[i]);
+	kfree(buf->lines);
+
+	buf->lines = lines;
+	buf->width = width;
+	buf->height = height;
+}
+
+static void fblog_buf_init(struct fblog_buf *buf)
+{
+	fblog_buf_resize(buf, 80, 24);
+}
+
+static void fblog_buf_deinit(struct fblog_buf *buf)
+{
+	fblog_buf_resize(buf, 0, 0);
+}
+
+static void fblog_buf_rotate(struct fblog_buf *buf)
+{
+	char *line;
+
+	if (!buf->height)
+		return;
+
+	line = buf->lines[0];
+	memset(line, 0, sizeof(char) * buf->width);
+
+	memmove(buf->lines, &buf->lines[1], sizeof(char*) * (buf->height - 1));
+	buf->lines[buf->height - 1] = line;
+}
+
+static void fblog_buf_write(struct fblog_buf *buf, const char *str, size_t len)
+{
+	char c;
+
+	if (!buf->height)
+		return;
+
+	while (len--) {
+		c = *str++;
+
+		if (c = '\n') {
+			buf->pos_x = 0;
+			if (++buf->pos_y >= buf->height) {
+				buf->pos_y = buf->height - 1;
+				fblog_buf_rotate(buf);
+			}
+		} else if (c = 0) {
+			/* ignore */
+		} else {
+			if (buf->pos_x >= buf->width) {
+				buf->pos_x = 0;
+				++buf->pos_y;
+			}
+			if (buf->pos_y >= buf->height) {
+				buf->pos_y = buf->height - 1;
+				fblog_buf_rotate(buf);
+			}
+
+			buf->lines[buf->pos_y][buf->pos_x++] = c;
+		}
+	}
+}
+
 static int __init fblog_init(void)
 {
 	return 0;
-- 
1.7.10.4


^ permalink raw reply related

* [PATCH 01/10] fblog: new framebuffer kernel log dummy driver
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann
In-Reply-To: <1339884266-9201-1-git-send-email-dh.herrmann@googlemail.com>

Fblog displays all kernel log messages on all connected framebuffers. It
replaces fbcon when CONFIG_VT=n is selected. Its main purpose is to debug
boot problems by displaying the whole boot log on the screen. This patch
provides the first dummy module-init/deinit functions.

As is uses all the font and fb functions I placed it in
drivers/video/console. However, this means that we need to move the check
for CONFIG_VT in Makefile/Kconfig from drivers/video into
drivers/video/console as fblog does not depend on CONFIG_VT.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
 drivers/video/Kconfig          |    5 +---
 drivers/video/Makefile         |    2 +-
 drivers/video/console/Kconfig  |   37 +++++++++++++++++++++------
 drivers/video/console/Makefile |    1 +
 drivers/video/console/fblog.c  |   55 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 87 insertions(+), 13 deletions(-)
 create mode 100644 drivers/video/console/fblog.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..e8fd53d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2448,10 +2448,7 @@ source "drivers/video/omap/Kconfig"
 source "drivers/video/omap2/Kconfig"
 source "drivers/video/exynos/Kconfig"
 source "drivers/video/backlight/Kconfig"
-
-if VT
-	source "drivers/video/console/Kconfig"
-endif
+source "drivers/video/console/Kconfig"
 
 if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..9f8a7f0 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -11,7 +11,7 @@ fb-y                              := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
                                      modedb.o fbcvt.o
 fb-objs                           := $(fb-y)
 
-obj-$(CONFIG_VT)		  += console/
+obj-y				  += console/
 obj-$(CONFIG_LOGO)		  += logo/
 obj-y				  += backlight/
 
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index c2d11fe..cfee482 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -6,7 +6,7 @@ menu "Console display driver support"
 
 config VGA_CONSOLE
 	bool "VGA text console" if EXPERT || !X86
-	depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
+	depends on VT && !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
 	default y
 	help
 	  Saying Y here will allow you to use Linux in text mode through a
@@ -45,7 +45,7 @@ config VGACON_SOFT_SCROLLBACK_SIZE
 	 screenfuls of scrollback buffer
 
 config MDA_CONSOLE
-	depends on !M68K && !PARISC && ISA
+	depends on VT && !M68K && !PARISC && ISA
 	tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
 	---help---
 	  Say Y here if you have an old MDA or monochrome Hercules graphics
@@ -61,14 +61,14 @@ config MDA_CONSOLE
 
 config SGI_NEWPORT_CONSOLE
         tristate "SGI Newport Console support"
-        depends on SGI_IP22 
+        depends on VT && SGI_IP22
         help
           Say Y here if you want the console on the Newport aka XL graphics
           card of your Indy.  Most people say Y here.
 
 config DUMMY_CONSOLE
 	bool
-	depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y 
+	depends on VT && (VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y)
 	default y
 
 config DUMMY_CONSOLE_COLUMNS
@@ -89,7 +89,7 @@ config DUMMY_CONSOLE_ROWS
 
 config FRAMEBUFFER_CONSOLE
 	tristate "Framebuffer Console support"
-	depends on FB
+	depends on VT && FB
 	select CRC32
 	help
 	  Low-level framebuffer-based console driver.
@@ -122,16 +122,37 @@ config FRAMEBUFFER_CONSOLE_ROTATION
 
 config STI_CONSOLE
         bool "STI text console"
-        depends on PARISC
+        depends on VT && PARISC
         default y
         help
           The STI console is the builtin display/keyboard on HP-PARISC
           machines.  Say Y here to build support for it into your kernel.
           The alternative is to use your primary serial port as a console.
 
+config FBLOG
+	tristate "Framebuffer Kernel Log Driver"
+	depends on !VT && FB
+	default n
+	help
+	  This driver displays all kernel log messages on all connected
+	  framebuffers. It is mutually exclusive with CONFIG_FRAMEBUFFER_CONSOLE
+	  and CONFIG_VT. It was mainly created for debugging purposes when
+	  CONFIG_VT is not selected but you still want kernel boot messages on
+	  the screen.
+
+	  This driver overwrites all other graphics output on the framebuffer as
+	  long as it is active so the kernel log will always be visible. You
+	  need to disable this driver via sysfs to be able to start another
+	  graphics application.
+
+	  If unsure, say N.
+
+	  To compile this driver as a module, choose M here: the module will
+	  be called fblog.
+
 config FONTS
 	bool "Select compiled-in fonts"
-	depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
+	depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE || FBLOG
 	help
 	  Say Y here if you would like to use fonts other than the default
 	  your frame buffer console usually use.
@@ -158,7 +179,7 @@ config FONT_8x8
 
 config FONT_8x16
 	bool "VGA 8x16 font" if FONTS
-	depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
+	depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON || FBLOG
 	default y if !SPARC && !FONTS
 	help
 	  This is the "high resolution" font for the VGA frame buffer (the one
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index a862e91..f608c97 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -20,6 +20,7 @@ font-objs += $(font-objs-y)
 
 # Each configuration option enables a list of files.
 
+obj-$(CONFIG_FBLOG)               += fblog.o font.o
 obj-$(CONFIG_DUMMY_CONSOLE)       += dummycon.o
 obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
 obj-$(CONFIG_STI_CONSOLE)         += sticon.o sticore.o font.o
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
new file mode 100644
index 0000000..ea83643
--- /dev/null
+++ b/drivers/video/console/fblog.c
@@ -0,0 +1,55 @@
+/*
+ * Framebuffer Kernel Log Driver
+ * Copyright (c) 2012 David Herrmann <dh.herrmann@googlemail.com>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+/*
+ * Framebuffer Kernel Log
+ * This driver prints the kernel log to all connected display devices. It
+ * replaces CONFIG_VT and cannot run simultaneously with it. It does not provide
+ * any virtual-terminal, though. It should only be used to get kernel boot
+ * messages to debug kernel errors.
+ * Hence, this driver is neither optimized for speed, nor does it provide any
+ * fancy features like colored text output. After booting is done, the init
+ * process should set /sys/class/graphics/fblog/active to 0 which disables this
+ * driver and you can start using the graphics devices. During shutdown, you can
+ * set this to 1 to get log messages again.
+ * This driver forcibly writes to the framebuffer while active, therefore, you
+ * cannot run other graphics applications simultaneously.
+ *
+ * fblog_redraw_line() is heavily based on the fbcon driver. See bitblit.c for
+ * the original implementation copyrighted by:
+ *     Copyright (C) 2004 Antonino Daplas <adaplas@pol.net>
+ *
+ * Please note that nearly all functions here must be called with console_lock
+ * held. This way, we have no locking problems and do not need special
+ * synchronization.
+ */
+
+#include <linux/atomic.h>
+#include <linux/console.h>
+#include <linux/fb.h>
+#include <linux/font.h>
+#include <linux/module.h>
+
+static int __init fblog_init(void)
+{
+	return 0;
+}
+
+static void __exit fblog_exit(void)
+{
+}
+
+module_init(fblog_init);
+module_exit(fblog_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Herrmann <dh.herrmann@googlemail.com>");
+MODULE_DESCRIPTION("Framebuffer Kernel Log Driver");
-- 
1.7.10.4


^ permalink raw reply related

* [RFC 00/10] fblog: framebuffer kernel log driver
From: David Herrmann @ 2012-06-16 22:04 UTC (permalink / raw)
  To: linux-serial
  Cc: Florian Tobias Schandinat, linux-fbdev, linux-kernel,
	Greg Kroah-Hartman, David Herrmann

Hi

As some might know I am working on making CONFIG_VT obsolete. But as a developer
it is often useful to have a kernel-log on the screen during boot to debug many
common kernel(-config) errors. However, without CONFIG_VT we cannot use the
VGA/framebbufer consoles either. Therefore, I am working on a small driver
called "fblog".

This driver simply writes the kernel log to all connected framebuffers. It works
similar to fbcon but removes all the complexity of the virtual terminals. There
is a sysfs attribute called "active" that allows to enable/disable fblog so
user-space can start an xserver or similar.

The main purpose is debugging kernel boot problems. Therefore, it is not
optimized for speed and I tried keeping it simple. I splitted the patches
into 10 small chunks to make review easier.

I would be glad if someone could review this and tell me whether this is
something we could include in mainline or not.


There are still some issues but apart from them it works fine on my
machine (x86):
  - I register the fblog device during module_init and need to call
    module_get(). However, this means it is impossible to call "rmmod fblog" as
    fblog has a reference to itself. Using "rmmod -f fblog" works fine but is a
    bit ugly. Is there a nice way to fix this? Otherwise I would need to call
    device_get() in module_exit() if there is a pending user of the fblog-device
    even though I unregistered it.
  - I redraw all framebuffers while holding the console-lock. This may slow down
    machines with more than 2 framebuffers (like 10 or 20). However, as this is
    supposed to be a debug driver, I think I can ignore this? If someone wants
    to improve the redraw logic to avoid redrawing the whole screen all the
    time, I would be glad to include it in this patchset :)
  - I am really no expert regarding the framebuffer subsystem. So I would
    appreciate it if someone could comment whether I need to handle the events
    in a different way or whether it is ok the way it is now.

I run this on my machine with CONFIG_VT=n and it works quite nice. If someone
wants to test it, this also works with CONFIG_VT=y and x11 running. Just load
the driver from your xserver and it will redraw the screen with the console.
Switching VTs back and forth will make the xserver redraw the whole screen
again. You need to remove "depends on !VT" of course.

Thanks and regards
David

David Herrmann (10):
  fblog: new framebuffer kernel log dummy driver
  fblog: implement buffer management
  fblog: register framebuffer objects
  fblog: implement fblog_redraw()
  fblog: add framebuffer helpers
  fblog: allow enabling/disabling fblog on runtime
  fblog: forward kernel log messages to all framebuffers
  fblog: react on framebuffer events
  fblog: register all handlers on module-init
  fblog: add "activate" module parameter

 Documentation/ABI/testing/sysfs-fblog |    9 +
 drivers/video/Kconfig                 |    5 +-
 drivers/video/Makefile                |    2 +-
 drivers/video/console/Kconfig         |   37 +-
 drivers/video/console/Makefile        |    1 +
 drivers/video/console/fblog.c         |  694 +++++++++++++++++++++++++++++++++
 6 files changed, 735 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-fblog
 create mode 100644 drivers/video/console/fblog.c

-- 
1.7.10.4


^ permalink raw reply

* [GIT PULL] fbdev fixes for 3.5
From: Florian Tobias Schandinat @ 2012-06-16 20:00 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: LKML, linux-fbdev@vger.kernel.org

Hi Linus,

please pull the fixes below.


Thanks,

Florian Tobias Schandinat


The following changes since commit c895305e806b4346006d3cfba2b432d52268ecd3:

  video: bfin_adv7393fb: Fix cleanup code (2012-05-29 13:16:45 +0000)

are available in the git repository at:

  git://github.com/schandinat/linux-2.6.git fbdev-fixes-for-3.5-1

for you to fetch changes up to b67989515defba7412acff01162e5bb1f0f5923a:

  video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk (2012-06-13 17:34:16 +0000)

----------------------------------------------------------------
fbdev fixes for 3.5

- two fixes for s3c-fb by Jingoo Han
  (including a fix for a potential division by zero)
- a couple of randconfig fixes by Arnd Bergmann
- a cleanup for bfin_adv7393fb by Emil Goode

----------------------------------------------------------------
Archit Taneja (1):
      OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters

Arnd Bergmann (5):
      drivers/video: use correct __devexit_p annotation
      video/ili9320: do not mark exported functions __devexit
      video/console: automatically select a font
      drivers/savagefb: use mdelay instead of udelay
      drivers/tosa: driver needs I2C and SPI to compile

Emil Goode (1):
      video: bfin_adv7393fb: Convert to kstrtouint_from_user

Florian Tobias Schandinat (1):
      Merge tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux into fbdev-for-linus

Jingoo Han (2):
      video: s3c-fb: clear SHADOWCON register when clearing hardware window registers
      video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk

Tomi Valkeinen (4):
      OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
      OMAPDSS: Taal: fix compilation warning
      OMAPDSS: fix bogus WARN_ON in dss_runtime_put()
      OMAPDSS: fix registration of DPI and SDI devices

 arch/arm/mach-omap2/display.c             |    4 ++--
 drivers/video/backlight/Kconfig           |    2 +-
 drivers/video/backlight/ili9320.c         |    2 +-
 drivers/video/bfin_adv7393fb.c            |    6 ++----
 drivers/video/broadsheetfb.c              |    2 +-
 drivers/video/console/Kconfig             |   14 ++++++++++++++
 drivers/video/mbx/mbxfb.c                 |    2 +-
 drivers/video/omap2/displays/panel-taal.c |    2 +-
 drivers/video/omap2/dss/core.c            |    3 +--
 drivers/video/omap2/dss/dsi.c             |    2 +-
 drivers/video/omap2/dss/dss.c             |    2 +-
 drivers/video/s3c-fb.c                    |   12 +++++++++---
 drivers/video/savage/savagefb_driver.c    |   10 +++++-----
 13 files changed, 40 insertions(+), 23 deletions(-)


^ permalink raw reply

* [PULL for v3.6] SH Mobile LCDC fixes and planes support
From: Laurent Pinchart @ 2012-06-16 14:07 UTC (permalink / raw)
  To: linux-fbdev

Hi Florian,

Could you please pull the following LCDC patches ?

The following changes since commit b67989515defba7412acff01162e5bb1f0f5923a:

  video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk 
(2012-06-13 17:34:16 +0000)

are available in the git repository at:
  git://linuxtv.org/pinchartl/fbdev.git planes

Guennadi Liakhovetski (1):
      fbdev: sh_mipi_dsi: fix a section mismatch

Laurent Pinchart (4):
      fbdev: sh_mobile_lcdc: Don't confuse line size with pitch
      fbdev: sh_mobile_lcdc: Constify sh_mobile_lcdc_fix structure
      fbdev: sh_mobile_lcdc: Rename fb operation handlers with a common prefix
      fbdev: sh_mobile_lcdc: Implement overlays support

 .../sysfs-devices-platform-sh_mobile_lcdc_fb       |   44 +
 drivers/video/sh_mipi_dsi.c                        |    7 +-
 drivers/video/sh_mobile_lcdcfb.c                   |  987 +++++++++++++++++--
 drivers/video/sh_mobile_lcdcfb.h                   |    1 +
 include/video/sh_mobile_lcdc.h                     |    7 +
 5 files changed, 944 insertions(+), 102 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-
sh_mobile_lcdc_fb

-- 
Regards,

Laurent Pinchart


^ permalink raw reply

* [PATCH] OMAPDSS: HDMI: Discard phy_tx_enabled member
From: jaswinder.singh @ 2012-06-15 22:13 UTC (permalink / raw)
  To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Jassi Brar

From: Jassi Brar <jaswinder.singh@linaro.org>

Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to set it.

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
---
 drivers/video/omap2/dss/ti_hdmi.h         |    1 -
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   11 ++++-------
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi.h b/drivers/video/omap2/dss/ti_hdmi.h
index e734cb4..d174ca1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -177,7 +177,6 @@ struct hdmi_ip_data {
 
 	/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
 	int hpd_gpio;
-	bool phy_tx_enabled;
 };
 int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4dae1b2..3fa3d98 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -157,6 +157,10 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data)
 /* PHY_PWR_CMD */
 static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
 {
+	/* Return if already the state */
+	if (REG_GET(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, 5, 4) = val)
+		return 0;
+
 	/* Command for power control of HDMI PHY */
 	REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
 
@@ -241,11 +245,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
 
 	hpd = gpio_get_value(ip_data->hpd_gpio);
 
-	if (hpd = ip_data->phy_tx_enabled) {
-		spin_unlock_irqrestore(&phy_tx_lock, flags);
-		return 0;
-	}
-
 	if (hpd)
 		r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
 	else
@@ -257,7 +256,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data *ip_data)
 		goto err;
 	}
 
-	ip_data->phy_tx_enabled = hpd;
 err:
 	spin_unlock_irqrestore(&phy_tx_lock, flags);
 	return r;
@@ -327,7 +325,6 @@ void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data)
 	free_irq(gpio_to_irq(ip_data->hpd_gpio), ip_data);
 
 	hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
-	ip_data->phy_tx_enabled = false;
 }
 
 static int hdmi_core_ddc_init(struct hdmi_ip_data *ip_data)
-- 
1.7.4.1


^ permalink raw reply related

* [PATCH 4/6] pwm_backlight: Add deferred probe support
From: Laurent Pinchart @ 2012-06-15 15:17 UTC (permalink / raw)
  To: linux-fbdev

If the PWM instance is not available yet at probe time, request a
deferred probe.

A better way to fix might be to create a PWM subsystem (possible
integrated into the GPIO subsystem) to support generic PWM objects, and
make sure the subsystem gets initialized first.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-fbdev@vger.kernel.org
---
 drivers/video/backlight/pwm_bl.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 342b7d7..5df8b91 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -121,6 +121,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	if (IS_ERR(pb->pwm)) {
 		dev_err(&pdev->dev, "unable to request PWM for backlight\n");
 		ret = PTR_ERR(pb->pwm);
+		if (ret = -ENODEV)
+			ret = -EPROBE_DEFER;
 		goto err_alloc;
 	} else
 		dev_dbg(&pdev->dev, "got pwm for backlight\n");
-- 
1.7.3.4


^ permalink raw reply related

* Re: [PATCH] fbdev: sh_mipi_dsi: fix a section mismatch
From: Guennadi Liakhovetski @ 2012-06-14 19:00 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1206140951570.30810@axis700.grange>

Hi Laurent

On Thu, 14 Jun 2012, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> Thanks for the patch.
> 
> On Thursday 14 June 2012 09:53:33 Guennadi Liakhovetski wrote:
> > sh_mipi_setup() is called from a .text function, therefore it cannot be
> > __init. Additionally, sh_mipi_remove() can be moved to the .devexit.text
> > section.
> > 
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> 
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Would you like me to take the patch in my tree ?

I don't have my own fbdev tree, so, any tree, that eventually lands in the 
mainline is good :)

Thanks
Guennadi

> > ---
> >  drivers/video/sh_mipi_dsi.c |    7 +++----
> >  1 files changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> > index 4c6b844..3951fda 100644
> > --- a/drivers/video/sh_mipi_dsi.c
> > +++ b/drivers/video/sh_mipi_dsi.c
> > @@ -127,8 +127,7 @@ static void sh_mipi_shutdown(struct platform_device
> > *pdev) sh_mipi_dsi_enable(mipi, false);
> >  }
> > 
> > -static int __init sh_mipi_setup(struct sh_mipi *mipi,
> > -				struct sh_mipi_dsi_info *pdata)
> > +static int sh_mipi_setup(struct sh_mipi *mipi, struct sh_mipi_dsi_info
> > *pdata) {
> >  	void __iomem *base = mipi->base;
> >  	struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
> > @@ -551,7 +550,7 @@ efindslot:
> >  	return ret;
> >  }
> > 
> > -static int __exit sh_mipi_remove(struct platform_device *pdev)
> > +static int __devexit sh_mipi_remove(struct platform_device *pdev)
> >  {
> >  	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	struct resource *res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > @@ -592,7 +591,7 @@ static int __exit sh_mipi_remove(struct platform_device
> > *pdev) }
> > 
> >  static struct platform_driver sh_mipi_driver = {
> > -	.remove		= __exit_p(sh_mipi_remove),
> > +	.remove		= __devexit_p(sh_mipi_remove),
> >  	.shutdown	= sh_mipi_shutdown,
> >  	.driver = {
> >  		.name	= "sh-mipi-dsi",
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

^ permalink raw reply

* Re: [PATCH] fbdev: sh_mipi_dsi: fix a section mismatch
From: Laurent Pinchart @ 2012-06-14 18:44 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <Pine.LNX.4.64.1206140951570.30810@axis700.grange>

Hi Guennadi,

Thanks for the patch.

On Thursday 14 June 2012 09:53:33 Guennadi Liakhovetski wrote:
> sh_mipi_setup() is called from a .text function, therefore it cannot be
> __init. Additionally, sh_mipi_remove() can be moved to the .devexit.text
> section.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Would you like me to take the patch in my tree ?

> ---
>  drivers/video/sh_mipi_dsi.c |    7 +++----
>  1 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
> index 4c6b844..3951fda 100644
> --- a/drivers/video/sh_mipi_dsi.c
> +++ b/drivers/video/sh_mipi_dsi.c
> @@ -127,8 +127,7 @@ static void sh_mipi_shutdown(struct platform_device
> *pdev) sh_mipi_dsi_enable(mipi, false);
>  }
> 
> -static int __init sh_mipi_setup(struct sh_mipi *mipi,
> -				struct sh_mipi_dsi_info *pdata)
> +static int sh_mipi_setup(struct sh_mipi *mipi, struct sh_mipi_dsi_info
> *pdata) {
>  	void __iomem *base = mipi->base;
>  	struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
> @@ -551,7 +550,7 @@ efindslot:
>  	return ret;
>  }
> 
> -static int __exit sh_mipi_remove(struct platform_device *pdev)
> +static int __devexit sh_mipi_remove(struct platform_device *pdev)
>  {
>  	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	struct resource *res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> @@ -592,7 +591,7 @@ static int __exit sh_mipi_remove(struct platform_device
> *pdev) }
> 
>  static struct platform_driver sh_mipi_driver = {
> -	.remove		= __exit_p(sh_mipi_remove),
> +	.remove		= __devexit_p(sh_mipi_remove),
>  	.shutdown	= sh_mipi_shutdown,
>  	.driver = {
>  		.name	= "sh-mipi-dsi",

-- 
Regards,

Laurent Pinchart


^ permalink raw reply

* [PATCH] fbdev: sh_mipi_dsi: fix a section mismatch
From: Guennadi Liakhovetski @ 2012-06-14  7:53 UTC (permalink / raw)
  To: linux-fbdev

sh_mipi_setup() is called from a .text function, therefore it cannot be
__init. Additionally, sh_mipi_remove() can be moved to the .devexit.text
section.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/video/sh_mipi_dsi.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 4c6b844..3951fda 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -127,8 +127,7 @@ static void sh_mipi_shutdown(struct platform_device *pdev)
 	sh_mipi_dsi_enable(mipi, false);
 }
 
-static int __init sh_mipi_setup(struct sh_mipi *mipi,
-				struct sh_mipi_dsi_info *pdata)
+static int sh_mipi_setup(struct sh_mipi *mipi, struct sh_mipi_dsi_info *pdata)
 {
 	void __iomem *base = mipi->base;
 	struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
@@ -551,7 +550,7 @@ efindslot:
 	return ret;
 }
 
-static int __exit sh_mipi_remove(struct platform_device *pdev)
+static int __devexit sh_mipi_remove(struct platform_device *pdev)
 {
 	struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	struct resource *res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -592,7 +591,7 @@ static int __exit sh_mipi_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver sh_mipi_driver = {
-	.remove		= __exit_p(sh_mipi_remove),
+	.remove		= __devexit_p(sh_mipi_remove),
 	.shutdown	= sh_mipi_shutdown,
 	.driver = {
 		.name	= "sh-mipi-dsi",
-- 
1.7.2.5


^ permalink raw reply related

* [PATCH] video: backlight: remove unused header
From: Paul Bolle @ 2012-06-13  7:47 UTC (permalink / raw)
  To: Florian Tobias Schandinat; +Cc: linux-fbdev, linux-kernel

Commit 9befe40f6e018e508b047eb76d189ede9b4ff03d ("video: backlight:
support s6e8ax0 panel driver based on MIPI DSI") added s6e8ax0.h, but
no file includes it. That's probably a good thing, because it declares
an extern void function that is defined static int in s6e8ax0.c.
Besides, that function is also wrapped in the module_init() macro, which
should do everything needed to make that function available to the code
outside of s6e8ax0.c. This header can safely be removed.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Tested mainly by using various git tools on the (history of the)
tree.

1) Shouldn't s6e8ax0_init() and s6e8ax0_exit(), both in s6e8ax0.c, carry
the usual __init and __exit attributes?

2) But note that all the module related code in s6e8ax0.c seems moot
currently: EXYNOS_LCD_S6E8AX0 is a boolean Kconfig symbol, so the code
can only be used builtin. So, as far as I can tell, either that symbol
(and the symbols on which it depends) should be made tristate, or the
module related code can be removed from s6e8ax0.c.

 drivers/video/exynos/s6e8ax0.h |   21 ---------------------
 1 files changed, 0 insertions(+), 21 deletions(-)
 delete mode 100644 drivers/video/exynos/s6e8ax0.h

diff --git a/drivers/video/exynos/s6e8ax0.h b/drivers/video/exynos/s6e8ax0.h
deleted file mode 100644
index 1f1b270..0000000
--- a/drivers/video/exynos/s6e8ax0.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/* linux/drivers/video/backlight/s6e8ax0.h
- *
- * MIPI-DSI based s6e8ax0 AMOLED LCD Panel definitions.
- *
- * Copyright (c) 2011 Samsung Electronics
- *
- * Inki Dae, <inki.dae@samsung.com>
- * Donghwa Lee <dh09.lee@samsung.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#ifndef _S6E8AX0_H
-#define _S6E8AX0_H
-
-extern void s6e8ax0_init(void);
-
-#endif
-
-- 
1.7.7.6


^ permalink raw reply related

* RE: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements
From: Nellutla, Aditya @ 2012-06-12  9:34 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1337753191-14802-1-git-send-email-aditya.n@ti.com>

Florian, 

   I didn't receive any review comments for the patch below. So could you please merge the patch?

Regards,
Aditya

-----Original Message-----
From: Nellutla, Aditya 
Sent: Monday, June 04, 2012 11:33 AM
To: Nellutla, Aditya; linux-fbdev@vger.kernel.org
Cc: Hiremath, Vaibhav
Subject: RE: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements

All, 
   Did you get chance to review this patch? Request to give your feedback as early as possible.

Regards,
Aditya 

-----Original Message-----
From: Nellutla, Aditya 
Sent: Wednesday, May 23, 2012 11:37 AM
To: linux-fbdev@vger.kernel.org
Cc: Nellutla, Aditya
Subject: [PATCH] da8xx-fb: Rounding FB size to satisfy SGX buffer requirements

In the real time use-case when SGX is used for rendering to FB buffers it has been
observed that, the available memory from framebuffer driver is not sufficient for
SGX under certain cases (like 16-bit WVGA resolution). SGX requires 2 swap buffers
with each of the buffers aligned to lcm(line_length, PAGE_SIZE).

Inorder to satisfy this requirement, we have two options,

	- Increase number of FB buffers (LCD_NUM_BUFFERS) to 3. This is not
	  recommended as we end up wasting huge memory in most of the cases.

	- Align FB buffers to lcm(line_length, PAGE_SIZE).This ensures framebuffer
	  size is increased to satisfy SGX requirements keeping alignment intact.

This patch makes sure that FB allocates buffers aligned to above formula.

Signed-off-by: Aditya Nellutla <aditya.n@ti.com>
---
 drivers/video/da8xx-fb.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 47118c7..2f24c19 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -31,6 +31,7 @@
 #include <linux/cpufreq.h>
 #include <linux/console.h>
 #include <linux/slab.h>
+#include <linux/lcm.h>
 #include <video/da8xx-fb.h>
 #include <asm/div64.h>
 
@@ -1114,6 +1115,7 @@ static int __devinit fb_probe(struct platform_device *device)
 	struct da8xx_fb_par *par;
 	resource_size_t len;
 	int ret, i;
+	unsigned long ulcm;
 
 	if (fb_pdata = NULL) {
 		dev_err(&device->dev, "Can not get platform data\n");
@@ -1209,7 +1211,8 @@ static int __devinit fb_probe(struct platform_device *device)
 
 	/* allocate frame buffer */
 	par->vram_size = lcdc_info->width * lcdc_info->height * lcd_cfg->bpp;
-	par->vram_size = PAGE_ALIGN(par->vram_size/8);
+	ulcm = lcm((lcdc_info->width * lcd_cfg->bpp)/8, PAGE_SIZE);
+	par->vram_size = roundup(par->vram_size/8, ulcm);
 	par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
 
 	par->vram_virt = dma_alloc_coherent(NULL,
-- 
1.7.0.4


^ permalink raw reply related

* Re: [PATCH] fbdev: make scripts/pnmtologo dependency portable
From: Geert Uytterhoeven @ 2012-06-12  7:32 UTC (permalink / raw)
  To: Yaakov (Cygwin/X); +Cc: linux-fbdev, linux-kbuild
In-Reply-To: <1339455720-2384-1-git-send-email-yselkowitz@users.sourceforge.net>

Cc linux-kbuild added

On Tue, Jun 12, 2012 at 1:02 AM, Yaakov (Cygwin/X)
<yselkowitz@users.sourceforge.net> wrote:
> From: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
>
> Commit a53c9d5b7115173fba9f82ff8120b624ef206f48 added a dependency on
> scripts/pnmtologo to all autogenerated .c files.  An explicit rule
> is required on platforms where the .exe suffix is used for hostprogs.
>
> Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
> ---
> Also applies to all 3.x stable branches
>
>  drivers/video/logo/Makefile |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/logo/Makefile b/drivers/video/logo/Makefile
> index 3b43781..3854dbb 100644
> --- a/drivers/video/logo/Makefile
> +++ b/drivers/video/logo/Makefile
> @@ -38,6 +38,7 @@ extra-y += $(call logo-cfiles,_clut224,ppm)
>  extra-y += $(call logo-cfiles,_gray256,pgm)
>
>  pnmtologo := scripts/pnmtologo
> +$(pnmtologo): $(objtree)/scripts/pnmtologo
>
>  # Create commands like "pnmtologo -t mono -n logo_mac_mono -o ..."
>  quiet_cmd_logo = LOGO    $@
> --
> 1.7.9
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH] fbdev: make scripts/pnmtologo dependency portable
From: Yaakov (Cygwin/X) @ 2012-06-11 23:02 UTC (permalink / raw)
  To: linux-fbdev

From: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>

Commit a53c9d5b7115173fba9f82ff8120b624ef206f48 added a dependency on
scripts/pnmtologo to all autogenerated .c files.  An explicit rule
is required on platforms where the .exe suffix is used for hostprogs.

Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
---
Also applies to all 3.x stable branches

 drivers/video/logo/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/logo/Makefile b/drivers/video/logo/Makefile
index 3b43781..3854dbb 100644
--- a/drivers/video/logo/Makefile
+++ b/drivers/video/logo/Makefile
@@ -38,6 +38,7 @@ extra-y += $(call logo-cfiles,_clut224,ppm)
 extra-y += $(call logo-cfiles,_gray256,pgm)
 
 pnmtologo := scripts/pnmtologo
+$(pnmtologo): $(objtree)/scripts/pnmtologo
 
 # Create commands like "pnmtologo -t mono -n logo_mac_mono -o ..."
 quiet_cmd_logo = LOGO    $@
-- 
1.7.9


^ permalink raw reply related

* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 11:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20120611110517.GE11168@n2100.arm.linux.org.uk>

2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
>> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
>> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> >> This patch checks if framebuffer is unblanked before
>> >> we actually trigger panning in custom pan display
>> >> function.
>> >>
>> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> >> ---
>> >>  drivers/video/mx3fb.c |    5 +++++
>> >>  1 files changed, 5 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> >> index e3406ab..d53db60 100644
>> >> --- a/drivers/video/mx3fb.c
>> >> +++ b/drivers/video/mx3fb.c
>> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> >> fb_var_screeninfo *var,
>> >>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>> >>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>> >>
>> >> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> >> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> >> +		return -EFAULT;
>> >> +	}
>> >
>> > Why is this an error, and why return -EFAULT?  What userspace access
>> > failed?
>> >
>> Hi, Russell,
>>
>> IMHO, panning with framebuffer blanked is meaningless, at least, it is
>> not a common usecase.
>
> Yes, but why should anything in userspace care whether the display is
> blanked or not?
>
> For example, we may pan the display when a user program produces output,
> and we're on the last line of the display.  We don't fail that just
> because the screen happens to be blank.  So I don't see why we should
> actively fail an explicit userspace pan request just because the console
> happened to be blanked.
>
> What I'm basically saying is that as far as _userspace_ is concerned,
> all the standard APIs should just work as normal whether the display is
> blanked or not.
>

Ok, understand your point. I am ok to drop this patch.

Thanks.

-- 
Best Regards,
Liu Ying

^ permalink raw reply

* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Russell King - ARM Linux @ 2012-06-11 11:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CA+8Hj81L9-NC=08_dvV2u_eM0NdssJsjduAgTbH37nusu56Avw@mail.gmail.com>

On Mon, Jun 11, 2012 at 06:46:14PM +0800, Liu Ying wrote:
> 2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> > On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
> >> This patch checks if framebuffer is unblanked before
> >> we actually trigger panning in custom pan display
> >> function.
> >>
> >> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> >> ---
> >>  drivers/video/mx3fb.c |    5 +++++
> >>  1 files changed, 5 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> >> index e3406ab..d53db60 100644
> >> --- a/drivers/video/mx3fb.c
> >> +++ b/drivers/video/mx3fb.c
> >> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
> >> fb_var_screeninfo *var,
> >>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
> >>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
> >>
> >> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
> >> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
> >> +		return -EFAULT;
> >> +	}
> >
> > Why is this an error, and why return -EFAULT?  What userspace access
> > failed?
> >
> Hi, Russell,
> 
> IMHO, panning with framebuffer blanked is meaningless, at least, it is
> not a common usecase.

Yes, but why should anything in userspace care whether the display is
blanked or not?

For example, we may pan the display when a user program produces output,
and we're on the last line of the display.  We don't fail that just
because the screen happens to be blank.  So I don't see why we should
actively fail an explicit userspace pan request just because the console
happened to be blanked.

What I'm basically saying is that as far as _userspace_ is concerned,
all the standard APIs should just work as normal whether the display is
blanked or not.

^ permalink raw reply

* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Liu Ying @ 2012-06-11 10:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20120611095102.GD11168@n2100.arm.linux.org.uk>

2012/6/11, Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
>> This patch checks if framebuffer is unblanked before
>> we actually trigger panning in custom pan display
>> function.
>>
>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> ---
>>  drivers/video/mx3fb.c |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> index e3406ab..d53db60 100644
>> --- a/drivers/video/mx3fb.c
>> +++ b/drivers/video/mx3fb.c
>> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct
>> fb_var_screeninfo *var,
>>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>>
>> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
>> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
>> +		return -EFAULT;
>> +	}
>
> Why is this an error, and why return -EFAULT?  What userspace access
> failed?
>
Hi, Russell,

IMHO, panning with framebuffer blanked is meaningless, at least, it is
not a common usecase. Most users use pan display to swap front buffer
and back buffer when framebuffer is unblanked/active. So, I choose to
take the in question case as an error. Pan display may let user select
a buffer address to be active on display  and I saw the head file
'errno-base.h' comments EFAULT macro to be 'Bad address', so I use
this return value. Perhaps, this return value is not good enough.
Maybe, EIO is better? Would you please help to give some advice on
this?

Thanks.

-- 
Best Regards,
Liu Ying

^ permalink raw reply

* Re: [PATCH 1/3] mx3fb: do not support panning with fb blanked
From: Russell King - ARM Linux @ 2012-06-11  9:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>

On Mon, Jun 11, 2012 at 09:06:48AM +0800, Liu Ying wrote:
> This patch checks if framebuffer is unblanked before
> we actually trigger panning in custom pan display
> function.
> 
> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
> ---
>  drivers/video/mx3fb.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index e3406ab..d53db60 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -1063,6 +1063,11 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
>  	dev_dbg(fbi->device, "%s [%c]\n", __func__,
>  		list_empty(&mx3_fbi->idmac_channel->queue) ? '-' : '+');
>  
> +	if (mx3_fbi->blank != FB_BLANK_UNBLANK) {
> +		dev_dbg(fbi->device, "panning with fb blanked not supported\n");
> +		return -EFAULT;
> +	}

Why is this an error, and why return -EFAULT?  What userspace access
failed?

^ permalink raw reply

* [PATCH 2/2] video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk
From: Jingoo Han @ 2012-06-11  2:27 UTC (permalink / raw)
  To: linux-fbdev

Divider value can be zero and it makes division by zero
from debug message in s3c_fb_calc_pixclk; therefore, it
should be fixed.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/video/s3c-fb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index b5c2939..ea7b661 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -361,7 +361,7 @@ static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
 	result = (unsigned int)tmp / 1000;
 
 	dev_dbg(sfb->dev, "pixclk=%u, clk=%lu, div=%d (%lu)\n",
-		pixclk, clk, result, clk / result);
+		pixclk, clk, result, result ? clk / result : clk);
 
 	return result;
 }
-- 
1.7.1



^ permalink raw reply related

* [PATCH 1/2] video: s3c-fb: clear SHADOWCON register when clearing hardware window registers
From: Jingoo Han @ 2012-06-11  2:26 UTC (permalink / raw)
  To: linux-fbdev

All bits of SHADOWCON register should be cleared when clearing
hardware window registers; however, some bits of SHADOWCON register
are not cleared previously.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
 drivers/video/s3c-fb.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 5f9d8e6..b5c2939 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1348,8 +1348,14 @@ static void s3c_fb_clear_win(struct s3c_fb *sfb, int win)
 	writel(0, regs + VIDOSD_A(win, sfb->variant));
 	writel(0, regs + VIDOSD_B(win, sfb->variant));
 	writel(0, regs + VIDOSD_C(win, sfb->variant));
-	reg = readl(regs + SHADOWCON);
-	writel(reg & ~SHADOWCON_WINx_PROTECT(win), regs + SHADOWCON);
+
+	if (sfb->variant.has_shadowcon) {
+		reg = readl(sfb->regs + SHADOWCON);
+		reg &= ~(SHADOWCON_WINx_PROTECT(win) |
+			SHADOWCON_CHx_ENABLE(win) |
+			SHADOWCON_CHx_LOCAL_ENABLE(win));
+		writel(reg, sfb->regs + SHADOWCON);
+	}
 }
 
 static int __devinit s3c_fb_probe(struct platform_device *pdev)
-- 
1.7.1



^ permalink raw reply related

* Re: [PATCH 1/1] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-11  2:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1206061711090.12739@axis700.grange>

2012/6/6, Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Wed, 30 May 2012, Liu Ying wrote:
>
>> Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
>> This ioctrl relies on fb_set_var() to do the job. fb_set_var()
>> calls custom fb_set_par() method and then calls custom
>> fb_pan_display() method. The current implementation of mx3fb
>> reinitializes IPU display controller every time the custom
>> fb_set_par() method is called, which makes the display flash
>> if fb_set_var() is called to do panning frequently. The custom
>> fb_pan_display() method checks if the current xoffset and
>> yoffset are different from previous ones before doing actual
>> panning, which prevents the panning from happening within the
>> fb_set_var() context. This patch checks new var info to decide
>> whether we really need to reinitialize IPU display controller.
>> We ignore xoffset and yoffset update because it doesn't require
>> to reinitialize the controller. Users may specify activate field
>> of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
>> reinialize the controller by force. Meanwhile, this patch removes
>> the check in custom fb_pan_display() method mentioned before to
>> have the panning work within fb_set_var() context. It doesn't
>> hurt to do panning again if there is no update for xoffset and
>> yoffset.
>
> You are really addressing 2 separate problems here: (1) panning cannot be
> set using FBIOPUT_VSCREENINFO and (2) screen flashes every time
> fb_set_var() is called, even if only panning is required. The reason for
> the first one is, that in fb_set_var() info->var is already updated from
> the new *var when fb_pan_display() is called. So, as you correctly
> identified, the condition
>
> 	if (fbi->var.xoffset = var->xoffset &&
> 	    fbi->var.yoffset = var->yoffset)
> 		return 0;	/* No change, do nothing */
>
> is trivially met and no panning takes place. Instead, you can use your
> idea to cache var_info locally and check against that one to see, whether
> offsets have changed, instead of removing that check completely.
>
> To solve the second problem you can use your check against the cached copy
> of var_info. See below for more details.
>
Thanks for your review. I think your suggestion is good and I have
sent you an updated series of patches for your review. Please find
more detail feedback inline.
>>
>> Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>> ---
>>  drivers/video/mx3fb.c |   31 +++++++++++++++++++++++++++----
>>  1 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> index e3406ab..238b9aa 100644
>> --- a/drivers/video/mx3fb.c
>> +++ b/drivers/video/mx3fb.c
>> @@ -269,6 +269,8 @@ struct mx3fb_info {
>>  	struct scatterlist		sg[2];
>>
>>  	u32				sync;	/* preserve var->sync flags */
>
> An incremental patch could then also remove the above .sync member and
> switch to using .cur_var.sync instead.
Ok. I have addressed this in an updated patch.
>
>> +
>> +	struct fb_var_screeninfo	cur_var; /* current var info */
>>  };
>>
>>  static void mx3fb_dma_done(void *);
>> @@ -721,6 +723,26 @@ static void mx3fb_dma_done(void *arg)
>>  	complete(&mx3_fbi->flip_cmpl);
>>  }
>>
>> +static bool mx3fb_need_not_to_set_par(struct fb_info *fbi)
>
> How about inverting logic and calling the function
> mx3fb_must_update_par()?
Ok. I use mx3fb_must_set_par() in an updated patch.
>
>> +{
>> +	struct mx3fb_info *mx3_fbi = fbi->par;
>> +	struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
>> +	struct fb_var_screeninfo new_var = fbi->var;
>> +
>> +	if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
>> +	    (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
>> +		return false;
>> +
>> +	/*
>> +	 * Ignore xoffset and yoffset update,
>> +	 * because pan display handles this case.
>> +	 */
>> +	old_var.xoffset = new_var.xoffset;
>> +	old_var.yoffset = new_var.yoffset;
>> +
>> +	return !memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
>> +}
>> +
>>  static int __set_par(struct fb_info *fbi, bool lock)
>>  {
>>  	u32 mem_len;
>> @@ -732,6 +754,9 @@ static int __set_par(struct fb_info *fbi, bool lock)
>>  	struct idmac_video_param *video = &ichan->params.video;
>>  	struct scatterlist *sg = mx3_fbi->sg;
>>
>> +	if (mx3fb_need_not_to_set_par(fbi))
>> +		return 0;
>> +
>
> __set_par() is called from 2 locations: from mx3fb_set_par() and
> init_fb_chan(), called from probing. You don't need to perform the above
> check in init_fb_chan() - there you always have to configure. Maybe better
> put it in mx3fb_set_par() just before calling __set_par() like
>
> 	ret = mx3fb_must_set_par() ? __set_par() : 0;
>
> As mentioned above, this solves problem #2 and should go into patch #2.
Ok. I have implemented your suggestion in an updated patch and
splitted this single patch into 2 separate ones. One is to support pan
display with fb_set_var(), the other is to fix screen flash issue when
panning with fb_set_var() frequently.
>
>>  	/* Total cleanup */
>>  	if (mx3_fbi->txd)
>>  		sdc_disable_channel(mx3_fbi);
>> @@ -808,6 +833,8 @@ static int __set_par(struct fb_info *fbi, bool lock)
>>  	if (mx3_fbi->blank = FB_BLANK_UNBLANK)
>>  		sdc_enable_channel(mx3_fbi);
>>
>> +	mx3_fbi->cur_var = fbi->var;
>> +
>
> Yes, but preserve xoffset and yoffset - you don't apply them yet in
> __set_par().
Yes. I have perserved xoffset and yoffset in case fb is blanked when
calling __set_par() in an updated patch. I found that in case fb is
unblanked when calling __set_par(), fb smem_start address is set to
the controller, so I set mx3_fbi->cur_var.xoffset and
mx3_fbi->cur_var.yoffset to zero in __set_par() in this case. Please
fix me if I misunderstood anything.
>
>>  	return 0;
>>  }
>>
>> @@ -1068,10 +1095,6 @@ static int mx3fb_pan_display(struct
>> fb_var_screeninfo *var,
>>  		return -EINVAL;
>>  	}
>>
>> -	if (fbi->var.xoffset = var->xoffset &&
>> -	    fbi->var.yoffset = var->yoffset)
>> -		return 0;	/* No change, do nothing */
>> -
>
> I think, it would be better not to remove these completely, but check
> against cached .cur_var, and then update those values too.
Ok. I have addressed this in an updated patch.
>
>>  	y_bottom = var->yoffset;
>>
>>  	if (!(var->vmode & FB_VMODE_YWRAP))
>> --
>> 1.7.1
>
> Makes sense? Or have I misunderstood something?
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Best Regards,
Liu Ying

^ permalink raw reply

* [PATCH 3/3] mx3fb: avoid screen flash when panning with fb_set_var
From: Liu Ying @ 2012-06-11  1:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>

Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
This ioctrl relies on fb_set_var() to do the job. fb_set_var()
calls custom fb_set_par() method and then calls custom
fb_pan_display() method. The current implementation of mx3fb
reinitializes IPU display controller every time the custom
fb_set_par() method is called, which makes the screen flash
if fb_set_var() is called to do panning frequently. This patch
compares the new var info with the cached old one to decide
whether we really need to reinitialize IPU display controller.
We ignore xoffset and yoffset update because it doesn't require
to reinitialize the controller. Users may specify activate field
of var info with FB_ACTIVATE_NOW and FB_ACTIVATE_FORCE to
reinialize the controller by force.

Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
 drivers/video/mx3fb.c |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 2dd11c4..7d0aa7b 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -721,6 +721,26 @@ static void mx3fb_dma_done(void *arg)
 	complete(&mx3_fbi->flip_cmpl);
 }
 
+static bool mx3fb_must_set_par(struct fb_info *fbi)
+{
+	struct mx3fb_info *mx3_fbi = fbi->par;
+	struct fb_var_screeninfo old_var = mx3_fbi->cur_var;
+	struct fb_var_screeninfo new_var = fbi->var;
+
+	if ((fbi->var.activate & FB_ACTIVATE_FORCE) &&
+	    (fbi->var.activate & FB_ACTIVATE_MASK) = FB_ACTIVATE_NOW)
+		return true;
+
+	/*
+	 * Ignore xoffset and yoffset update,
+	 * because pan display handles this case.
+	 */
+	old_var.xoffset = new_var.xoffset;
+	old_var.yoffset = new_var.yoffset;
+
+	return !!memcmp(&old_var, &new_var, sizeof(struct fb_var_screeninfo));
+}
+
 static int __set_par(struct fb_info *fbi, bool lock)
 {
 	u32 mem_len, cur_xoffset, cur_yoffset;
@@ -844,7 +864,7 @@ static int mx3fb_set_par(struct fb_info *fbi)
 
 	mutex_lock(&mx3_fbi->mutex);
 
-	ret = __set_par(fbi, true);
+	ret = mx3fb_must_set_par(fbi) ? __set_par(fbi, true) : 0;
 
 	mutex_unlock(&mx3_fbi->mutex);
 
-- 
1.7.1



^ permalink raw reply related

* [PATCH 2/3] mx3fb: support pan display with fb_set_var
From: Liu Ying @ 2012-06-11  1:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1339376810-8247-1-git-send-email-Ying.Liu@freescale.com>

Users may call FBIOPUT_VSCREENINFO ioctrl to do pan display.
This ioctrl relies on fb_set_var() to do the job. fb_set_var()
calls the custom fb_set_par() method and then calls the custom
fb_pan_display() method. Before calling the custom fb_pan_display()
method, info->var is already updated from the new *var in fb_set_var().
And, the custom fb_pan_display() method checks if xoffset and yoffset
in info->var and the new *var are different before doing actual panning,
which prevents the panning from happening within fb_set_var() context.
This patch caches the current var info locally in mx3fb driver so that
pan display with fb_set_var is supported.

Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
 drivers/video/mx3fb.c |   33 ++++++++++++++++++++++++++-------
 1 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d53db60..2dd11c4 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -268,7 +268,7 @@ struct mx3fb_info {
 	dma_cookie_t			cookie;
 	struct scatterlist		sg[2];
 
-	u32				sync;	/* preserve var->sync flags */
+	struct fb_var_screeninfo	cur_var; /* current var info */
 };
 
 static void mx3fb_dma_done(void *);
@@ -723,7 +723,7 @@ static void mx3fb_dma_done(void *arg)
 
 static int __set_par(struct fb_info *fbi, bool lock)
 {
-	u32 mem_len;
+	u32 mem_len, cur_xoffset, cur_yoffset;
 	struct ipu_di_signal_cfg sig_cfg;
 	enum ipu_panel mode = IPU_PANEL_TFT;
 	struct mx3fb_info *mx3_fbi = fbi->par;
@@ -805,8 +805,25 @@ static int __set_par(struct fb_info *fbi, bool lock)
 	video->out_height	= fbi->var.yres;
 	video->out_stride	= fbi->var.xres_virtual;
 
-	if (mx3_fbi->blank = FB_BLANK_UNBLANK)
+	if (mx3_fbi->blank = FB_BLANK_UNBLANK) {
 		sdc_enable_channel(mx3_fbi);
+		/*
+		 * sg[0] points to fb smem_start address
+		 * and is actually active in controller.
+		 */
+		mx3_fbi->cur_var.xoffset = 0;
+		mx3_fbi->cur_var.yoffset = 0;
+	}
+
+	/*
+	 * Preserve xoffset and yoffest in case they are
+	 * inactive in controller as fb is blanked.
+	 */
+	cur_xoffset = mx3_fbi->cur_var.xoffset;
+	cur_yoffset = mx3_fbi->cur_var.yoffset;
+	mx3_fbi->cur_var = fbi->var;
+	mx3_fbi->cur_var.xoffset = cur_xoffset;
+	mx3_fbi->cur_var.yoffset = cur_yoffset;
 
 	return 0;
 }
@@ -926,8 +943,8 @@ static int mx3fb_check_var(struct fb_var_screeninfo *var, struct fb_info *fbi)
 	var->grayscale = 0;
 
 	/* Preserve sync flags */
-	var->sync |= mx3_fbi->sync;
-	mx3_fbi->sync |= var->sync;
+	var->sync |= mx3_fbi->cur_var.sync;
+	mx3_fbi->cur_var.sync |= var->sync;
 
 	return 0;
 }
@@ -1073,8 +1090,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
 		return -EINVAL;
 	}
 
-	if (fbi->var.xoffset = var->xoffset &&
-	    fbi->var.yoffset = var->yoffset)
+	if (mx3_fbi->cur_var.xoffset = var->xoffset &&
+	    mx3_fbi->cur_var.yoffset = var->yoffset)
 		return 0;	/* No change, do nothing */
 
 	y_bottom = var->yoffset;
@@ -1157,6 +1174,8 @@ static int mx3fb_pan_display(struct fb_var_screeninfo *var,
 	else
 		fbi->var.vmode &= ~FB_VMODE_YWRAP;
 
+	mx3_fbi->cur_var = fbi->var;
+
 	mutex_unlock(&mx3_fbi->mutex);
 
 	dev_dbg(fbi->device, "Update complete\n");
-- 
1.7.1



^ permalink raw reply related

page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]

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