[PATCH 0/9] Miscellaneous OMAP DSS patches

[PATCH 0/9] Miscellaneous OMAP DSS patches

[Tomi Valkeinen]

Some miscellaneous DSS patches. Quite minor fixes/cleanups, except "Remove
implicit display update on unblank" which does have some functional impact. 

Jani Nikula (2):
  OMAP: DSS2: Add method for querying display dimensions from DSS
    drivers
  OMAP: DSS2: OMAPFB: Remove implicit display update on unblank

Tomi Valkeinen (7):
  OMAP: DSS2: move dss device clock configuration
  OMAP: DSS2: remove non-working msleep(40) workaround
  OMAP: DSS2: make 50ms bug-fix sleep optional
  OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional
  OMAP: DSS2: VENC: Remove sleeps at venc enable/disable
  OMAP: DSS2: OMAPFB: Handle errors when initializing panel
  OMAP: DSS2: VENC: Add missing start/stop_device calls

 arch/arm/mach-omap2/board-4430sdp.c       |   14 +++--
 arch/arm/plat-omap/include/plat/display.h |   30 +++++---
 drivers/video/omap2/dss/Kconfig           |   23 ++++++
 drivers/video/omap2/dss/dsi.c             |   14 ++--
 drivers/video/omap2/dss/dss.c             |    5 ++
 drivers/video/omap2/dss/overlay.c         |   19 +++--
 drivers/video/omap2/dss/venc.c            |   21 ++++--
 drivers/video/omap2/omapfb/omapfb-ioctl.c |   12 +++-
 drivers/video/omap2/omapfb/omapfb-main.c  |  105 +++++++++++++++++++----------
 9 files changed, 168 insertions(+), 75 deletions(-)

[PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Tomi Valkeinen]

Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.

Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
 arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
 drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
 3 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
 		.data1_pol	= 0,
 		.data2_lane	= 3,
 		.data2_pol	= 0,
-		.div		= {
+	},
+
+	.clocks = {
+		.dispc = {
+			.lck_div	= 1,	/* Logic Clock = 172.8 MHz */
+			.pck_div	= 5,	/* Pixel Clock = 34.56 MHz */
+		},
+
+		.dsi = {
 			.regn		= 16,	/* Fint = 2.4 MHz */
 			.regm		= 180,	/* DDR Clock = 216 MHz */
 			.regm_dispc	= 5,	/* PLL1_CLK1 = 172.8 MHz */
 			.regm_dsi	= 5,	/* PLL1_CLK2 = 172.8 MHz */
 
 			.lp_clk_div	= 10,	/* LP Clock = 8.64 MHz */
-
-			.lck_div	= 1,	/* Logic Clock = 172.8 MHz */
-			.pck_div	= 5,	/* Pixel Clock = 34.56 MHz */
-
 		},
 	},
 	.channel		= OMAP_DSS_CHANNEL_LCD,
diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
index 5e04ddc..e10cfe2 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -401,18 +401,6 @@ struct omap_dss_device {
 			u8 data2_lane;
 			u8 data2_pol;
 
-			struct {
-				u16 regn;
-				u16 regm;
-				u16 regm_dispc;
-				u16 regm_dsi;
-
-				u16 lp_clk_div;
-
-				u16 lck_div;
-				u16 pck_div;
-			} div;
-
 			bool ext_te;
 			u8 ext_te_gpio;
 		} dsi;
@@ -424,6 +412,22 @@ struct omap_dss_device {
 	} phy;
 
 	struct {
+		struct {
+			u16 lck_div;
+			u16 pck_div;
+		} dispc;
+
+		struct {
+			u16 regn;
+			u16 regm;
+			u16 regm_dispc;
+			u16 regm_dsi;
+
+			u16 lp_clk_div;
+		} dsi;
+	} clocks;
+
+	struct {
 		struct omap_video_timings timings;
 
 		int acbi;	/* ac-bias pin transitions per interrupt */
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 23d9bbe..7304c87 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device *dssdev)
 	unsigned lp_clk_div;
 	unsigned long lp_clk;
 
-	lp_clk_div = dssdev->phy.dsi.div.lp_clk_div;
+	lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
 
 	if (lp_clk_div = 0 || lp_clk_div > dsi.lpdiv_max)
 		return -EINVAL;
@@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct omap_dss_device *dssdev)
 
 	/* we always use DSS_CLK_SYSCK as input clock */
 	cinfo.use_sys_clk = true;
