Re: [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data
On Wed, 2012-08-08 at 11:27 +0530, Archit Taneja wrote: I am a bit unclear about resolution when it comes to command mode panels. Right, it's a bit confusing. And I'm not 100% sure how to manage the rotation. For command mode panels, we can perform rotation at the panel side. That is, the panel refreshes itself by fetching pixels from it's buffer in a rotated way. Is that right? Yes. Well, actually I think the panel stores the pixels in rotated manner when it receives them from OMAP, but it's practically the same. One thing to realize is that this kind of rotation is a bit limited: because there's only one buffer, OMAP will write pixels to the buffers at the same time as the panel shows them. When rotating, this leads to tearing. If the panel has double buffer, that solves the problem, but I haven't seen such panels. Another option is to update the panel in two parts, like N9 does, but that's timing sensitive and a bit tricky. If the original resolution is 864x480, and we set rotation at panel side to make the rotation 480x864, the DISPC manager size should also be configured at 480x864 right? Yep. When we use the panel rotation, from OMAP's point of view the panel resolution has changed. We seem to be setting the manager timings only once when DSI is enabled. After that, setting rotation doesn't impact manager size. Hmm, previously the mgr size was set before each update. I wonder if that code has been dropped, probably because we removed the support for partial updates at one point. Without partial updates, the size stays the same, except obviously with rotation. I think I just forgot about rotation at that time. I am asking this to understand if we need to keep resolution as a separate parameter than timings. That is, timings represents the initial width and height of the panel, and resolution represents the current width and height of the panel. I'm not sure. I think that OMAP doesn't really need to know about the initial resolution. It doesn't really matter from OMAP's point of view. I think I originally kept timings and resolution separately, and the idea was that timings represent the panel's timings, i.e. how it updates the screen from its own memory. And resolution represents the usable resolution, from OMAP's point of view. While I haven't seen such a cmd mode panel, there could be a command sent to the panel to configure its timings. For this we need real timings, not the rotated resolution. However, even in that case the DISPC doesn't need to know about those timings, they would be handled by the panel driver (which could, perhaps, reconfigure the DSI bus speed to match the new timings). So I think that inside omapdss, we don't need separate timings and resolution for DSI cmd mode panels. Tomi signature.asc Description: This is a digitally signed message part
Re: [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data
On Wednesday 08 August 2012 12:40 PM, Tomi Valkeinen wrote: On Wed, 2012-08-08 at 11:59 +0530, Archit Taneja wrote: I tried out rotation on Taal, and it only works for 180 degrees(and 0 of course), 90 and 270 result in no output. I'll add a dss_mgr_set_timings() in omap_dsi_update, that should sort of fix it, but someone would need to reconfigure the connected overlays too before trying out an update. Right, but that's something omapdss/panel cannot do, it must be done by the user. The same problem is there with changing, say, DPI mode also. Btw, can you separate smaller cleanups/fixes to another patch series, to make this series even slightly smaller? I think at least the first patches in this series are quite separate, and the rotation fix is also. Right, I'll do that. Archit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
^^^
DSI
expected to call omapdss_dsi_set_timings() to set these timings before the
panel
is enabled.
Signed-off-by: Archit Taneja arc...@ti.comd
---
drivers/video/omap2/displays/panel-taal.c |2 ++
drivers/video/omap2/dss/dsi.c | 27 ++-
include/video/omapdss.h |2 ++
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 3f5acc7..4775580 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1060,6 +1060,8 @@ static int taal_power_on(struct omap_dss_device *dssdev)
goto err0;
};
+ omapdss_dsi_set_timings(dssdev, td-panel_config-timings);
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(dssdev-dev, failed to enable DSI\n);
Video timings for command mode panel are meaningless. If we need to pass
the resolution of the panel, perhaps we should have a separate function
for that.
However, with a quick glance at dsi.c, we don't even use the
dssdev-panel.timings for cmd mode panel. But we do use
dssdev-get_resolution() in a few places. Those calls could be replaced
by storing the panel size in dsi.c, given with omapdss_dsi_set_size() or
such. We could use the timings field in dsi.c to store them, though.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [RFC 08/17] OMAPDSS: DSI: Maintain own copy of timings in driver data
On Tuesday 07 August 2012 07:37 PM, Tomi Valkeinen wrote:
On Wed, 2012-08-01 at 16:01 +0530, Archit Taneja wrote:
The DSI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and DSI blocks accordingly. This makes the DSI interface
driver dependent on the omap_dss_device struct.
Make the DPI driver data maintain it's own timings field. The panel driver is
^^^
DSI
expected to call omapdss_dsi_set_timings() to set these timings before the panel
is enabled.
Signed-off-by: Archit Taneja arc...@ti.comd
---
drivers/video/omap2/displays/panel-taal.c |2 ++
drivers/video/omap2/dss/dsi.c | 27 ++-
include/video/omapdss.h |2 ++
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 3f5acc7..4775580 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1060,6 +1060,8 @@ static int taal_power_on(struct omap_dss_device *dssdev)
goto err0;
};
+ omapdss_dsi_set_timings(dssdev, td-panel_config-timings);
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(dssdev-dev, failed to enable DSI\n);
Video timings for command mode panel are meaningless. If we need to pass
the resolution of the panel, perhaps we should have a separate function
for that.
However, with a quick glance at dsi.c, we don't even use the
dssdev-panel.timings for cmd mode panel. But we do use
dssdev-get_resolution() in a few places. Those calls could be replaced
by storing the panel size in dsi.c, given with omapdss_dsi_set_size() or
such. We could use the timings field in dsi.c to store them, though.
I am a bit unclear about resolution when it comes to command mode panels.
For command mode panels, we can perform rotation at the panel side. That
is, the panel refreshes itself by fetching pixels from it's buffer in a
rotated way. Is that right?
If the original resolution is 864x480, and we set rotation at panel side
to make the rotation 480x864, the DISPC manager size should also be
configured at 480x864 right?
We seem to be setting the manager timings only once when DSI is enabled.
After that, setting rotation doesn't impact manager size.
I am asking this to understand if we need to keep resolution as a
separate parameter than timings. That is, timings represents the initial
width and height of the panel, and resolution represents the current
width and height of the panel.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
