On Mon, Aug 22, 2011 at 4:27 PM, Tomi Valkeinen [off-list ref] 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