-	cinfo.regn  = dssdev->phy.dsi.div.regn;
-	cinfo.regm  = dssdev->phy.dsi.div.regm;
-	cinfo.regm_dispc = dssdev->phy.dsi.div.regm_dispc;
-	cinfo.regm_dsi = dssdev->phy.dsi.div.regm_dsi;
+	cinfo.regn  = dssdev->clocks.dsi.regn;
+	cinfo.regm  = dssdev->clocks.dsi.regm;
+	cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
+	cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
 	r = dsi_calc_clock_rates(dssdev, &cinfo);
 	if (r) {
 		DSSERR("Failed to calc dsi clocks\n");
@@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
 
 	fck = dsi_get_pll_hsdiv_dispc_rate();
 
-	dispc_cinfo.lck_div = dssdev->phy.dsi.div.lck_div;
-	dispc_cinfo.pck_div = dssdev->phy.dsi.div.pck_div;
+	dispc_cinfo.lck_div = dssdev->clocks.dispc.lck_div;
+	dispc_cinfo.pck_div = dssdev->clocks.dispc.pck_div;
 
 	r = dispc_calc_clock_rates(fck, &dispc_cinfo);
 	if (r) {
-- 
1.7.1

[PATCH 2/9] OMAP: DSS2: remove non-working msleep(40) workaround

[Tomi Valkeinen]

The sleep workaround for the problem described in the comment doesn't
really work. This patch removes the workaround, and improves the comment
about the bug, and proposes an userspace workaround.

omap_dss_set_manager() is called 6 times when loading omapdss and
omapfb, which means that 40ms * 6 = 240ms was spent sleeping when
booting up.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/overlay.c |   19 ++++++++++++-------
 1 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index f1aca6d..fcde51b 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -491,13 +491,18 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
 	ovl->manager = mgr;
 
 	dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
-	/* XXX: on manual update display, in auto update mode, a bug happens
-	 * here. When an overlay is first enabled on LCD, then it's disabled,
-	 * and the manager is changed to TV, we sometimes get SYNC_LOST_DIGIT
-	 * errors. Waiting before changing the channel_out fixes it. I'm
-	 * guessing that the overlay is still somehow being used for the LCD,
-	 * but I don't understand how or why. */
-	msleep(40);
+	/* XXX: When there is an overlay on a DSI manual update display, and
+	 * the overlay is first disabled, then moved to tv, and enabled, we
+	 * seem to get SYNC_LOST_DIGIT error.
+	 *
+	 * Waiting doesn't seem to help, but updating the manual update display
+	 * after disabling the overlay seems to fix this. This hints that the
+	 * overlay is perhaps somehow tied to the LCD output until the output
+	 * is updated.
+	 *
+	 * Userspace workaround for this is to update the LCD after disabling
+	 * the overlay, but before moving the overlay to TV.
+	 */
 	dispc_set_channel_out(ovl->id, mgr->id);
 	dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
 
-- 
1.7.1

[PATCH 3/9] OMAP: DSS2: make 50ms bug-fix sleep optional

[Tomi Valkeinen]

For some unknown reason we may get SYNC_LOST errors from the display
subsystem at initialization time if we don't sleep before resetting the
DSS. See the source (dss.c) for more comments.

However, 50ms is quite long time to sleep, and with some configurations
the SYNC_LOST may never happen, so this patch creates a Kconfig option
to disable the sleep.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/Kconfig |   11 +++++++++++
 drivers/video/omap2/dss/dss.c   |    5 +++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index bfc5da0..458cfe1 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -125,4 +125,15 @@ config OMAP2_DSS_MIN_FCK_PER_PCK
 	  Max FCK is 173MHz, so this doesn't work if your PCK
 	  is very high.
 
+config OMAP2_DSS_SLEEP_BEFORE_RESET
+	bool "Sleep 50ms before DSS reset"
+	default y
+	help
+	  For some unknown reason we may get SYNC_LOST errors from the display
+	  subsystem at initialization time if we don't sleep before resetting
+	  the DSS. See the source (dss.c) for more comments.
+
+	  However, 50ms is quite long time to sleep, and with some
+	  configurations the SYNC_LOST may never happen, so the sleep can
+	  be disabled here.
 endif
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 3f1fee6..688947f 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -659,13 +659,18 @@ static int dss_init(void)
 	 * the kernel resets it */
 	omap_writel(omap_readl(0x48050440) & ~0x3, 0x48050440);
 
+#ifdef CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET
 	/* We need to wait here a bit, otherwise we sometimes start to
 	 * get synclost errors, and after that only power cycle will
 	 * restore DSS functionality. I have no idea why this happens.
 	 * And we have to wait _before_ resetting the DSS, but after
 	 * enabling clocks.
+	 *
+	 * This bug was at least present on OMAP3430. It's unknown
+	 * if it happens on OMAP2 or OMAP3630.
 	 */
 	msleep(50);
+#endif
 
 	_omap_dss_reset();
 
-- 
1.7.1

[PATCH 4/9] OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optional

[Tomi Valkeinen]

There's a 20ms sleep after VENC reset. It's unknown what bug this
circumvents and on what platforms. Add a Kconfig option to disable the
sleep.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/Kconfig |   12 ++++++++++++
 drivers/video/omap2/dss/venc.c  |    3 +++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 458cfe1..5b45c0c 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -136,4 +136,16 @@ config OMAP2_DSS_SLEEP_BEFORE_RESET
 	  However, 50ms is quite long time to sleep, and with some
 	  configurations the SYNC_LOST may never happen, so the sleep can
 	  be disabled here.
+
+config OMAP2_DSS_SLEEP_AFTER_VENC_RESET
+	bool "Sleep 20ms after VENC reset"
+	default y
+	help
+	  There is a 20ms sleep after VENC reset which seemed to fix the
+	  reset. The reason for the bug is unclear, and it's also unclear
+	  on what platforms this happens.
+
+	  This option enables the sleep, and is enabled by default. You can
+	  disable the sleep if it doesn't cause problems on your platform.
+
 endif
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 8e35a5b..8c7af90 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -373,8 +373,11 @@ static void venc_reset(void)
 		}
 	}
 
