[PATCH 0/4] OMAPDSS: misc minor fixes

[PATCH 0/4] OMAPDSS: misc minor fixes

[Tomi Valkeinen]

Some minor fixes for DSS. 

 Tomi

Tomi Valkeinen (4):
  OMAP: OMAPFB: make omapfb start even when a display is missing a
    driver
  OMAP: DSS2: fix clock sources on error and uninit
  OMAP: DSS2: Handle manager change in apply
  OMAP: DSS2: Remove "EXPERIMENTAL" from Kconfig

 drivers/video/omap2/dss/Kconfig          |    2 +-
 drivers/video/omap2/dss/dispc.c          |    4 +++-
 drivers/video/omap2/dss/dpi.c            |    4 +++-
 drivers/video/omap2/dss/dsi.c            |    3 +++
 drivers/video/omap2/dss/dss.h            |    2 --
 drivers/video/omap2/dss/manager.c        |    5 +++++
 drivers/video/omap2/dss/overlay.c        |    9 ++-------
 drivers/video/omap2/omapfb/Kconfig       |    2 +-
 drivers/video/omap2/omapfb/omapfb-main.c |    5 +++--
 include/video/omapdss.h                  |    1 +
 10 files changed, 22 insertions(+), 15 deletions(-)

-- 
1.7.4.1

[PATCH 0/4] OMAPDSS: misc minor fixes

[Tomi Valkeinen]

Some minor fixes for DSS. 

 Tomi

Tomi Valkeinen (4):
  OMAP: OMAPFB: make omapfb start even when a display is missing a
    driver
  OMAP: DSS2: fix clock sources on error and uninit
  OMAP: DSS2: Handle manager change in apply
  OMAP: DSS2: Remove "EXPERIMENTAL" from Kconfig

 drivers/video/omap2/dss/Kconfig          |    2 +-
 drivers/video/omap2/dss/dispc.c          |    4 +++-
 drivers/video/omap2/dss/dpi.c            |    4 +++-
 drivers/video/omap2/dss/dsi.c            |    3 +++
 drivers/video/omap2/dss/dss.h            |    2 --
 drivers/video/omap2/dss/manager.c        |    5 +++++
 drivers/video/omap2/dss/overlay.c        |    9 ++-------
 drivers/video/omap2/omapfb/Kconfig       |    2 +-
 drivers/video/omap2/omapfb/omapfb-main.c |    5 +++--
 include/video/omapdss.h                  |    1 +
 10 files changed, 22 insertions(+), 15 deletions(-)

-- 
1.7.4.1

[PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display is missing a driver

[Tomi Valkeinen]

Currently omapfb wants that all the display devices have a driver,
otherwise omapfb refuses to start. There's no real requirement to act
like that, and this patch will make omapfb give a warning and skip that
device.

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

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index e5a64b3..cd2cae8e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2373,9 +2373,10 @@ static int omapfb_probe(struct platform_device *pdev)
 		omap_dss_get_device(dssdev);
 
 		if (!dssdev->driver) {
-			dev_err(&pdev->dev, "no driver for display: %s\n",
+			dev_warn(&pdev->dev, "no driver for display: %s\n",
 				dssdev->name);
-			r = -ENODEV;
+			omap_dss_put_device(dssdev);
+			continue;
 		}
 
 		d = &fbdev->displays[fbdev->num_displays++];
-- 
1.7.4.1

[PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display is missing a driver

[Tomi Valkeinen]

Currently omapfb wants that all the display devices have a driver,
otherwise omapfb refuses to start. There's no real requirement to act
like that, and this patch will make omapfb give a warning and skip that
device.

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

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index e5a64b3..cd2cae8e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2373,9 +2373,10 @@ static int omapfb_probe(struct platform_device *pdev)
 		omap_dss_get_device(dssdev);
 
 		if (!dssdev->driver) {
-			dev_err(&pdev->dev, "no driver for display: %s\n",
+			dev_warn(&pdev->dev, "no driver for display: %s\n",
 				dssdev->name);
-			r = -ENODEV;
+			omap_dss_put_device(dssdev);
+			continue;
 		}
 
 		d = &fbdev->displays[fbdev->num_displays++];
-- 
1.7.4.1

Re: [PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display

[Jaya Kumar]

On Mon, Aug 22, 2011 at 4:27 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Currently omapfb wants that all the display devices have a driver,
> otherwise omapfb refuses to start. There's no real requirement to act
> like that, and this patch will make omapfb give a warning and skip that
> device.

Hi Tomi,

Just a question, I am working with an out-of-tree hdmi driver for the
NXP TDA9984 with dm3730. This worked fine in 2.6.32 as a runtime
loaded dss display driver. That is:

+static struct omap_dss_device wiser2_hdmi_device = {
+       .type = OMAP_DISPLAY_TYPE_DPI,
+       .name = "hdmi",
+       .driver_name = "hdmi_panel",
+       .phy.dpi.data_lines = 24,
+       .platform_enable = wiser2_enable_hdmi,
+       .platform_disable = wiser2_disable_hdmi,
+};
+
+static struct omap_dss_device wiser2_tv_device = {
+       .name = "tv",
+       .driver_name = "venc",
+       .type = OMAP_DISPLAY_TYPE_VENC,
+       .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+       .platform_enable = wiser2_panel_enable_tv,
+       .platform_disable = wiser2_panel_disable_tv,
+};
+
+static struct omap_dss_device *wiser2_dss_devices[] = {
+       &wiser2_dvi_device,
+       &wiser2_tv_device,
+       &wiser2_hdmi_device,
+};

so this hdmi_panel omap_dss_driver was being insmoded after init at
bootup and it worked fine, no problems with omaplfb so pvr stuff
worked fine.

I then switched to 2.6.37 (from TI devkit 2.1 gingerbread) and this
kernel wasn't so happy (panic at boot). I applied your patch below. I
also figured out that omap_vout had a similar problem as the one
you've fixed which was what was causing the panic (omap_vout tries to
call display->driver->update without checking if driver exists):
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 2aee372..36d69db 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2574,24 +2591,32 @@ static int __init omap_vout_probe(struct
platform_device *pdev)
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        for (i = 0; i < vid_dev->num_displays; i++) {
                struct omap_dss_device *display = vid_dev->displays[i];

-               if (display->driver->update)
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
+               if ((display->driver) && (display->driver->update)) {
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
                        display->driver->update(display, 0, 0,
                                        display->panel.timings.x_res,
                                        display->panel.timings.y_res);
+               }
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        }
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        return 0;

After that change, it boots up cleanly but I don't get any display
output. I noticed that:
echo 1 > /sys/devices/omapdss/display2/enabled
no longer works. display2 stays enabled=0 rather than coming on.

I'm planning on debugging this some more when I have some free time.
But I figured I should ask first if this is a known problem, whether
anyone else is testing runtime loaded omap_dss_driver stuff and if
anyone has gotten it to work with kernels 2.6.37 and above.

Thanks,
jaya

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/video/omap2/omapfb/omapfb-main.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index e5a64b3..cd2cae8e 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2373,9 +2373,10 @@ static int omapfb_probe(struct platform_device *pdev)
>                omap_dss_get_device(dssdev);
>
>                if (!dssdev->driver) {
> -                       dev_err(&pdev->dev, "no driver for display: %s\n",
> +                       dev_warn(&pdev->dev, "no driver for display: %s\n",
>                                dssdev->name);
> -                       r = -ENODEV;
> +                       omap_dss_put_device(dssdev);
> +                       continue;
>                }
>
>                d = &fbdev->displays[fbdev->num_displays++];
> --
> 1.7.4.1
>
> --
> 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
>

Re: [PATCH 1/4] OMAP: OMAPFB: make omapfb start even when a display is missing a driver

[Jaya Kumar]

On Mon, Aug 22, 2011 at 4:27 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Currently omapfb wants that all the display devices have a driver,
> otherwise omapfb refuses to start. There's no real requirement to act
> like that, and this patch will make omapfb give a warning and skip that
> device.

Hi Tomi,

Just a question, I am working with an out-of-tree hdmi driver for the
NXP TDA9984 with dm3730. This worked fine in 2.6.32 as a runtime
loaded dss display driver. That is:

+static struct omap_dss_device wiser2_hdmi_device = {
+       .type = OMAP_DISPLAY_TYPE_DPI,
+       .name = "hdmi",
+       .driver_name = "hdmi_panel",
+       .phy.dpi.data_lines = 24,
+       .platform_enable = wiser2_enable_hdmi,
+       .platform_disable = wiser2_disable_hdmi,
+};
+
+static struct omap_dss_device wiser2_tv_device = {
+       .name = "tv",
+       .driver_name = "venc",
+       .type = OMAP_DISPLAY_TYPE_VENC,
+       .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+       .platform_enable = wiser2_panel_enable_tv,
+       .platform_disable = wiser2_panel_disable_tv,
+};
+
+static struct omap_dss_device *wiser2_dss_devices[] = {
+       &wiser2_dvi_device,
+       &wiser2_tv_device,
+       &wiser2_hdmi_device,
+};

so this hdmi_panel omap_dss_driver was being insmoded after init at
bootup and it worked fine, no problems with omaplfb so pvr stuff
worked fine.

I then switched to 2.6.37 (from TI devkit 2.1 gingerbread) and this
kernel wasn't so happy (panic at boot). I applied your patch below. I
also figured out that omap_vout had a similar problem as the one
you've fixed which was what was causing the panic (omap_vout tries to
call display->driver->update without checking if driver exists):
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 2aee372..36d69db 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2574,24 +2591,32 @@ static int __init omap_vout_probe(struct
platform_device *pdev)
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        for (i = 0; i < vid_dev->num_displays; i++) {
                struct omap_dss_device *display = vid_dev->displays[i];

-               if (display->driver->update)
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
+               if ((display->driver) && (display->driver->update)) {
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
                        display->driver->update(display, 0, 0,
                                        display->panel.timings.x_res,
                                        display->panel.timings.y_res);
+               }
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        }
+       printk(KERN_INFO "%s:%d\n", __func__, __LINE__);
        return 0;

After that change, it boots up cleanly but I don't get any display
output. I noticed that:
echo 1 > /sys/devices/omapdss/display2/enabled
no longer works. display2 stays enabled=0 rather than coming on.

I'm planning on debugging this some more when I have some free time.
But I figured I should ask first if this is a known problem, whether
anyone else is testing runtime loaded omap_dss_driver stuff and if
anyone has gotten it to work with kernels 2.6.37 and above.

Thanks,
jaya

>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
>  drivers/video/omap2/omapfb/omapfb-main.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index e5a64b3..cd2cae8e 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2373,9 +2373,10 @@ static int omapfb_probe(struct platform_device *pdev)
>                omap_dss_get_device(dssdev);
>
>                if (!dssdev->driver) {
> -                       dev_err(&pdev->dev, "no driver for display: %s\n",
> +                       dev_warn(&pdev->dev, "no driver for display: %s\n",
>                                dssdev->name);
> -                       r = -ENODEV;
> +                       omap_dss_put_device(dssdev);
> +                       continue;
>                }
>
>                d = &fbdev->displays[fbdev->num_displays++];
> --
> 1.7.4.1
>
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] OMAP: DSS2: fix clock sources on error and uninit

[Tomi Valkeinen]

DPI and DSI were not cleaning up the clock source in error or uninit
cases. Set the clock source back to PRCM.

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

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 046ce08..dc698bd 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -83,8 +83,10 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev, bool is_tft,
 	dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
 
 	r = dispc_set_clock_div(dssdev->manager->id, &dispc_cinfo);
-	if (r)
+	if (r) {
+		dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 		return r;
+	}
 
 	*fck = dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
 	*lck_div = dispc_cinfo.lck_div;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ae6bf1d..c951a75 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4184,6 +4184,8 @@ err3:
 err2:
 	dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 	dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
+	dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
+
 err1:
 	dsi_pll_uninit(dsidev, true);
 err0:
@@ -4209,6 +4211,7 @@ static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
 
 	dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 	dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
+	dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
 	dsi_cio_uninit(dssdev);
 	dsi_pll_uninit(dsidev, disconnect_lanes);
 }
-- 
1.7.4.1

[PATCH 2/4] OMAP: DSS2: fix clock sources on error and uninit

[Tomi Valkeinen]

DPI and DSI were not cleaning up the clock source in error or uninit
cases. Set the clock source back to PRCM.

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

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 046ce08..dc698bd 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -83,8 +83,10 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev, bool is_tft,
 	dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
 
 	r = dispc_set_clock_div(dssdev->manager->id, &dispc_cinfo);
-	if (r)
+	if (r) {
+		dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 		return r;
+	}
 
 	*fck = dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
 	*lck_div = dispc_cinfo.lck_div;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ae6bf1d..c951a75 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4184,6 +4184,8 @@ err3:
 err2:
 	dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 	dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
+	dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
+
 err1:
 	dsi_pll_uninit(dsidev, true);
 err0:
@@ -4209,6 +4211,7 @@ static void dsi_display_uninit_dsi(struct omap_dss_device *dssdev,
 
 	dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
 	dss_select_dsi_clk_source(dsi_module, OMAP_DSS_CLK_SRC_FCK);
+	dss_select_lcd_clk_source(dssdev->manager->id, OMAP_DSS_CLK_SRC_FCK);
 	dsi_cio_uninit(dssdev);
 	dsi_pll_uninit(dsidev, disconnect_lanes);
 }
-- 
1.7.4.1

[PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Tomi Valkeinen]

Currently when changing the manager of an overlay, set_manager() directly
calls dispc to set the overlay's destination.

Change this to be more in line with other overlay configurations, and
this will also remove the need to have dispc clocks enabled when calling
set_manager().

A new field is added to overlay struct, "manager_changed". This is
similar to "display_changed" field in manager struct, and is used to
inform apply that the manager has changed and thus write to the
registers is needed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dispc.c   |    4 +++-
 drivers/video/omap2/dss/dss.h     |    2 --
 drivers/video/omap2/dss/manager.c |    5 +++++
 drivers/video/omap2/dss/overlay.c |    9 ++-------
 include/video/omapdss.h           |    1 +
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9d9fbeb..003227c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -841,7 +841,7 @@ static void _dispc_set_color_mode(enum omap_plane plane,
 	REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), m, 4, 1);
 }
 
-void dispc_set_channel_out(enum omap_plane plane,
+static void dispc_set_channel_out(enum omap_plane plane,
 		enum omap_channel channel)
 {
 	int shift;
@@ -1860,6 +1860,8 @@ int dispc_setup_plane(enum omap_plane plane,
 	_dispc_set_pre_mult_alpha(plane, pre_mult_alpha);
 	_dispc_setup_global_alpha(plane, global_alpha);
 
+	dispc_set_channel_out(plane, channel);
+
 	return 0;
 }
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index adeff04..ff7ac35 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -399,8 +399,6 @@ void dispc_set_plane_ba0(enum omap_plane plane, u32 paddr);
 void dispc_set_plane_ba1(enum omap_plane plane, u32 paddr);
 void dispc_set_plane_pos(enum omap_plane plane, u16 x, u16 y);
 void dispc_set_plane_size(enum omap_plane plane, u16 width, u16 height);
-void dispc_set_channel_out(enum omap_plane plane,
-		enum omap_channel channel_out);
 
 void dispc_enable_gamma_table(bool enable);
 int dispc_setup_plane(enum omap_plane plane,
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index 63674b0..a6a909a 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1338,6 +1338,11 @@ static int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
 
 		oc = &dss_cache.overlay_cache[ovl->id];
 
+		if (ovl->manager_changed) {
+			ovl->manager_changed = false;
+			ovl->info_dirty  = true;
+		}
+
 		if (!overlay_enabled(ovl)) {
 			if (oc->enabled) {
 				oc->enabled = false;
diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index c84380c..ab44403 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -516,6 +516,7 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
 	}
 
 	ovl->manager = mgr;
+	ovl->manager_changed = true;
 
 	/* 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
@@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
 	 * 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);
 
 	return 0;
 }
 
 static int omap_dss_unset_manager(struct omap_overlay *ovl)
 {
-	int r;
-
 	if (!ovl->manager) {
 		DSSERR("failed to detach overlay: manager not set\n");
 		return -EINVAL;
@@ -548,11 +546,8 @@ static int omap_dss_unset_manager(struct omap_overlay *ovl)
 		return -EINVAL;
 	}
 
-	r = ovl->wait_for_go(ovl);
-	if (r)
-		return r;
-
 	ovl->manager = NULL;
+	ovl->manager_changed = true;
 
 	return 0;
 }
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 9301805..b965f5a 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -326,6 +326,7 @@ struct omap_overlay {
 	struct omap_overlay_manager *manager;
 	struct omap_overlay_info info;
 
+	bool manager_changed;
 	/* if true, info has been changed, but not applied() yet */
 	bool info_dirty;
 
-- 
1.7.4.1

[PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Tomi Valkeinen]

Currently when changing the manager of an overlay, set_manager() directly
calls dispc to set the overlay's destination.

Change this to be more in line with other overlay configurations, and
this will also remove the need to have dispc clocks enabled when calling
set_manager().

A new field is added to overlay struct, "manager_changed". This is
similar to "display_changed" field in manager struct, and is used to
inform apply that the manager has changed and thus write to the
registers is needed.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dispc.c   |    4 +++-
 drivers/video/omap2/dss/dss.h     |    2 --
 drivers/video/omap2/dss/manager.c |    5 +++++
 drivers/video/omap2/dss/overlay.c |    9 ++-------
 include/video/omapdss.h           |    1 +
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9d9fbeb..003227c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -841,7 +841,7 @@ static void _dispc_set_color_mode(enum omap_plane plane,
 	REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), m, 4, 1);
 }
 
-void dispc_set_channel_out(enum omap_plane plane,
+static void dispc_set_channel_out(enum omap_plane plane,
 		enum omap_channel channel)
 {
 	int shift;
@@ -1860,6 +1860,8 @@ int dispc_setup_plane(enum omap_plane plane,
 	_dispc_set_pre_mult_alpha(plane, pre_mult_alpha);
 	_dispc_setup_global_alpha(plane, global_alpha);
 
+	dispc_set_channel_out(plane, channel);
+
 	return 0;
 }
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index adeff04..ff7ac35 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -399,8 +399,6 @@ void dispc_set_plane_ba0(enum omap_plane plane, u32 paddr);
 void dispc_set_plane_ba1(enum omap_plane plane, u32 paddr);
 void dispc_set_plane_pos(enum omap_plane plane, u16 x, u16 y);
 void dispc_set_plane_size(enum omap_plane plane, u16 width, u16 height);
-void dispc_set_channel_out(enum omap_plane plane,
-		enum omap_channel channel_out);
 
 void dispc_enable_gamma_table(bool enable);
 int dispc_setup_plane(enum omap_plane plane,
diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
index 63674b0..a6a909a 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -1338,6 +1338,11 @@ static int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
 
 		oc = &dss_cache.overlay_cache[ovl->id];
 
+		if (ovl->manager_changed) {
+			ovl->manager_changed = false;
+			ovl->info_dirty  = true;
+		}
+
 		if (!overlay_enabled(ovl)) {
 			if (oc->enabled) {
 				oc->enabled = false;
diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
index c84380c..ab44403 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -516,6 +516,7 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
 	}
 
 	ovl->manager = mgr;
+	ovl->manager_changed = true;
 
 	/* 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
@@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
 	 * 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);
 
 	return 0;
 }
 
 static int omap_dss_unset_manager(struct omap_overlay *ovl)
 {
-	int r;
-
 	if (!ovl->manager) {
 		DSSERR("failed to detach overlay: manager not set\n");
 		return -EINVAL;
@@ -548,11 +546,8 @@ static int omap_dss_unset_manager(struct omap_overlay *ovl)
 		return -EINVAL;
 	}
 
-	r = ovl->wait_for_go(ovl);
-	if (r)
-		return r;
-
 	ovl->manager = NULL;
+	ovl->manager_changed = true;
 
 	return 0;
 }
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 9301805..b965f5a 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -326,6 +326,7 @@ struct omap_overlay {
 	struct omap_overlay_manager *manager;
 	struct omap_overlay_info info;
 
+	bool manager_changed;
 	/* if true, info has been changed, but not applied() yet */
 	bool info_dirty;
 
-- 
1.7.4.1

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Archit Taneja]

On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> Currently when changing the manager of an overlay, set_manager() directly
> calls dispc to set the overlay's destination.
>
> Change this to be more in line with other overlay configurations, and
> this will also remove the need to have dispc clocks enabled when calling
> set_manager().
>
> A new field is added to overlay struct, "manager_changed". This is
> similar to "display_changed" field in manager struct, and is used to
> inform apply that the manager has changed and thus write to the
> registers is needed.

I was wondering if it would be better to create an overlay_info member 
called 'channel_out' rather than having 'manager_enabled' at a higher 
level? This way, we won't need to do some of the things below(I have 
pointed them out):

>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
>   drivers/video/omap2/dss/dispc.c   |    4 +++-
>   drivers/video/omap2/dss/dss.h     |    2 --
>   drivers/video/omap2/dss/manager.c |    5 +++++
>   drivers/video/omap2/dss/overlay.c |    9 ++-------
>   include/video/omapdss.h           |    1 +
>   5 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 9d9fbeb..003227c 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -841,7 +841,7 @@ static void _dispc_set_color_mode(enum omap_plane plane,
>   	REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), m, 4, 1);
>   }
>
> -void dispc_set_channel_out(enum omap_plane plane,
> +static void dispc_set_channel_out(enum omap_plane plane,
>   		enum omap_channel channel)
>   {
>   	int shift;
> @@ -1860,6 +1860,8 @@ int dispc_setup_plane(enum omap_plane plane,
>   	_dispc_set_pre_mult_alpha(plane, pre_mult_alpha);
>   	_dispc_setup_global_alpha(plane, global_alpha);
>
> +	dispc_set_channel_out(plane, channel);
> +
>   	return 0;
>   }
>
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index adeff04..ff7ac35 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -399,8 +399,6 @@ void dispc_set_plane_ba0(enum omap_plane plane, u32 paddr);
>   void dispc_set_plane_ba1(enum omap_plane plane, u32 paddr);
>   void dispc_set_plane_pos(enum omap_plane plane, u16 x, u16 y);
>   void dispc_set_plane_size(enum omap_plane plane, u16 width, u16 height);
> -void dispc_set_channel_out(enum omap_plane plane,
> -		enum omap_channel channel_out);
>
>   void dispc_enable_gamma_table(bool enable);
>   int dispc_setup_plane(enum omap_plane plane,
> diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
> index 63674b0..a6a909a 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -1338,6 +1338,11 @@ static int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
>
>   		oc =&dss_cache.overlay_cache[ovl->id];
>
> +		if (ovl->manager_changed) {
> +			ovl->manager_changed = false;
> +			ovl->info_dirty  = true;
> +		}
> +

We won't need to do this if we created channel_out as an overlay_info 
member. The info will get dirty automatically.

>   		if (!overlay_enabled(ovl)) {
>   			if (oc->enabled) {
>   				oc->enabled = false;
> diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
> index c84380c..ab44403 100644
> --- a/drivers/video/omap2/dss/overlay.c
> +++ b/drivers/video/omap2/dss/overlay.c
> @@ -516,6 +516,7 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
>   	}
>
>   	ovl->manager = mgr;
> +	ovl->manager_changed = true;
>
>   	/* 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
> @@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
>   	 * 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);

We would need to do a get_overlay_info/set_overlay_info here, like it is 
done for other overlay sysfs attributes.

>
>   	return 0;
>   }
>
>   static int omap_dss_unset_manager(struct omap_overlay *ovl)
>   {
> -	int r;
> -
>   	if (!ovl->manager) {
>   		DSSERR("failed to detach overlay: manager not set\n");
>   		return -EINVAL;
> @@ -548,11 +546,8 @@ static int omap_dss_unset_manager(struct omap_overlay *ovl)
>   		return -EINVAL;
>   	}
>
> -	r = ovl->wait_for_go(ovl);
> -	if (r)
> -		return r;
> -
>   	ovl->manager = NULL;
> +	ovl->manager_changed = true;
>
>   	return 0;
>   }
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 9301805..b965f5a 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -326,6 +326,7 @@ struct omap_overlay {
>   	struct omap_overlay_manager *manager;
>   	struct omap_overlay_info info;
>
> +	bool manager_changed;
>   	/* if true, info has been changed, but not applied() yet */
>   	bool info_dirty;
>

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Archit Taneja]

On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> Currently when changing the manager of an overlay, set_manager() directly
> calls dispc to set the overlay's destination.
>
> Change this to be more in line with other overlay configurations, and
> this will also remove the need to have dispc clocks enabled when calling
> set_manager().
>
> A new field is added to overlay struct, "manager_changed". This is
> similar to "display_changed" field in manager struct, and is used to
> inform apply that the manager has changed and thus write to the
> registers is needed.

I was wondering if it would be better to create an overlay_info member 
called 'channel_out' rather than having 'manager_enabled' at a higher 
level? This way, we won't need to do some of the things below(I have 
pointed them out):

>
> Signed-off-by: Tomi Valkeinen<tomi.valkeinen@ti.com>
> ---
>   drivers/video/omap2/dss/dispc.c   |    4 +++-
>   drivers/video/omap2/dss/dss.h     |    2 --
>   drivers/video/omap2/dss/manager.c |    5 +++++
>   drivers/video/omap2/dss/overlay.c |    9 ++-------
>   include/video/omapdss.h           |    1 +
>   5 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 9d9fbeb..003227c 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -841,7 +841,7 @@ static void _dispc_set_color_mode(enum omap_plane plane,
>   	REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), m, 4, 1);
>   }
>
> -void dispc_set_channel_out(enum omap_plane plane,
> +static void dispc_set_channel_out(enum omap_plane plane,
>   		enum omap_channel channel)
>   {
>   	int shift;
> @@ -1860,6 +1860,8 @@ int dispc_setup_plane(enum omap_plane plane,
>   	_dispc_set_pre_mult_alpha(plane, pre_mult_alpha);
>   	_dispc_setup_global_alpha(plane, global_alpha);
>
> +	dispc_set_channel_out(plane, channel);
> +
>   	return 0;
>   }
>
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index adeff04..ff7ac35 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -399,8 +399,6 @@ void dispc_set_plane_ba0(enum omap_plane plane, u32 paddr);
>   void dispc_set_plane_ba1(enum omap_plane plane, u32 paddr);
>   void dispc_set_plane_pos(enum omap_plane plane, u16 x, u16 y);
>   void dispc_set_plane_size(enum omap_plane plane, u16 width, u16 height);
> -void dispc_set_channel_out(enum omap_plane plane,
> -		enum omap_channel channel_out);
>
>   void dispc_enable_gamma_table(bool enable);
>   int dispc_setup_plane(enum omap_plane plane,
> diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
> index 63674b0..a6a909a 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -1338,6 +1338,11 @@ static int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
>
>   		oc =&dss_cache.overlay_cache[ovl->id];
>
> +		if (ovl->manager_changed) {
> +			ovl->manager_changed = false;
> +			ovl->info_dirty  = true;
> +		}
> +

We won't need to do this if we created channel_out as an overlay_info 
member. The info will get dirty automatically.

>   		if (!overlay_enabled(ovl)) {
>   			if (oc->enabled) {
>   				oc->enabled = false;
> diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
> index c84380c..ab44403 100644
> --- a/drivers/video/omap2/dss/overlay.c
> +++ b/drivers/video/omap2/dss/overlay.c
> @@ -516,6 +516,7 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
>   	}
>
>   	ovl->manager = mgr;
> +	ovl->manager_changed = true;
>
>   	/* 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
> @@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,
>   	 * 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);

We would need to do a get_overlay_info/set_overlay_info here, like it is 
done for other overlay sysfs attributes.

>
>   	return 0;
>   }
>
>   static int omap_dss_unset_manager(struct omap_overlay *ovl)
>   {
> -	int r;
> -
>   	if (!ovl->manager) {
>   		DSSERR("failed to detach overlay: manager not set\n");
>   		return -EINVAL;
> @@ -548,11 +546,8 @@ static int omap_dss_unset_manager(struct omap_overlay *ovl)
>   		return -EINVAL;
>   	}
>
> -	r = ovl->wait_for_go(ovl);
> -	if (r)
> -		return r;
> -
>   	ovl->manager = NULL;
> +	ovl->manager_changed = true;
>
>   	return 0;
>   }
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 9301805..b965f5a 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -326,6 +326,7 @@ struct omap_overlay {
>   	struct omap_overlay_manager *manager;
>   	struct omap_overlay_info info;
>
> +	bool manager_changed;
>   	/* if true, info has been changed, but not applied() yet */
>   	bool info_dirty;
>

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Tomi Valkeinen]

On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> > Currently when changing the manager of an overlay, set_manager()
> directly
> > calls dispc to set the overlay's destination.
> >
> > Change this to be more in line with other overlay configurations,
> and
> > this will also remove the need to have dispc clocks enabled when
> calling
> > set_manager().
> >
> > A new field is added to overlay struct, "manager_changed". This is
> > similar to "display_changed" field in manager struct, and is used to
> > inform apply that the manager has changed and thus write to the
> > registers is needed.
> 
> I was wondering if it would be better to create an overlay_info
> member 
> called 'channel_out' rather than having 'manager_enabled' at a higher 
> level? This way, we won't need to do some of the things below(I have 
> pointed them out): 

The overlay_info is written by the users of the DSS. So if we had
channel_out there, we'd need to remove the set/get_manager() functions.
I made those functions in the first place as I felt changing the manager
is a bit bigger operation than the normal overlay attributes. Changing
the manager does effect both the old and the new managers. While I don't
think we currently do anything related to that, I believe it would be
needed for optimizations like FIFO merge.

It could perhaps be possible to change this so that the overlay_info has
the channel_out parameter, but that would be a bit bigger change, and
would needs lots of testing. So I feel this is a safer change, and it
fixes a problem we had with DRM.

 Tomi

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Tomi Valkeinen]

On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
> > Currently when changing the manager of an overlay, set_manager()
> directly
> > calls dispc to set the overlay's destination.
> >
> > Change this to be more in line with other overlay configurations,
> and
> > this will also remove the need to have dispc clocks enabled when
> calling
> > set_manager().
> >
> > A new field is added to overlay struct, "manager_changed". This is
> > similar to "display_changed" field in manager struct, and is used to
> > inform apply that the manager has changed and thus write to the
> > registers is needed.
> 
> I was wondering if it would be better to create an overlay_info
> member 
> called 'channel_out' rather than having 'manager_enabled' at a higher 
> level? This way, we won't need to do some of the things below(I have 
> pointed them out): 

The overlay_info is written by the users of the DSS. So if we had
channel_out there, we'd need to remove the set/get_manager() functions.
I made those functions in the first place as I felt changing the manager
is a bit bigger operation than the normal overlay attributes. Changing
the manager does effect both the old and the new managers. While I don't
think we currently do anything related to that, I believe it would be
needed for optimizations like FIFO merge.

It could perhaps be possible to change this so that the overlay_info has
the channel_out parameter, but that would be a bit bigger change, and
would needs lots of testing. So I feel this is a safer change, and it
fixes a problem we had with DRM.

 Tomi

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Archit Taneja]

On Friday 02 September 2011 12:55 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
>> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
>>> Currently when changing the manager of an overlay, set_manager()
>> directly
>>> calls dispc to set the overlay's destination.
>>>
>>> Change this to be more in line with other overlay configurations,
>> and
>>> this will also remove the need to have dispc clocks enabled when
>> calling
>>> set_manager().
>>>
>>> A new field is added to overlay struct, "manager_changed". This is
>>> similar to "display_changed" field in manager struct, and is used to
>>> inform apply that the manager has changed and thus write to the
>>> registers is needed.
>>
>> I was wondering if it would be better to create an overlay_info
>> member
>> called 'channel_out' rather than having 'manager_enabled' at a higher
>> level? This way, we won't need to do some of the things below(I have
>> pointed them out):
>
> The overlay_info is written by the users of the DSS. So if we had
> channel_out there, we'd need to remove the set/get_manager() functions.
> I made those functions in the first place as I felt changing the manager
> is a bit bigger operation than the normal overlay attributes. Changing
> the manager does effect both the old and the new managers. While I don't
> think we currently do anything related to that, I believe it would be
> needed for optimizations like FIFO merge.

Right, I forgot users of DSS2 will also get the opportunity to change 
channel_out, and we would need to do extra stuff in that case.

>
> It could perhaps be possible to change this so that the overlay_info has
> the channel_out parameter, but that would be a bit bigger change, and
> would needs lots of testing. So I feel this is a safer change, and it
> fixes a problem we had with DRM.

Okay, we could think about this later then.

Archit

>
>   Tomi
>
>

Re: [PATCH 3/4] OMAP: DSS2: Handle manager change in apply

[Archit Taneja]

On Friday 02 September 2011 12:55 PM, Valkeinen, Tomi wrote:
> On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
>> On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
>>> Currently when changing the manager of an overlay, set_manager()
>> directly
>>> calls dispc to set the overlay's destination.
>>>
>>> Change this to be more in line with other overlay configurations,
>> and
>>> this will also remove the need to have dispc clocks enabled when
>> calling
>>> set_manager().
>>>
>>> A new field is added to overlay struct, "manager_changed". This is
>>> similar to "display_changed" field in manager struct, and is used to
>>> inform apply that the manager has changed and thus write to the
>>> registers is needed.
>>
>> I was wondering if it would be better to create an overlay_info
>> member
>> called 'channel_out' rather than having 'manager_enabled' at a higher
>> level? This way, we won't need to do some of the things below(I have
>> pointed them out):
>
> The overlay_info is written by the users of the DSS. So if we had
> channel_out there, we'd need to remove the set/get_manager() functions.
> I made those functions in the first place as I felt changing the manager
> is a bit bigger operation than the normal overlay attributes. Changing
> the manager does effect both the old and the new managers. While I don't
> think we currently do anything related to that, I believe it would be
> needed for optimizations like FIFO merge.

