From: Tomi Valkeinen <hidden> Date: 2011-08-22 08:27:13
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 <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-08-22 08:27:14
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 <redacted>
---
drivers/video/omap2/dss/dpi.c | 4 +++-
drivers/video/omap2/dss/dsi.c | 3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-08-22 08:27:15
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 <redacted>
---
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(-)
@@ -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*theoverlayisfirstdisabled,thenmovedtotv,andenabled,we
@@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,*UserspaceworkaroundforthisistoupdatetheLCDafterdisabling*theoverlay,butbeforemovingtheoverlaytoTV.*/-dispc_set_channel_out(ovl->id,mgr->id);return0;}staticintomap_dss_unset_manager(structomap_overlay*ovl){-intr;-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)-returnr;-ovl->manager=NULL;+ovl->manager_changed=true;return0;}
@@ -326,6 +326,7 @@ struct omap_overlay {structomap_overlay_manager*manager;structomap_overlay_infoinfo;+boolmanager_changed;/* if true, info has been changed, but not applied() yet */boolinfo_dirty;
From: Tomi Valkeinen <hidden> Date: 2011-08-22 08:27:16
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 <redacted>
---
drivers/video/omap2/dss/Kconfig | 2 +-
drivers/video/omap2/omapfb/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
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
@@ -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
@@ -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
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):
@@ -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*theoverlayisfirstdisabled,thenmovedtotv,andenabled,we
@@ -529,15 +530,12 @@ static int omap_dss_set_manager(struct omap_overlay *ovl,*UserspaceworkaroundforthisistoupdatetheLCDafterdisabling*theoverlay,butbeforemovingtheoverlaytoTV.*/-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.
quoted hunk
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; }
@@ -326,6 +326,7 @@ struct omap_overlay {structomap_overlay_manager*manager;structomap_overlay_infoinfo;+boolmanager_changed;/* if true, info has been changed, but not applied() yet */boolinfo_dirty;
From: Tomi Valkeinen <hidden> Date: 2011-09-02 07:25:22
On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
quoted
Currently when changing the manager of an overlay, set_manager()
directly
quoted
calls dispc to set the overlay's destination.
Change this to be more in line with other overlay configurations,
and
quoted
this will also remove the need to have dispc clocks enabled when
calling
quoted
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
On Friday 02 September 2011 12:55 PM, Valkeinen, Tomi wrote:
On Fri, 2011-09-02 at 12:20 +0530, Archit Taneja wrote:
quoted
On Monday 22 August 2011 01:57 PM, Valkeinen, Tomi wrote:
quoted
Currently when changing the manager of an overlay, set_manager()
directly
quoted
calls dispc to set the overlay's destination.
Change this to be more in line with other overlay configurations,
and
quoted
this will also remove the need to have dispc clocks enabled when
calling
quoted
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