+#ifdef CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET
 	/* the magical sleep that makes things work */
+	/* XXX more info? What bug this circumvents? */
 	msleep(20);
+#endif
 }
 
 static void venc_enable_clocks(int enable)
-- 
1.7.1

[PATCH 5/9] OMAP: DSS2: VENC: Remove sleeps at venc enable/disable

[Tomi Valkeinen]

VENC code had 50ms sleep after enabling the output and 100ms sleep after
disabling the output. I don't see any reason for these sleeps.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/venc.c |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 8c7af90..fe18800 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -487,9 +487,6 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
 
 	dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
-	/* wait couple of vsyncs until enabling the LCD */
-	msleep(50);
-
 err1:
 	mutex_unlock(&venc.venc_lock);
 
@@ -513,9 +510,6 @@ static void venc_panel_disable(struct omap_dss_device *dssdev)
 
 	venc_power_off(dssdev);
 
-	/* wait at least 5 vsyncs after disabling the LCD */
-	msleep(100);
-
 	dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
 end:
 	mutex_unlock(&venc.venc_lock);
-- 
1.7.1

[PATCH 6/9] OMAP: DSS2: Add method for querying display dimensions from DSS drivers

[Tomi Valkeinen]

From: Jani Nikula <ext-jani.1.nikula@nokia.com>