Right, I forgot users of DSS2 will also get the opportunity to change 
channel_out, and we would need to do extra stuff in that case.

>
> It could perhaps be possible to change this so that the overlay_info has
> the channel_out parameter, but that would be a bit bigger change, and
> would needs lots of testing. So I feel this is a safer change, and it
> fixes a problem we had with DRM.

Okay, we could think about this later then.

Archit

>
>   Tomi
>
>

[PATCH 4/4] OMAP: DSS2: Remove "EXPERIMENTAL" from Kconfig

[Tomi Valkeinen]

DSS driver has not been "experimental" for many years now, so perhaps
it's time to remove the text from Kconfig titles.

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

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 0d12524..7be7c06 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -1,5 +1,5 @@
 menuconfig OMAP2_DSS
-        tristate "OMAP2+ Display Subsystem support (EXPERIMENTAL)"
+        tristate "OMAP2+ Display Subsystem support"
         depends on ARCH_OMAP2PLUS
         help
 	  OMAP2+ Display Subsystem support.
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index aa33386..83d3fe7 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -1,5 +1,5 @@
 menuconfig FB_OMAP2
-        tristate "OMAP2+ frame buffer support (EXPERIMENTAL)"
+        tristate "OMAP2+ frame buffer support"
         depends on FB && OMAP2_DSS
 
 	select OMAP2_VRAM
-- 
1.7.4.1

[PATCH 4/4] OMAP: DSS2: Remove "EXPERIMENTAL" from Kconfig

[Tomi Valkeinen]

DSS driver has not been "experimental" for many years now, so perhaps
it's time to remove the text from Kconfig titles.

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

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 0d12524..7be7c06 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -1,5 +1,5 @@
 menuconfig OMAP2_DSS
-        tristate "OMAP2+ Display Subsystem support (EXPERIMENTAL)"
+        tristate "OMAP2+ Display Subsystem support"
         depends on ARCH_OMAP2PLUS
         help
 	  OMAP2+ Display Subsystem support.
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index aa33386..83d3fe7 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -1,5 +1,5 @@
 menuconfig FB_OMAP2
-        tristate "OMAP2+ frame buffer support (EXPERIMENTAL)"
+        tristate "OMAP2+ frame buffer support"
         depends on FB && OMAP2_DSS
 
 	select OMAP2_VRAM
-- 
1.7.4.1