Add get_dimensions() to struct omap_dss_driver. Use the call, if supported
by the driver, in OMAPFB.

Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 arch/arm/plat-omap/include/plat/display.h |    2 ++
 drivers/video/omap2/omapfb/omapfb-ioctl.c |   12 ++++++++++--
 drivers/video/omap2/omapfb/omapfb-main.c  |   12 ++++++++++--
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
index e10cfe2..f6e4b87 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -507,6 +507,8 @@ struct omap_dss_driver {
 
 	void (*get_resolution)(struct omap_dss_device *dssdev,
 			u16 *xres, u16 *yres);
+	void (*get_dimensions)(struct omap_dss_device *dssdev,
+			u32 *width, u32 *height);
 	int (*get_recommended_bpp)(struct omap_dss_device *dssdev);
 
 	int (*check_timings)(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 6f43545..b4636b1 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -895,8 +895,16 @@ int omapfb_ioctl(struct fb_info *fbi, unsigned int cmd, unsigned long arg)
 
 		p.display_info.xres = xres;
 		p.display_info.yres = yres;
-		p.display_info.width = 0;
-		p.display_info.height = 0;
+
+		if (display->driver->get_dimensions) {
+			u32 w, h;
+			display->driver->get_dimensions(display, &w, &h);
+			p.display_info.width = w;
+			p.display_info.height = h;
+		} else {
+			p.display_info.width = 0;
+			p.display_info.height = 0;
+		}
 
 		if (copy_to_user((void __user *)arg, &p.display_info,
 					sizeof(p.display_info)))
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 505ec66..163fb8b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -702,8 +702,16 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
 			var->xres, var->yres,
 			var->xres_virtual, var->yres_virtual);
 
-	var->height             = -1;
-	var->width              = -1;
+	if (display && display->driver->get_dimensions) {
+		u32 w, h;
+		display->driver->get_dimensions(display, &w, &h);
+		var->width = DIV_ROUND_CLOSEST(w, 1000);
+		var->height = DIV_ROUND_CLOSEST(h, 1000);
+	} else {
+		var->height = -1;
+		var->width = -1;
+	}
+
 	var->grayscale          = 0;
 
 	if (display && display->driver->get_timings) {
-- 
1.7.1

[PATCH 7/9] OMAP: DSS2: OMAPFB: Handle errors when initializing panel

[Tomi Valkeinen]

Errors from the panel driver were ignored during panel initialization.
Handle the errors and fail accordingly.

Also move the display initialization to a separate function to make it
cleaner.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   80 ++++++++++++++++++++++--------
 1 files changed, 59 insertions(+), 21 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 163fb8b..1b89e28 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2193,6 +2193,61 @@ static int omapfb_parse_def_modes(struct omapfb2_device *fbdev)
 	return r;
 }
 
+static int omapfb_init_display(struct omapfb2_device *fbdev,
+		struct omap_dss_device *dssdev)
+{
+	struct omap_dss_driver *dssdrv = dssdev->driver;
+	int r;
+
+	r = dssdrv->enable(dssdev);
+	if (r) {
+		dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
+				dssdev->name);
+		return r;
+	}
+
+	if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
+		u16 w, h;
+		if (dssdrv->enable_te) {
+			r = dssdrv->enable_te(dssdev, 1);
+			if (r) {
+				dev_err(fbdev->dev, "Failed to set TE\n");
+				return r;
+			}
+		}
+
+		if (dssdrv->set_update_mode) {
+			r = dssdrv->set_update_mode(dssdev,
+					OMAP_DSS_UPDATE_MANUAL);
+			if (r) {
+				dev_err(fbdev->dev,
+						"Failed to set update mode\n");
+				return r;
+			}
+		}
+
+		dssdrv->get_resolution(dssdev, &w, &h);
+		r = dssdrv->update(dssdev, 0, 0, w, h);
+		if (r) {
+			dev_err(fbdev->dev,
+					"Failed to update display\n");
+			return r;
+		}
+	} else {
+		if (dssdrv->set_update_mode) {
+			r = dssdrv->set_update_mode(dssdev,
+					OMAP_DSS_UPDATE_AUTO);
+			if (r) {
+				dev_err(fbdev->dev,
+						"Failed to set update mode\n");
+				return r;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static int omapfb_probe(struct platform_device *pdev)
 {
 	struct omapfb2_device *fbdev = NULL;
@@ -2292,30 +2347,13 @@ static int omapfb_probe(struct platform_device *pdev)
 	}
 
 	if (def_display) {
-		struct omap_dss_driver *dssdrv = def_display->driver;
-
-		r = def_display->driver->enable(def_display);
+		r = omapfb_init_display(fbdev, def_display);
 		if (r) {
-			dev_warn(fbdev->dev, "Failed to enable display '%s'\n",
-					def_display->name);
+			dev_err(fbdev->dev,
+					"failed to initialize default "
+					"display\n");
 			goto cleanup;
 		}
-
-		if (def_display->caps & OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE) {
-			u16 w, h;
-			if (dssdrv->enable_te)
-				dssdrv->enable_te(def_display, 1);
-			if (dssdrv->set_update_mode)
-				dssdrv->set_update_mode(def_display,
-						OMAP_DSS_UPDATE_MANUAL);
-
-			dssdrv->get_resolution(def_display, &w, &h);
-			def_display->driver->update(def_display, 0, 0, w, h);
-		} else {
-			if (dssdrv->set_update_mode)
-				dssdrv->set_update_mode(def_display,
-						OMAP_DSS_UPDATE_AUTO);
-		}
 	}
 
 	DBG("create sysfs for fbs\n");
-- 
1.7.1

[PATCH 8/9] OMAP: DSS2: OMAPFB: Remove implicit display update on unblank

[Tomi Valkeinen]

From: Jani Nikula <ext-jani.1.nikula@nokia.com>

Currently omapfb does an implicit display update (for manual update
displays) on unblank.

There is no guarantee that the framebuffer contains a valid image when
unblank is called. When using manual update displays it is the
responsibility of the user space to update the display, and so it should
be in this case also.

This patch removes the implicit display update on unblank.

Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com>
[tomi.valkeinen@ti.com: improved description]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   13 -------------
 1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 1b89e28..1f9cb3a 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1271,7 +1271,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
 	struct omapfb_info *ofbi = FB2OFB(fbi);
 	struct omapfb2_device *fbdev = ofbi->fbdev;
 	struct omap_dss_device *display = fb2display(fbi);
-	int do_update = 0;
 	int r = 0;
 
 	if (!display)
@@ -1287,11 +1286,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
 		if (display->driver->resume)
 			r = display->driver->resume(display);
 
-		if (r = 0 && display->driver->get_update_mode &&
-				display->driver->get_update_mode(display) =
-				OMAP_DSS_UPDATE_MANUAL)
-			do_update = 1;
-
 		break;
 
 	case FB_BLANK_NORMAL:
@@ -1315,13 +1309,6 @@ static int omapfb_blank(int blank, struct fb_info *fbi)
 exit:
 	omapfb_unlock(fbdev);
 
-	if (r = 0 && do_update && display->driver->update) {
-		u16 w, h;
-		display->driver->get_resolution(display, &w, &h);
-
-		r = display->driver->update(display, 0, 0, w, h);
-	}
-
 	return r;
 }
 
-- 
1.7.1

[PATCH 9/9] OMAP: DSS2: VENC: Add missing start/stop_device calls

[Tomi Valkeinen]

VENC code was missing omap_dss_start/stop_device calls. This didn't
cause any problems as VENC could not be compiled as a module, but
nevertheless it's better to add the calls.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/venc.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index fe18800..b845c56 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -476,6 +476,12 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
 
 	mutex_lock(&venc.venc_lock);
 
+	r = omap_dss_start_device(dssdev);
+	if (r) {
+		DSSERR("failed to start device\n");
+		goto err0;
+	}
+
 	if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
 		r = -EINVAL;
 		goto err1;
@@ -487,7 +493,11 @@ static int venc_panel_enable(struct omap_dss_device *dssdev)
 
 	dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
+	mutex_unlock(&venc.venc_lock);
+	return 0;
 err1:
+	omap_dss_stop_device(dssdev);
+err0:
 	mutex_unlock(&venc.venc_lock);
 
 	return r;
@@ -511,6 +521,8 @@ static void venc_panel_disable(struct omap_dss_device *dssdev)
 	venc_power_off(dssdev);
 
 	dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+
+	omap_dss_stop_device(dssdev);
 end:
 	mutex_unlock(&venc.venc_lock);
 }
-- 
1.7.1

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Tomi Valkeinen]

On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> > Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> > config doesn't really belong there, and so it's moved to dssdev.clock
> > struct.
> >
> > Now the explicit clock configuration could also be used for other
> > interfaces than DSI, although there's no support for it currently.
> >
> > Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> > ---
> >   arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
> >   arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
> >   drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
> >   3 files changed, 32 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> > index 05288c9..626b16b 100644
> > --- a/arch/arm/mach-omap2/board-4430sdp.c
> > +++ b/arch/arm/mach-omap2/board-4430sdp.c

<snip>

> > @@ -424,6 +412,22 @@ struct omap_dss_device {
> >   	} phy;
> >
> >   	struct {
> > +		struct {
> > +			u16 lck_div;
> > +			u16 pck_div;
> 
> Is it possible to wrap these members around a channel member? The board 
> file can then fill up the lck_div and ppck_div based on what channel it 
> is using.

Hmm. What do you mean "wrap around"? The channel is defined a bit below
there.

 Tomi

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Archit Taneja]

On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> config doesn't really belong there, and so it's moved to dssdev.clock
> struct.
>
> Now the explicit clock configuration could also be used for other
> interfaces than DSI, although there's no support for it currently.
>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
>   arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
>   arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
>   drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
>   3 files changed, 32 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 05288c9..626b16b 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
>   		.data1_pol	= 0,
>   		.data2_lane	= 3,
>   		.data2_pol	= 0,
> -		.div		= {
> +	},
> +
> +	.clocks = {
> +		.dispc = {
> +			.lck_div	= 1,	/* Logic Clock = 172.8 MHz */
> +			.pck_div	= 5,	/* Pixel Clock = 34.56 MHz */
> +		},
> +
> +		.dsi = {
>   			.regn		= 16,	/* Fint = 2.4 MHz */
>   			.regm		= 180,	/* DDR Clock = 216 MHz */
>   			.regm_dispc	= 5,	/* PLL1_CLK1 = 172.8 MHz */
>   			.regm_dsi	= 5,	/* PLL1_CLK2 = 172.8 MHz */
>
>   			.lp_clk_div	= 10,	/* LP Clock = 8.64 MHz */
> -
> -			.lck_div	= 1,	/* Logic Clock = 172.8 MHz */
> -			.pck_div	= 5,	/* Pixel Clock = 34.56 MHz */
> -
>   		},
>   	},
>   	.channel		= OMAP_DSS_CHANNEL_LCD,
> diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h
> index 5e04ddc..e10cfe2 100644
> --- a/arch/arm/plat-omap/include/plat/display.h
> +++ b/arch/arm/plat-omap/include/plat/display.h
> @@ -401,18 +401,6 @@ struct omap_dss_device {
>   			u8 data2_lane;
>   			u8 data2_pol;
>
> -			struct {
> -				u16 regn;
> -				u16 regm;
> -				u16 regm_dispc;
> -				u16 regm_dsi;
> -
> -				u16 lp_clk_div;
> -
> -				u16 lck_div;
> -				u16 pck_div;
> -			} div;
> -
>   			bool ext_te;
>   			u8 ext_te_gpio;
>   		} dsi;
> @@ -424,6 +412,22 @@ struct omap_dss_device {
>   	} phy;
>
>   	struct {
> +		struct {
> +			u16 lck_div;
> +			u16 pck_div;

Is it possible to wrap these members around a channel member? The board 
file can then fill up the lck_div and ppck_div based on what channel it 
is using.

Archit

> +		} dispc;
> +
> +		struct {
> +			u16 regn;
> +			u16 regm;
> +			u16 regm_dispc;
> +			u16 regm_dsi;
> +
> +			u16 lp_clk_div;
> +		} dsi;
> +	} clocks;
> +
> +	struct {
>   		struct omap_video_timings timings;
>
>   		int acbi;	/* ac-bias pin transitions per interrupt */
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index 23d9bbe..7304c87 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device *dssdev)
>   	unsigned lp_clk_div;
>   	unsigned long lp_clk;
>
> -	lp_clk_div = dssdev->phy.dsi.div.lp_clk_div;
> +	lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
>
>   	if (lp_clk_div = 0 || lp_clk_div>  dsi.lpdiv_max)
>   		return -EINVAL;
> @@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct omap_dss_device *dssdev)
>
>   	/* we always use DSS_CLK_SYSCK as input clock */
>   	cinfo.use_sys_clk = true;
> -	cinfo.regn  = dssdev->phy.dsi.div.regn;
> -	cinfo.regm  = dssdev->phy.dsi.div.regm;
> -	cinfo.regm_dispc = dssdev->phy.dsi.div.regm_dispc;
> -	cinfo.regm_dsi = dssdev->phy.dsi.div.regm_dsi;
> +	cinfo.regn  = dssdev->clocks.dsi.regn;
> +	cinfo.regm  = dssdev->clocks.dsi.regm;
> +	cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
> +	cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
>   	r = dsi_calc_clock_rates(dssdev,&cinfo);
>   	if (r) {
>   		DSSERR("Failed to calc dsi clocks\n");
> @@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
>
>   	fck = dsi_get_pll_hsdiv_dispc_rate();
>
> -	dispc_cinfo.lck_div = dssdev->phy.dsi.div.lck_div;
> -	dispc_cinfo.pck_div = dssdev->phy.dsi.div.pck_div;
> +	dispc_cinfo.lck_div = dssdev->clocks.dispc.lck_div;
> +	dispc_cinfo.pck_div = dssdev->clocks.dispc.pck_div;
>
>   	r = dispc_calc_clock_rates(fck,&dispc_cinfo);
>   	if (r) {

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Archit Taneja]

On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
>> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
>>> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
>>> config doesn't really belong there, and so it's moved to dssdev.clock
>>> struct.
>>>
>>> Now the explicit clock configuration could also be used for other
>>> interfaces than DSI, although there's no support for it currently.
>>>
>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>> ---
>>>    arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
>>>    arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
>>>    drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
>>>    3 files changed, 32 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
>>> index 05288c9..626b16b 100644
>>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>
> <snip>
>
>>> @@ -424,6 +412,22 @@ struct omap_dss_device {
>>>    	} phy;
>>>
>>>    	struct {
>>> +		struct {
>>> +			u16 lck_div;
>>> +			u16 pck_div;
>>
>> Is it possible to wrap these members around a channel member? The board
>> file can then fill up the lck_div and ppck_div based on what channel it
>> is using.
>
> Hmm. What do you mean "wrap around"? The channel is defined a bit below
> there.
>

I meant something like:
	
	...
	struct {
		struct {
			struct {
				u16 lck_div;
				u16 pck_div;
			} channel[MAX_CHANNELS];
		} dispc;

		...

		struct {

		} dsi;

	} clocks;
	...

Or something equivalent to the thing above, like using a pointer to an 
array.

Archit

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Tomi Valkeinen]

On Fri, 2011-04-01 at 13:21 +0530, Archit Taneja wrote:
> On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
> > On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
> >> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
> >>> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
> >>> config doesn't really belong there, and so it's moved to dssdev.clock
> >>> struct.
> >>>
> >>> Now the explicit clock configuration could also be used for other
> >>> interfaces than DSI, although there's no support for it currently.
> >>>
> >>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> >>> ---
> >>>    arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
> >>>    arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
> >>>    drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
> >>>    3 files changed, 32 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> >>> index 05288c9..626b16b 100644
> >>> --- a/arch/arm/mach-omap2/board-4430sdp.c
> >>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> >
> > <snip>
> >
> >>> @@ -424,6 +412,22 @@ struct omap_dss_device {
> >>>    	} phy;
> >>>
> >>>    	struct {
> >>> +		struct {
> >>> +			u16 lck_div;
> >>> +			u16 pck_div;
> >>
> >> Is it possible to wrap these members around a channel member? The board
> >> file can then fill up the lck_div and ppck_div based on what channel it
> >> is using.
> >
> > Hmm. What do you mean "wrap around"? The channel is defined a bit below
> > there.
> >
> 
> I meant something like:
> 	
> 	...
> 	struct {
> 		struct {
> 			struct {
> 				u16 lck_div;
> 				u16 pck_div;
> 			} channel[MAX_CHANNELS];
> 		} dispc;
> 
> 		...
> 
> 		struct {
> 
> 		} dsi;
> 
> 	} clocks;
> 	...
> 
> Or something equivalent to the thing above, like using a pointer to an 
> array.

What would be the benefit of that? A dss device can be connected only to
one channel. Now we have the dividers and the channel defined, and
omapdss can use this info to configure the dividers for that channel
properly.

 Tomi

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Archit Taneja]

On Friday 01 April 2011 01:20 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 13:21 +0530, Archit Taneja wrote:
>> On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
>>> On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
>>>> On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
>>>>> Clock configuration was defined inside dssdev.phy.dsi struct. The clock
>>>>> config doesn't really belong there, and so it's moved to dssdev.clock
>>>>> struct.
>>>>>
>>>>> Now the explicit clock configuration could also be used for other
>>>>> interfaces than DSI, although there's no support for it currently.
>>>>>
>>>>> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
>>>>> ---
>>>>>     arch/arm/mach-omap2/board-4430sdp.c       |   14 +++++++++-----
>>>>>     arch/arm/plat-omap/include/plat/display.h |   28 ++++++++++++++++------------
>>>>>     drivers/video/omap2/dss/dsi.c             |   14 +++++++-------
>>>>>     3 files changed, 32 insertions(+), 24 deletions(-)
>>>>>

<snip>

>> I meant something like:
>> 	
>> 	...
>> 	struct {
>> 		struct {
>> 			struct {
>> 				u16 lck_div;
>> 				u16 pck_div;
>> 			} channel[MAX_CHANNELS];
>> 		} dispc;
>>
>> 		...
>>
>> 		struct {
>>
>> 		} dsi;
>>
>> 	} clocks;
>> 	...
>>
>> Or something equivalent to the thing above, like using a pointer to an
>> array.
>
> What would be the benefit of that? A dss device can be connected only to
> one channel. Now we have the dividers and the channel defined, and
> omapdss can use this info to configure the dividers for that channel
> properly.

Okay, I guess channel wasn't the best example to explain my point, and I 
guess its safe for dss device not to touch any other channels (currently 
ignoring complex bridge chips which can merge data of 2 LCD channels 
onto one panel).

But there are some parameters which might get common across dss devices.
Things like dispc clock source, dispc core clock divider will be shared 
across the panels. We had discussed the possibility of declaring this 
common info in omap_dss_board_info or as a separate common_clocks 
structure. Each device could pick this filled up common_clocks struct, 
or fill it up its own way (for the use cases which has only one panel on 
at a time). I was wondering if it would be easy to move to this approach 
with your patch. dispc itself would now have some common clock stuff and 
per panel clock stuff. Is that a very clean approach?

Anyway, I think it would be good to have a channel struct, as there are 
more things to put in dispc clocks, it should look something like:

struct clocks {
		struct {
			struct {
				u16 lck_div;
				u16 pck_div;
				enum clock_source lcd_clk_src;
			} channel;
			...
			...
			u16 core_clk_div;
		} dispc;
		...
		...
};

Archit

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Tomi Valkeinen]

On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:

> But there are some parameters which might get common across dss devices.
> Things like dispc clock source, dispc core clock divider will be shared 
> across the panels. We had discussed the possibility of declaring this 
> common info in omap_dss_board_info or as a separate common_clocks 
> structure. Each device could pick this filled up common_clocks struct, 
> or fill it up its own way (for the use cases which has only one panel on 
> at a time). I was wondering if it would be easy to move to this approach 
> with your patch. dispc itself would now have some common clock stuff and 
> per panel clock stuff. Is that a very clean approach?

I don't know =). I think the simplest solution is to have full divisor
info for each dss_device. And it's up to the board file writer to make
sure the divisors match for all the displays that can be enabled at the
same time.

I don't think that is perfect, but trying to share the data sounds a bit
confusing. Especially as there are just a divisor and a clock source
that are shared. If we have a lot of common data, then a shared struct
would of course be better.

> Anyway, I think it would be good to have a channel struct, as there are 
> more things to put in dispc clocks, it should look something like:
> 
> struct clocks {
> 		struct {
> 			struct {
> 				u16 lck_div;
> 				u16 pck_div;
> 				enum clock_source lcd_clk_src;
> 			} channel;
> 			...
> 			...
> 			u16 core_clk_div;
> 		} dispc;
> 		...
> 		...
> };

In my original patch I had:

        struct {
                struct {
                        u16 fck_div;
                } dss;

                struct {
                        u16 lck_div;
                        u16 pck_div;

                        bool fclk_from_dsi_pll;
                } dispc;

		...
	};

Which I removed due to comments and slight confusion how to handle the
DSS_FCLK divisor and the clock source.

Adding the clock source there needs some more work, moving the enum to
public include file, and implementing the support. If you agree that
this patch in its current form is an improvement, I'd like to go forward
with this and work on the clock source later.

 Tomi

Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration

[Archit Taneja]

On Friday 01 April 2011 02:09 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:
>
>> But there are some parameters which might get common across dss devices.
>> Things like dispc clock source, dispc core clock divider will be shared
>> across the panels. We had discussed the possibility of declaring this
>> common info in omap_dss_board_info or as a separate common_clocks
>> structure. Each device could pick this filled up common_clocks struct,
>> or fill it up its own way (for the use cases which has only one panel on
>> at a time). I was wondering if it would be easy to move to this approach
>> with your patch. dispc itself would now have some common clock stuff and
>> per panel clock stuff. Is that a very clean approach?
>
> I don't know =). I think the simplest solution is to have full divisor
> info for each dss_device. And it's up to the board file writer to make
> sure the divisors match for all the displays that can be enabled at the
> same time.
>
> I don't think that is perfect, but trying to share the data sounds a bit
> confusing. Especially as there are just a divisor and a clock source
> that are shared. If we have a lot of common data, then a shared struct
> would of course be better.
>
>> Anyway, I think it would be good to have a channel struct, as there are
>> more things to put in dispc clocks, it should look something like:
>>
>> struct clocks {
>> 		struct {
>> 			struct {
>> 				u16 lck_div;
>> 				u16 pck_div;
>> 				enum clock_source lcd_clk_src;
>> 			} channel;
>> 			...
>> 			...
>> 			u16 core_clk_div;
>> 		} dispc;
>> 		...
>> 		...
>> };
>
> In my original patch I had:
>
>          struct {
>                  struct {
>                          u16 fck_div;
>                  } dss;
>
>                  struct {
>                          u16 lck_div;
>                          u16 pck_div;
>
>                          bool fclk_from_dsi_pll;
>                  } dispc;
>
> 		...
> 	};
>
> Which I removed due to comments and slight confusion how to handle the
> DSS_FCLK divisor and the clock source.
>
> Adding the clock source there needs some more work, moving the enum to
> public include file, and implementing the support. If you agree that
> this patch in its current form is an improvement, I'd like to go forward
> with this and work on the clock source later.

Yeah it is, sure.

Archit