* [PATCH 07/17] OMAPDSS: DISPC: Configure newly added omap_video_timing fields
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes,
Hsync and Vsync signals(with respect to pixel clock) are newly added parameters
in omap_video_timings.
Program these in dispc_mgr_set_lcd_timings. These will be configured when the
manager's timings are set via dss_mgr_set_timings().
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 43 ++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d974be9..184d37b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2620,9 +2620,16 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
}
static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int hsw,
- int hfp, int hbp, int vsw, int vfp, int vbp)
+ int hfp, int hbp, int vsw, int vfp, int vbp,
+ enum omap_dss_signal_level vsync_level,
+ enum omap_dss_signal_level hsync_level,
+ enum omap_dss_signal_level pclk_edge,
+ enum omap_dss_signal_level de_level,
+ enum omap_dss_signal_edge hsync_vsync_edge)
+
{
- u32 timing_h, timing_v;
+ u32 timing_h, timing_v, l;
+ bool onoff, rf;
if (cpu_is_omap24xx() || omap_rev() < OMAP3430_REV_ES3_0) {
timing_h = FLD_VAL(hsw-1, 5, 0) | FLD_VAL(hfp-1, 15, 8) |
@@ -2640,6 +2647,32 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int hsw,
dispc_write_reg(DISPC_TIMING_H(channel), timing_h);
dispc_write_reg(DISPC_TIMING_V(channel), timing_v);
+
+ switch (hsync_vsync_edge) {
+ case OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES:
+ onoff = false;
+ rf = false;
+ break;
+ case OMAPDSS_DRIVE_SIG_FALLING_EDGE:
+ onoff = true;
+ rf = false;
+ break;
+ case OMAPDSS_DRIVE_SIG_RISING_EDGE:
+ onoff = true;
+ rf = true;
+ break;
+ default:
+ BUG();
+ };
+
+ l = dispc_read_reg(DISPC_POL_FREQ(channel));
+ l |= FLD_VAL(onoff, 17, 17);
+ l |= FLD_VAL(rf, 16, 16);
+ l |= FLD_VAL(de_level, 15, 15);
+ l |= FLD_VAL(pclk_edge, 14, 14);
+ l |= FLD_VAL(hsync_level, 13, 13);
+ l |= FLD_VAL(vsync_level, 12, 12);
+ dispc_write_reg(DISPC_POL_FREQ(channel), l);
}
/* change name to mode? */
@@ -2659,7 +2692,8 @@ void dispc_mgr_set_timings(enum omap_channel channel,
if (dispc_mgr_is_lcd(channel)) {
_dispc_mgr_set_lcd_timings(channel, t.hsw, t.hfp, t.hbp, t.vsw,
- t.vfp, t.vbp);
+ t.vfp, t.vbp, t.vsync_level, t.hsync_level,
+ t.pclk_edge, t.de_level, t.hsync_vsync_edge);
xtot = t.x_res + t.hfp + t.hsw + t.hbp;
ytot = t.y_res + t.vfp + t.vsw + t.vbp;
@@ -2670,6 +2704,9 @@ void dispc_mgr_set_timings(enum omap_channel channel,
DSSDBG("pck %u\n", timings->pixel_clock);
DSSDBG("hsw %d hfp %d hbp %d vsw %d vfp %d vbp %d\n",
t.hsw, t.hfp, t.hbp, t.vsw, t.vfp, t.vbp);
+ DSSDBG("vsync_level %d hsync_level %d pclk_edge %d de_level %d hsync_vsync_edge %d\n",
+ t.vsync_level, t.hsync_level, t.pclk_edge, t.de_level,
+ t.hsync_vsync_edge);
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 08/17] OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq()
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
All these fields have been moved to omap_video_timings struct, and are now
programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
are applied via dss_mgr_set_timings().
Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 29 -----------------------------
drivers/video/omap2/dss/dpi.c | 2 --
drivers/video/omap2/dss/dss.h | 2 --
drivers/video/omap2/dss/sdi.c | 2 --
4 files changed, 35 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 184d37b..9b22563 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3113,35 +3113,6 @@ static void dispc_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-static void _dispc_mgr_set_pol_freq(enum omap_channel channel, bool onoff,
- bool rf, bool ieo, bool ipc, bool ihs, bool ivs)
-{
- u32 l = 0;
-
- DSSDBG("onoff %d rf %d ieo %d ipc %d ihs %d ivs %d\n",
- onoff, rf, ieo, ipc, ihs, ivs);
-
- l |= FLD_VAL(onoff, 17, 17);
- l |= FLD_VAL(rf, 16, 16);
- l |= FLD_VAL(ieo, 15, 15);
- l |= FLD_VAL(ipc, 14, 14);
- l |= FLD_VAL(ihs, 13, 13);
- l |= FLD_VAL(ivs, 12, 12);
-
- dispc_write_reg(DISPC_POL_FREQ(channel), l);
-}
-
-void dispc_mgr_set_pol_freq(enum omap_channel channel,
- enum omap_panel_config config)
-{
- _dispc_mgr_set_pol_freq(channel, (config & OMAP_DSS_LCD_ONOFF) != 0,
- (config & OMAP_DSS_LCD_RF) != 0,
- (config & OMAP_DSS_LCD_IEO) != 0,
- (config & OMAP_DSS_LCD_IPC) != 0,
- (config & OMAP_DSS_LCD_IHS) != 0,
- (config & OMAP_DSS_LCD_IVS) != 0);
-}
-
/* with fck as input clock rate, find dispc dividers that produce req_pck */
void dispc_find_clk_divs(unsigned long req_pck, unsigned long fck,
struct dispc_clock_info *cinfo)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index d8cc440..046a6fb 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -148,8 +148,6 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
unsigned long pck;
int r = 0;
- dispc_mgr_set_pol_freq(dssdev->manager->id, dssdev->panel.config);
-
if (dpi_use_dsi_pll(dssdev))
r = dpi_set_dsi_clk(dssdev, t->pixel_clock * 1000, &fck,
&lck_div, &pck_div);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d64f894..3d23a23 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -414,8 +414,6 @@ void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines);
void dispc_mgr_set_lcd_type_tft(enum omap_channel channel);
void dispc_mgr_set_timings(enum omap_channel channel,
struct omap_video_timings *timings);
-void dispc_mgr_set_pol_freq(enum omap_channel channel,
- enum omap_panel_config config);
unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
unsigned long dispc_core_clk_rate(void);
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 9330410..264efd5 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -82,8 +82,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
dssdev->panel.timings.hsync_vsync_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
- dispc_mgr_set_pol_freq(dssdev->manager->id, dssdev->panel.config);
-
r = dss_calc_clock_div(t->pixel_clock * 1000, &dss_cinfo, &dispc_cinfo);
if (r)
goto err_calc_clock_div;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/17] OMAPFB: Map the newly added omap_video_timings fields with fb sync flags
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding sync flags in fb_var_screeninfo and
fb_videomode.
Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync
flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT.
When converting fb mode to omap_video_timings, the fields which don't have an
equivalent parameter in fb are set to the default values.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 1dd8f2c..7c99725 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -733,6 +733,10 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
var->lower_margin = timings.vfp;
var->hsync_len = timings.hsw;
var->vsync_len = timings.vsw;
+ var->sync |= timings.hsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
+ FB_SYNC_HOR_HIGH_ACT : 0;
+ var->sync |= timings.vsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
+ FB_SYNC_VERT_HIGH_ACT : 0;
} else {
var->pixclock = 0;
var->left_margin = 0;
@@ -741,11 +745,11 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
var->lower_margin = 0;
var->hsync_len = 0;
var->vsync_len = 0;
+ var->sync = 0;
}
/* TODO: get these from panel->config */
var->vmode = FB_VMODE_NONINTERLACED;
- var->sync = 0;
return 0;
}
@@ -2053,6 +2057,15 @@ static int omapfb_mode_to_timings(const char *mode_str,
timings->vsw = var->vsync_len;
timings->x_res = var->xres;
timings->y_res = var->yres;
+ timings->hsync_level = var->sync & FB_SYNC_HOR_HIGH_ACT ?
+ OMAPDSS_SIG_ACTIVE_HIGH :
+ OMAPDSS_SIG_ACTIVE_LOW;
+ timings->vsync_level = var->sync & FB_SYNC_VERT_HIGH_ACT ?
+ OMAPDSS_SIG_ACTIVE_HIGH :
+ OMAPDSS_SIG_ACTIVE_LOW;
+ timings->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
+ timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
+ timings->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
switch (var->bits_per_pixel) {
case 16:
@@ -2187,6 +2200,15 @@ static void fb_videomode_to_omap_timings(struct fb_videomode *m,
t->vsw = m->vsync_len;
t->vfp = m->lower_margin;
t->vbp = m->upper_margin;
+ t->hsync_level = m->sync & FB_SYNC_HOR_HIGH_ACT ?
+ OMAPDSS_SIG_ACTIVE_HIGH :
+ OMAPDSS_SIG_ACTIVE_LOW;
+ t->vsync_level = m->sync & FB_SYNC_VERT_HIGH_ACT ?
+ OMAPDSS_SIG_ACTIVE_HIGH :
+ OMAPDSS_SIG_ACTIVE_LOW;
+ t->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
+ t->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
+ t->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
}
static int omapfb_find_best_mode(struct omap_dss_device *display,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/17] OMAPDRM: Map the newly added omap_video_timings fields with drm mode flags
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding drm mode flags in drm_display_mode.
Out of the new fields, hsync_level and vsync_level can be mapped to the drm mode
flags DRM_MODE_FLAG_PHSYNC, DRM_MODE_FLAG_NHSYNC, DRM_MODE_FLAG_PVSYNC and
DRM_MODE_FLAG_NVSYNC
When converting drm mode to omap_video_timings, the fields which don't have an
equivalent parameter in drm mode are set to the default values.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/staging/omapdrm/omap_connector.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c
index 5e2856c..157f6ec 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -48,13 +48,11 @@ static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode,
mode->vsync_end = mode->vsync_start + timings->vsw;
mode->vtotal = mode->vsync_end + timings->vbp;
- /* note: whether or not it is interlaced, +/- h/vsync, etc,
- * which should be set in the mode flags, is not exposed in
- * the omap_video_timings struct.. but hdmi driver tracks
- * those separately so all we have to have to set the mode
- * is the way to recover these timings values, and the
- * omap_dss_driver would do the rest.
- */
+ mode->flags |= timings->hsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
+ DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+
+ mode->flags |= timings->vsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
+ DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
}
static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
@@ -71,6 +69,16 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
timings->vfp = mode->vsync_start - mode->vdisplay;
timings->vsw = mode->vsync_end - mode->vsync_start;
timings->vbp = mode->vtotal - mode->vsync_end;
+
+ timings->hsync_level = mode->flags & DRM_MODE_FLAG_PHSYNC ?
+ OMAPDSS_SIG_ACTIVE_HIGH : OMAPDSS_SIG_ACTIVE_LOW;
+
+ timings->vsync_level = mode->flags & DRM_MODE_FLAG_PVSYNC ?
+ OMAPDSS_SIG_ACTIVE_HIGH : OMAPDSS_SIG_ACTIVE_LOW;
+
+ timings->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
+ timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
+ timings->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
}
static void omap_connector_dpms(struct drm_connector *connector, int mode)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 11/17] OMAPDSS: Remove omap_panel_config enum from omap_dss_device
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.
Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/displays/panel-acx565akm.c | 1 -
drivers/video/omap2/displays/panel-generic-dpi.c | 29 --------------------
.../omap2/displays/panel-lgphilips-lb035q02.c | 1 -
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 2 --
drivers/video/omap2/displays/panel-picodlp.c | 2 --
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 1 -
.../video/omap2/displays/panel-tpo-td043mtea1.c | 2 --
drivers/video/omap2/dss/hdmi_panel.c | 2 --
drivers/video/omap2/dss/sdi.c | 2 --
include/video/omapdss.h | 11 --------
10 files changed, 53 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel-acx565akm.c
index 067c8a8..c6a2d51 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -501,7 +501,6 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
struct backlight_properties props;
dev_dbg(&dssdev->dev, "%s\n", __func__);
- dssdev->panel.config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
/* FIXME AC bias ? */
dssdev->panel.timings = acx_panel_timings;
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c
index e5bba0b..96e3d2b 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -40,8 +40,6 @@
struct panel_config {
struct omap_video_timings timings;
- enum omap_panel_config config;
-
int power_on_delay;
int power_off_delay;
@@ -73,8 +71,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IEO,
.power_on_delay = 50,
.power_off_delay = 100,
.name = "sharp_lq",
@@ -99,7 +95,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.power_on_delay = 50,
.power_off_delay = 100,
.name = "sharp_ls",
@@ -126,9 +121,6 @@ static struct panel_config generic_dpi_panels[] = {
.pclk_edge = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_vsync_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IPC |
- OMAP_DSS_LCD_ONOFF,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "toppoly_tdo35s",
@@ -153,7 +145,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "samsung_lte430wq_f0c",
@@ -178,7 +169,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "seiko_70wvw1tz3",
@@ -204,8 +194,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.de_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IEO,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "powertip_ph480272t",
@@ -230,7 +218,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "innolux_at070tn83",
@@ -255,7 +242,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.name = "nec_nl2432dr22-11b",
},
@@ -297,8 +283,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
-
.name = "apollon",
},
/* FocalTech ETM070003DH6 */
@@ -320,7 +304,6 @@ static struct panel_config generic_dpi_panels[] = {
.vsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS,
.name = "focaltech_etm070003dh6",
},
@@ -344,8 +327,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.pclk_edge = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IPC,
.power_on_delay = 0,
.power_off_delay = 0,
.name = "microtips_umsh_8173md",
@@ -390,9 +371,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.de_level = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IEO,
-
.name = "innolux_at080tn52",
},
@@ -451,8 +429,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.pclk_edge = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IPC,
.name = "primeview_pd050vl1",
},
@@ -476,8 +452,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.pclk_edge = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IPC,
.name = "primeview_pm070wl4",
},
@@ -501,8 +475,6 @@ static struct panel_config generic_dpi_panels[] = {
.hsync_level = OMAPDSS_SIG_ACTIVE_LOW,
.pclk_edge = OMAPDSS_SIG_ACTIVE_LOW,
},
- .config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IPC,
.name = "primeview_pd104slf",
},
};
@@ -592,7 +564,6 @@ static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
if (!panel_config)
return -EINVAL;
- dssdev->panel.config = panel_config->config;
dssdev->panel.timings = panel_config->timings;
drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
diff --git a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
index d9565c4e..d8cfc83 100644
--- a/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/omap2/displays/panel-lgphilips-lb035q02.c
@@ -85,7 +85,6 @@ static int lb035q02_panel_probe(struct omap_dss_device *dssdev)
struct lb035q02_data *ld;
int r;
- dssdev->panel.config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
dssdev->panel.timings = lb035q02_timings;
ld = kzalloc(sizeof(*ld), GFP_KERNEL);
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
index ff863d1..bccd451 100644
--- a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -120,8 +120,6 @@ static int nec_8048_panel_probe(struct omap_dss_device *dssdev)
struct backlight_properties props;
int r;
- dssdev->panel.config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_RF | OMAP_DSS_LCD_ONOFF;
dssdev->panel.timings = nec_8048_panel_timings;
necd = kzalloc(sizeof(*necd), GFP_KERNEL);
diff --git a/drivers/video/omap2/displays/panel-picodlp.c b/drivers/video/omap2/displays/panel-picodlp.c
index 95fda38..29705cf 100644
--- a/drivers/video/omap2/displays/panel-picodlp.c
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -418,8 +418,6 @@ static int picodlp_panel_probe(struct omap_dss_device *dssdev)
struct i2c_client *picodlp_i2c_client;
int r = 0, picodlp_adapter_id;
- dssdev->panel.config = OMAP_DSS_LCD_ONOFF | OMAP_DSS_LCD_IHS |
- OMAP_DSS_LCD_IVS;
dssdev->panel.timings = pico_ls_timings;
picod = kzalloc(sizeof(struct picodlp_data), GFP_KERNEL);
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index 9854f35..6d54a1a 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -89,7 +89,6 @@ static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
struct sharp_data *sd;
int r;
- dssdev->panel.config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
dssdev->panel.timings = sharp_ls_timings;
sd = kzalloc(sizeof(*sd), GFP_KERNEL);
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index 446cef6..c5a0868 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -409,8 +409,6 @@ static int tpo_td043_probe(struct omap_dss_device *dssdev)
return -ENODEV;
}
- dssdev->panel.config = OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IVS |
- OMAP_DSS_LCD_IPC;
dssdev->panel.timings = tpo_td043_timings;
dssdev->ctrl.pixel_size = 24;
diff --git a/drivers/video/omap2/dss/hdmi_panel.c b/drivers/video/omap2/dss/hdmi_panel.c
index aa0f3c2..a991840 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -43,8 +43,6 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
{
DSSDBG("ENTER hdmi_panel_probe\n");
- dssdev->panel.config = OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
-
dssdev->panel.timings = (struct omap_video_timings)
{ 640, 480, 25175, 96, 16, 48, 2, 11, 31,
OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 264efd5..2fd8540 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -78,8 +78,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
sdi_basic_init(dssdev);
/* 15.5.9.1.2 */
- dssdev->panel.config |= OMAP_DSS_LCD_RF | OMAP_DSS_LCD_ONOFF;
-
dssdev->panel.timings.hsync_vsync_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
r = dss_calc_clock_div(t->pixel_clock * 1000, &dss_cinfo, &dispc_cinfo);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 1d1a2be..5de5c9c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -116,15 +116,6 @@ enum omap_rfbi_te_mode {
OMAP_DSS_RFBI_TE_MODE_2 = 2,
};
-enum omap_panel_config {
- OMAP_DSS_LCD_IVS = 1<<0,
- OMAP_DSS_LCD_IHS = 1<<1,
- OMAP_DSS_LCD_IPC = 1<<2,
- OMAP_DSS_LCD_IEO = 1<<3,
- OMAP_DSS_LCD_RF = 1<<4,
- OMAP_DSS_LCD_ONOFF = 1<<5,
-};
-
enum omap_dss_signal_level {
OMAPDSS_SIG_ACTIVE_HIGH,
OMAPDSS_SIG_ACTIVE_LOW,
@@ -598,8 +589,6 @@ struct omap_dss_device {
/* Unit: line clocks */
int acb; /* ac-bias pin frequency */
- enum omap_panel_config config;
-
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
enum omap_dss_dsi_mode dsi_mode;
struct omap_dss_dsi_videomode_data dsi_vm_data;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 12/17] OMAPDSS: Add interlace parameter to omap_video_timings
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.
It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dispc.c | 6 +-----
drivers/video/omap2/dss/venc.c | 4 ++++
include/video/omapdss.h | 3 +++
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9b22563..92b6428 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2710,11 +2710,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
- enum dss_hdmi_venc_clk_source_select source;
-
- source = dss_get_hdmi_venc_clk_source();
-
- if (source = DSS_VENC_TV_CLK)
+ if (t.interlace = true)
t.y_res /= 2;
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 3552305..494f763 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -272,6 +272,8 @@ const struct omap_video_timings omap_dss_pal_timings = {
.vsw = 5,
.vfp = 5,
.vbp = 41,
+
+ .interlace = true,
};
EXPORT_SYMBOL(omap_dss_pal_timings);
@@ -285,6 +287,8 @@ const struct omap_video_timings omap_dss_ntsc_timings = {
.vsw = 6,
.vfp = 6,
.vbp = 31,
+
+ .interlace = true,
};
EXPORT_SYMBOL(omap_dss_ntsc_timings);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 5de5c9c..1498bb3 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -390,6 +390,9 @@ struct omap_video_timings {
* default value: OMAPDSS_SIG_ACTIVE_HIGH
*/
enum omap_dss_signal_level hsync_level;
+
+ /* Interlaced or Progressive timings */
+ bool interlace;
/*
* Pixel clock edge to drive LCD data
* default value: OMAPDSS_SIG_ACTIVE_HIGH
--
1.7.9.5
^ permalink raw reply related
* [PATCH 13/17] OMAPDSS: DISPC/APPLY: Use interlace info in manager timings for dispc_ovl_setup()
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Currently the interlace parameter passed to dispc_ovl_setup() is configured by
checking the display type, and set to true if the display type is VENC.
This isn't correct as other panels can take interlaced content too. The
omap_video_timings struct in manager's private data contains the info whether
the panel is in interlaced mode or not.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/apply.c | 6 ++----
drivers/video/omap2/dss/dispc.c | 4 ++--
drivers/video/omap2/dss/dss.h | 3 +--
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ab22cc2..3ce7a3e 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -537,7 +537,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
{
struct ovl_priv_data *op = get_ovl_priv(ovl);
struct omap_overlay_info *oi;
- bool ilace, replication;
+ bool replication;
struct mgr_priv_data *mp;
int r;
@@ -552,9 +552,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
replication = dss_use_replication(ovl->manager->device, oi->color_mode);
- ilace = ovl->manager->device->type = OMAP_DISPLAY_TYPE_VENC;
-
- r = dispc_ovl_setup(ovl->id, oi, ilace, replication, &mp->timings);
+ r = dispc_ovl_setup(ovl->id, oi, replication, &mp->timings);
if (r) {
/*
* We can't do much here, as this function can be called from
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 92b6428..c0b82c6 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2086,8 +2086,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication,
- const struct omap_video_timings *mgr_timings)
+ bool replication, const struct omap_video_timings *mgr_timings)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
bool five_taps = true;
@@ -2103,6 +2102,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
u16 out_width, out_height;
enum omap_channel channel;
int x_predecim = 1, y_predecim = 1;
+ bool ilace = mgr_timings->interlace;
channel = dispc_ovl_get_channel_out(plane);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 3d23a23..20151d5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -394,8 +394,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane,
u32 *fifo_low, u32 *fifo_high, bool use_fifomerge,
bool manual_update);
int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
- bool ilace, bool replication,
- const struct omap_video_timings *mgr_timings);
+ bool replication, const struct omap_video_timings *mgr_timings);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/17] OMAPFB: Map interlace field in omap_video_timings with fb vmode flags
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Use the interlace field in omap_video_timings to configure/retrieve
corresponding fb mode flags in fb_var_screeninfo and fb_videomode.
The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and
FB_VMODE_NONINTERLACED.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 7c99725..434aa9a 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -737,6 +737,8 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
FB_SYNC_HOR_HIGH_ACT : 0;
var->sync |= timings.vsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
FB_SYNC_VERT_HIGH_ACT : 0;
+ var->vmode = timings.interlace ?
+ FB_VMODE_INTERLACED : FB_VMODE_NONINTERLACED;
} else {
var->pixclock = 0;
var->left_margin = 0;
@@ -746,11 +748,9 @@ int check_fb_var(struct fb_info *fbi, struct fb_var_screeninfo *var)
var->hsync_len = 0;
var->vsync_len = 0;
var->sync = 0;
+ var->vmode = FB_VMODE_NONINTERLACED;
}
- /* TODO: get these from panel->config */
- var->vmode = FB_VMODE_NONINTERLACED;
-
return 0;
}
@@ -2063,6 +2063,7 @@ static int omapfb_mode_to_timings(const char *mode_str,
timings->vsync_level = var->sync & FB_SYNC_VERT_HIGH_ACT ?
OMAPDSS_SIG_ACTIVE_HIGH :
OMAPDSS_SIG_ACTIVE_LOW;
+ timings->interlace = var->vmode & FB_VMODE_INTERLACED;
timings->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
timings->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
@@ -2206,6 +2207,7 @@ static void fb_videomode_to_omap_timings(struct fb_videomode *m,
t->vsync_level = m->sync & FB_SYNC_VERT_HIGH_ACT ?
OMAPDSS_SIG_ACTIVE_HIGH :
OMAPDSS_SIG_ACTIVE_LOW;
+ t->interlace = m->vmode & FB_VMODE_INTERLACED;
t->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
t->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
t->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 15/17] OMAPDRM: Map interlace field in omap_video_timings with drm mode flags
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
Use the interlace field in omap_video_timings to configure/retrieve
corresponding flags in drm_display_mode.
The interlace field maps with the drm mode flag DRM_MODE_FLAG_INTERLACE.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/staging/omapdrm/omap_connector.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c
index 157f6ec..05dda41 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -53,6 +53,8 @@ static inline void copy_timings_omap_to_drm(struct drm_display_mode *mode,
mode->flags |= timings->vsync_level = OMAPDSS_SIG_ACTIVE_HIGH ?
DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+
+ mode->flags |= timings->interlace ? DRM_MODE_FLAG_INTERLACE : 0;
}
static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
@@ -76,6 +78,9 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings,
timings->vsync_level = mode->flags & DRM_MODE_FLAG_PVSYNC ?
OMAPDSS_SIG_ACTIVE_HIGH : OMAPDSS_SIG_ACTIVE_LOW;
+ timings->interlace = mode->flags & DRM_MODE_FLAG_INTERLACE ?
+ true : false;
+
timings->pclk_edge = OMAPDSS_SIG_ACTIVE_HIGH;
timings->de_level = OMAPDSS_SIG_ACTIVE_HIGH;
timings->hsync_vsync_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 16/17] OMAPDSS: HDMI: Remove custom hdmi_video_timings struct
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja, Mythri P K
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings,
omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync
polarities and interlaced/progressive information.
Remove hdmi_video_timings, and use omap_video_timings instead.
Cc: Mythri P K <mythripk@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 241 ++++++++++++++++++++++++-----
drivers/video/omap2/dss/ti_hdmi.h | 19 +--
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 8 +-
3 files changed, 213 insertions(+), 55 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 34910bc..46fb1be 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -78,43 +78,214 @@ static struct {
*/
static const struct hdmi_config cea_timings[] = {
-{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
-{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
-{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
-{ {1920, 540, 74250, 44, 88, 148, 5, 2, 15, 1, 1, 1}, {5, HDMI_HDMI} },
-{ {1440, 240, 27027, 124, 38, 114, 3, 4, 15, 0, 0, 1}, {6, HDMI_HDMI} },
-{ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36, 1, 1, 0}, {16, HDMI_HDMI} },
-{ {720, 576, 27000, 64, 12, 68, 5, 5, 39, 0, 0, 0}, {17, HDMI_HDMI} },
-{ {1280, 720, 74250, 40, 440, 220, 5, 5, 20, 1, 1, 0}, {19, HDMI_HDMI} },
-{ {1920, 540, 74250, 44, 528, 148, 5, 2, 15, 1, 1, 1}, {20, HDMI_HDMI} },
-{ {1440, 288, 27000, 126, 24, 138, 3, 2, 19, 0, 0, 1}, {21, HDMI_HDMI} },
-{ {1440, 576, 54000, 128, 24, 136, 5, 5, 39, 0, 0, 0}, {29, HDMI_HDMI} },
-{ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36, 1, 1, 0}, {31, HDMI_HDMI} },
-{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
-{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
-{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+ {
+ { 640, 480, 25200, 96, 16, 48, 2, 10, 33,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 1, HDMI_HDMI },
+ },
+ {
+ { 720, 480, 27027, 62, 16, 60, 6, 9, 30,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 2, HDMI_HDMI },
+ },
+ {
+ { 1280, 720, 74250, 40, 110, 220, 5, 5, 20,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 4, HDMI_HDMI },
+ },
+ {
+ { 1920, 540, 74250, 44, 88, 148, 5, 2, 15,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ true, },
+ { 5, HDMI_HDMI },
+ },
+ {
+ { 1440, 240, 27027, 124, 38, 114, 3, 4, 15,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ true, },
+ { 6, HDMI_HDMI },
+ },
+ {
+ { 1920, 1080, 148500, 44, 88, 148, 5, 4, 36,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 16, HDMI_HDMI },
+ },
+ {
+ { 720, 576, 27000, 64, 12, 68, 5, 5, 39,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 17, HDMI_HDMI },
+ },
+ {
+ { 1280, 720, 74250, 40, 440, 220, 5, 5, 20,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 19, HDMI_HDMI },
+ },
+ {
+ { 1920, 540, 74250, 44, 528, 148, 5, 2, 15,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ true, },
+ { 20, HDMI_HDMI },
+ },
+ {
+ { 1440, 288, 27000, 126, 24, 138, 3, 2, 19,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ true, },
+ { 21, HDMI_HDMI },
+ },
+ {
+ { 1440, 576, 54000, 128, 24, 136, 5, 5, 39,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 29, HDMI_HDMI },
+ },
+ {
+ { 1920, 1080, 148500, 44, 528, 148, 5, 4, 36,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 31, HDMI_HDMI },
+ },
+ {
+ { 1920, 1080, 74250, 44, 638, 148, 5, 4, 36,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 32, HDMI_HDMI },
+ },
+ {
+ { 2880, 480, 108108, 248, 64, 240, 6, 9, 30,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 35, HDMI_HDMI },
+ },
+ {
+ { 2880, 576, 108000, 256, 48, 272, 5, 5, 39,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 37, HDMI_HDMI },
+ },
};
+
static const struct hdmi_config vesa_timings[] = {
/* VESA From Here */
-{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
-{ {800, 600, 40000, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
-{ {848, 480, 33750, 112, 16, 112, 8 , 6, 23, 1, 1, 0}, {0xE, HDMI_DVI} },
-{ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20, 1, 0, 0}, {0x17, HDMI_DVI} },
-{ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22, 1, 0, 0}, {0x1C, HDMI_DVI} },
-{ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18, 1, 1, 0}, {0x27, HDMI_DVI} },
-{ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36, 1, 1, 0}, {0x20, HDMI_DVI} },
-{ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38, 1, 1, 0}, {0x23, HDMI_DVI} },
-{ {1024, 768, 65000, 136, 24, 160, 6, 3, 29, 0, 0, 0}, {0x10, HDMI_DVI} },
-{ {1400, 1050, 121750, 144, 88, 232, 4, 3, 32, 1, 0, 0}, {0x2A, HDMI_DVI} },
-{ {1440, 900, 106500, 152, 80, 232, 6, 3, 25, 1, 0, 0}, {0x2F, HDMI_DVI} },
-{ {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30, 1, 0, 0}, {0x3A, HDMI_DVI} },
-{ {1366, 768, 85500, 143, 70, 213, 3, 3, 24, 1, 1, 0}, {0x51, HDMI_DVI} },
-{ {1920, 1080, 148500, 44, 148, 80, 5, 4, 36, 1, 1, 0}, {0x52, HDMI_DVI} },
-{ {1280, 768, 68250, 32, 48, 80, 7, 3, 12, 0, 1, 0}, {0x16, HDMI_DVI} },
-{ {1400, 1050, 101000, 32, 48, 80, 4, 3, 23, 0, 1, 0}, {0x29, HDMI_DVI} },
-{ {1680, 1050, 119000, 32, 48, 80, 6, 3, 21, 0, 1, 0}, {0x39, HDMI_DVI} },
-{ {1280, 800, 79500, 32, 48, 80, 6, 3, 14, 0, 1, 0}, {0x1B, HDMI_DVI} },
-{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {0x55, HDMI_DVI} }
+ {
+ { 640, 480, 25175, 96, 16, 48, 2, 11, 31,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 4, HDMI_DVI },
+ },
+ {
+ { 800, 600, 40000, 128, 40, 88, 4, 1, 23,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 9, HDMI_DVI },
+ },
+ {
+ { 848, 480, 33750, 112, 16, 112, 8, 6, 23,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0xE, HDMI_DVI },
+ },
+ {
+ { 1280, 768, 79500, 128, 64, 192, 7, 3, 20,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x17, HDMI_DVI },
+ },
+ {
+ { 1280, 800, 83500, 128, 72, 200, 6, 3, 22,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x1C, HDMI_DVI },
+ },
+ {
+ { 1360, 768, 85500, 112, 64, 256, 6, 3, 18,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x27, HDMI_DVI },
+ },
+ {
+ { 1280, 960, 108000, 112, 96, 312, 3, 1, 36,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x20, HDMI_DVI },
+ },
+ {
+ { 1280, 1024, 108000, 112, 48, 248, 3, 1, 38,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x23, HDMI_DVI },
+ },
+ {
+ { 1024, 768, 65000, 136, 24, 160, 6, 3, 29,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x10, HDMI_DVI },
+ },
+ {
+ { 1400, 1050, 121750, 144, 88, 232, 4, 3, 32,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x2A, HDMI_DVI },
+ },
+ {
+ { 1440, 900, 106500, 152, 80, 232, 6, 3, 25,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x2F, HDMI_DVI },
+ },
+ {
+ { 1680, 1050, 146250, 176 , 104, 280, 6, 3, 30,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_LOW,
+ false, },
+ { 0x3A, HDMI_DVI },
+ },
+ {
+ { 1366, 768, 85500, 143, 70, 213, 3, 3, 24,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x51, HDMI_DVI },
+ },
+ {
+ { 1920, 1080, 148500, 44, 148, 80, 5, 4, 36,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x52, HDMI_DVI },
+ },
+ {
+ { 1280, 768, 68250, 32, 48, 80, 7, 3, 12,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x16, HDMI_DVI },
+ },
+ {
+ { 1400, 1050, 101000, 32, 48, 80, 4, 3, 23,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x29, HDMI_DVI },
+ },
+ {
+ { 1680, 1050, 119000, 32, 48, 80, 6, 3, 21,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x39, HDMI_DVI },
+ },
+ {
+ { 1280, 800, 79500, 32, 48, 80, 6, 3, 14,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x1B, HDMI_DVI },
+ },
+ {
+ { 1280, 720, 74250, 40, 110, 220, 5, 5, 20,
+ OMAPDSS_SIG_ACTIVE_HIGH, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x55, HDMI_DVI },
+ },
};
static int hdmi_runtime_get(void)
@@ -179,7 +350,7 @@ static const struct hdmi_config *hdmi_get_timings(void)
}
static bool hdmi_timings_compare(struct omap_video_timings *timing1,
- const struct hdmi_video_timings *timing2)
+ const struct omap_video_timings *timing2)
{
int timing1_vsync, timing1_hsync, timing2_vsync, timing2_hsync;
diff --git a/drivers/video/omap2/dss/ti_hdmi.h b/drivers/video/omap2/dss/ti_hdmi.h
index e734cb4..913c4ca 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -42,30 +42,13 @@ enum hdmi_clk_refsel {
HDMI_REFSEL_SYSCLK = 3
};
-/* HDMI timing structure */
-struct hdmi_video_timings {
- u16 x_res;
- u16 y_res;
- /* Unit: KHz */
- u32 pixel_clock;
- u16 hsw;
- u16 hfp;
- u16 hbp;
- u16 vsw;
- u16 vfp;
- u16 vbp;
- bool vsync_pol;
- bool hsync_pol;
- bool interlace;
-};
-
struct hdmi_cm {
int code;
int mode;
};
struct hdmi_config {
- struct hdmi_video_timings timings;
+ struct omap_video_timings timings;
struct hdmi_cm cm;
};
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4dae1b2..92944ac 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -747,11 +747,15 @@ static void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
{
u32 r;
+ bool vsync_pol, hsync_pol;
pr_debug("Enter hdmi_wp_video_config_interface\n");
+ vsync_pol = ip_data->cfg.timings.vsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
+ hsync_pol = ip_data->cfg.timings.hsync_level = OMAPDSS_SIG_ACTIVE_HIGH;
+
r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
- r = FLD_MOD(r, ip_data->cfg.timings.vsync_pol, 7, 7);
- r = FLD_MOD(r, ip_data->cfg.timings.hsync_pol, 6, 6);
+ r = FLD_MOD(r, vsync_pol, 7, 7);
+ r = FLD_MOD(r, hsync_pol, 6, 6);
r = FLD_MOD(r, ip_data->cfg.timings.interlace, 3, 3);
r = FLD_MOD(r, 1, 1, 0); /* HDMI_TIMING_MASTER_24BIT */
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 17/17] OMAPDSS: DSI: Remove redundant fields in omap_dss_dsi_videomode_data
From: Archit Taneja @ 2012-06-26 9:48 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: rob, linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1340703414-1915-1-git-send-email-archit@ti.com>
The struct omap_dss_dsi_videomode_data holds polaritiy/logic level information
of the DISPC video port signals DE, HSYNC and VSYNC. This information already
exists in the omap_video_timings struct.
Use the fields in omap_video_timings to program VP_DE_POL, VP_HSYNC_POL and
VP_VSYNC_POL in DSI_CTRL. Remove the redundant fields in
omap_dss_dsi_videomode_data.
Signed-off-by: Archit Taneja <archit@ti.com>
---
drivers/video/omap2/dss/dsi.c | 11 ++++++++---
include/video/omapdss.h | 3 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 061bf53..3844430 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3628,13 +3628,18 @@ static void dsi_config_vp_num_line_buffers(struct omap_dss_device *dssdev)
static void dsi_config_vp_sync_events(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- int de_pol = dssdev->panel.dsi_vm_data.vp_de_pol;
- int hsync_pol = dssdev->panel.dsi_vm_data.vp_hsync_pol;
- int vsync_pol = dssdev->panel.dsi_vm_data.vp_vsync_pol;
+ int de_pol, hsync_pol, vsync_pol;
+ int de_level = dssdev->panel.timings.de_level;
+ int hsync_level = dssdev->panel.timings.hsync_level;
+ int vsync_level = dssdev->panel.timings.vsync_level;
bool vsync_end = dssdev->panel.dsi_vm_data.vp_vsync_end;
bool hsync_end = dssdev->panel.dsi_vm_data.vp_hsync_end;
u32 r;
+ de_pol = de_level = OMAPDSS_SIG_ACTIVE_HIGH ? 1 : 0;
+ hsync_pol = hsync_level = OMAPDSS_SIG_ACTIVE_HIGH ? 1 : 0;
+ vsync_pol = vsync_level = OMAPDSS_SIG_ACTIVE_HIGH ? 1 : 0;
+
r = dsi_read_reg(dsidev, DSI_CTRL);
r = FLD_MOD(r, de_pol, 9, 9); /* VP_DE_POL */
r = FLD_MOD(r, hsync_pol, 10, 10); /* VP_HSYNC_POL */
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 1498bb3..f627ad9 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -255,9 +255,6 @@ struct omap_dss_dsi_videomode_data {
int hfp_blanking_mode;
/* Video port sync events */
- int vp_de_pol;
- int vp_hsync_pol;
- int vp_vsync_pol;
bool vp_vsync_end;
bool vp_hsync_end;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Jassi Brar @ 2012-06-26 10:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <1340701660.24530.17.camel@deskari>
On 26 June 2012 14:37, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
>
>> Something non-omapdss in vanilla breaks suspend/resume.
>
> I was able to reproduce (probably) the same issue with omap3 overo. Does
> this looks familiar:
>
> [ 2267.140197] ------------[ cut here ]------------
> [ 2267.145172] WARNING: at drivers/video/omap2/dss/dispc.c:377 dispc_runtime_get+0x60/0x7c [omapdss]
> ()
> [ 2267.154846] Modules linked in: omapfb panel_generic_dpi omapdss cfbimgblt cfbfillrect cfbcopyarea
> [last unloaded: omapdss]
> [ 2267.166595] [<c001b61c>] (unwind_backtrace+0x0/0xf0) from [<c0040238>] (warn_slowpath_common+0x4c
> /0x64)
> [ 2267.176605] [<c0040238>] (warn_slowpath_common+0x4c/0x64) from [<c004026c>] (warn_slowpath_null+0
> x1c/0x24)
> [ 2267.186859] [<c004026c>] (warn_slowpath_null+0x1c/0x24) from [<bf0d7918>] (dispc_runtime_get+0x60
> /0x7c [omapdss])
> [ 2267.197814] [<bf0d7918>] (dispc_runtime_get+0x60/0x7c [omapdss]) from [<bf0e3148>] (omapdss_dpi_d
> isplay_enable+0x48/0x230 [omapdss])
> [ 2267.210479] [<bf0e3148>] (omapdss_dpi_display_enable+0x48/0x230 [omapdss]) from [<bf110034>] (gen
> eric_dpi_panel_check_timings+0x30/0x7c [panel_generic_dpi])
> [ 2267.225311] [<bf110034>] (generic_dpi_panel_check_timings+0x30/0x7c [panel_generic_dpi]) from [<b
> f11008c>] (generic_dpi_panel_resume+0xc/0x1c [panel_generic_dpi])
> [ 2267.240722] [<bf11008c>] (generic_dpi_panel_resume+0xc/0x1c [panel_generic_dpi]) from [<bf0de654>
> ] (dss_resume_device+0x28/0x40 [omapdss])
> [ 2267.253936] [<bf0de654>] (dss_resume_device+0x28/0x40 [omapdss]) from [<c02bfb94>] (bus_for_each_
> dev+0x50/0x7c)
> [ 2267.264678] [<c02bfb94>] (bus_for_each_dev+0x50/0x7c) from [<c02c287c>] (platform_pm_resume+0x2c/
> 0x50)
> [ 2267.274566] [<c02c287c>] (platform_pm_resume+0x2c/0x50) from [<c02c6da8>] (dpm_run_callback.clone
> .7+0x30/0xb0)
> [ 2267.285186] [<c02c6da8>] (dpm_run_callback.clone.7+0x30/0xb0) from [<c02c7b2c>] (device_resume+0x
> c8/0x188)
> [ 2267.295471] [<c02c7b2c>] (device_resume+0xc8/0x188) from [<c02c7f54>] (dpm_resume+0xfc/0x21c)
> [ 2267.304534] [<c02c7f54>] (dpm_resume+0xfc/0x21c) from [<c02c8208>] (dpm_resume_end+0xc/0x18)
> [ 2267.313507] [<c02c8208>] (dpm_resume_end+0xc/0x18) from [<c007fbcc>] (suspend_devices_and_enter+0
> x15c/0x2d0)
> [ 2267.323913] [<c007fbcc>] (suspend_devices_and_enter+0x15c/0x2d0) from [<c007fecc>] (pm_suspend+0x
> 18c/0x208)
> [ 2267.334259] [<c007fecc>] (pm_suspend+0x18c/0x208) from [<c007f170>] (state_store+0x120/0x134)
> [ 2267.343292] [<c007f170>] (state_store+0x120/0x134) from [<c0262850>] (kobj_attr_store+0x14/0x20)
> [ 2267.352661] [<c0262850>] (kobj_attr_store+0x14/0x20) from [<c0169b6c>] (sysfs_write_file+0x100/0x
> 184)
> [ 2267.362457] [<c0169b6c>] (sysfs_write_file+0x100/0x184) from [<c0109008>] (vfs_write+0xb4/0x148)
> [ 2267.371795] [<c0109008>] (vfs_write+0xb4/0x148) from [<c0109290>] (sys_write+0x40/0x70)
> [ 2267.380310] [<c0109290>] (sys_write+0x40/0x70) from [<c0013d60>] (ret_fast_syscall+0x0/0x3c)
> [ 2267.389282] ---[ end trace 54fe7eea726ac84d ]---
> [ 2267.394592] dpm_run_callback(): platform_pm_resume+0x0/0x50 returns -13
> [ 2267.401641] PM: Device omapdss failed to resume: error -13
>
Seems similar, but I only tested OMAP4 HDMI.
thanks.
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Tomi Valkeinen @ 2012-06-26 12:03 UTC (permalink / raw)
To: Jassi Brar; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <CAJe_Zhd-LA67yO-H_7pacB_T8_z6=Zf47QuoHSJcsXDZ9S+byw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2902 bytes --]
On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> Seems similar, but I only tested OMAP4 HDMI.
Would something like this one below work for you? It fixes the issues on
my overo board.
Instead of using omapdss device's suspend/resume callbacks, this one
uses PM notifier calls which happen before suspend and after resume.
I still think the suspend handling is wrong, omapdss shouldn't be
enabling and disabling panel devices like that, but this one should
remove the biggest issues with the current suspend method.
Tomi
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5066eee..c35a248 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -32,6 +32,7 @@
#include <linux/io.h>
#include <linux/device.h>
#include <linux/regulator/consumer.h>
+#include <linux/suspend.h>
#include <video/omapdss.h>
@@ -201,6 +202,30 @@ int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
#endif /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
+static int omap_dss_pm_notif(struct notifier_block *b, unsigned long v, void *d)
+{
+ DSSDBG("pm notif %lu\n", v);
+
+ switch (v)
+ {
+ case PM_SUSPEND_PREPARE:
+ DSSDBG("suspending displays\n");
+ return dss_suspend_all_devices();
+
+ case PM_POST_SUSPEND:
+ DSSDBG("resuming displays\n");
+ return dss_resume_all_devices();
+
+ default:
+ return 0;
+ }
+}
+
+static struct notifier_block omap_dss_pm_notif_block =
+{
+ .notifier_call = omap_dss_pm_notif,
+};
+
static int __init omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
@@ -224,6 +249,8 @@ static int __init omap_dss_probe(struct platform_device *pdev)
else if (pdata->default_device)
core.default_display_name = pdata->default_device->name;
+ register_pm_notifier(&omap_dss_pm_notif_block);
+
return 0;
err_debugfs:
@@ -233,6 +260,8 @@ err_debugfs:
static int omap_dss_remove(struct platform_device *pdev)
{
+ unregister_pm_notifier(&omap_dss_pm_notif_block);
+
dss_uninitialize_debugfs();
dss_uninit_overlays(pdev);
@@ -247,25 +276,9 @@ static void omap_dss_shutdown(struct platform_device *pdev)
dss_disable_all_devices();
}
-static int omap_dss_suspend(struct platform_device *pdev, pm_message_t state)
-{
- DSSDBG("suspend %d\n", state.event);
-
- return dss_suspend_all_devices();
-}
-
-static int omap_dss_resume(struct platform_device *pdev)
-{
- DSSDBG("resume\n");
-
- return dss_resume_all_devices();
-}
-
static struct platform_driver omap_dss_driver = {
.remove = omap_dss_remove,
.shutdown = omap_dss_shutdown,
- .suspend = omap_dss_suspend,
- .resume = omap_dss_resume,
.driver = {
.name = "omapdss",
.owner = THIS_MODULE,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Grazvydas Ignotas @ 2012-06-26 13:02 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Tomi Valkeinen, jaswinder.singh, mythripk, linux-omap,
linux-fbdev, andy.green, n-dechesne, Rafael J. Wysocki, linux-pm
In-Reply-To: <4FE93FB9.3080705@ti.com>
CCing some PM people, maybe they can comment?
On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
>>
>> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
>> Are they supposed to handle the error values returned by runtime PM
>> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
>
> hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would
> be stubbed to return success and not failure. And the _pm_runtime_resume
> function indeed seems to return 1, which is not failure but just saying
> that your device is already active/enabled.
> The _pm_runtime_suspend and _pm_runtime_idle do return a -ENOSYS, which
> is something only returned when CONFIG_RUNTIME_PM=n, so if you really
> want to handle failing pm_runtime_put_sync cases, maybe you still can.
> But then, I don't know if there is anything you can do to recover from
> a failing pm_runtime_put_sync, except for warning the user maybe.
>
>> Both options sound a bit difficult to me... With the first one it's
>> difficult to see if there was an actual error and we should somehow
>> react to it, or is everything fine and we just shouldn't care about
>> runtime PM. The second one requires ifdefs in many places.
--
Gražvydas
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Alan Stern @ 2012-06-26 14:34 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Rajendra Nayak, Tomi Valkeinen, jaswinder.singh, mythripk,
linux-omap, linux-fbdev, andy.green, n-dechesne,
Rafael J. Wysocki, linux-pm
In-Reply-To: <CANOLnOP_z47QCB234y-BOWyRGHeO8u-pJct=Kq6+2XCig-tX=w@mail.gmail.com>
On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
> CCing some PM people, maybe they can comment?
>
> On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> >>
> >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
> >> Are they supposed to handle the error values returned by runtime PM
> >> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
> >
> > hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would
> > be stubbed to return success and not failure.
Not exactly. They are stubbed to indicate that the device cannot be
suspended, that it is always active.
Failure to suspend a device should not be regarded as particularly bad,
because it doesn't affect the device's functionality. That's true even
when CONFIG_RUNTIME_PM is enabled.
> And the _pm_runtime_resume
> > function indeed seems to return 1, which is not failure but just saying
> > that your device is already active/enabled.
> > The _pm_runtime_suspend and _pm_runtime_idle do return a -ENOSYS, which
> > is something only returned when CONFIG_RUNTIME_PM=n, so if you really
> > want to handle failing pm_runtime_put_sync cases, maybe you still can.
> > But then, I don't know if there is anything you can do to recover from
> > a failing pm_runtime_put_sync, except for warning the user maybe.
I don't see much point in warning the user that a device was unable to
go to low power.
Alan Stern
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Jassi Brar @ 2012-06-26 14:52 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <1340712213.24530.21.camel@deskari>
On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>
>> Seems similar, but I only tested OMAP4 HDMI.
>
> Would something like this one below work for you? It fixes the issues on
> my overo board.
>
I think this should work too (I will get to test it only tomorrow).
Though I don't think it'll fix stack spew when run without
CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the
xxx_runtime_put() as Alan noted?
-j
> Instead of using omapdss device's suspend/resume callbacks, this one
> uses PM notifier calls which happen before suspend and after resume.
>
> I still think the suspend handling is wrong, omapdss shouldn't be
> enabling and disabling panel devices like that, but this one should
> remove the biggest issues with the current suspend method.
>
> Tomi
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 5066eee..c35a248 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -32,6 +32,7 @@
> #include <linux/io.h>
> #include <linux/device.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/suspend.h>
>
> #include <video/omapdss.h>
>
> @@ -201,6 +202,30 @@ int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
> #endif /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
>
> /* PLATFORM DEVICE */
> +static int omap_dss_pm_notif(struct notifier_block *b, unsigned long v, void *d)
> +{
> + DSSDBG("pm notif %lu\n", v);
> +
> + switch (v)
> + {
> + case PM_SUSPEND_PREPARE:
> + DSSDBG("suspending displays\n");
> + return dss_suspend_all_devices();
> +
> + case PM_POST_SUSPEND:
> + DSSDBG("resuming displays\n");
> + return dss_resume_all_devices();
> +
> + default:
> + return 0;
> + }
> +}
> +
> +static struct notifier_block omap_dss_pm_notif_block > +{
> + .notifier_call = omap_dss_pm_notif,
> +};
> +
> static int __init omap_dss_probe(struct platform_device *pdev)
> {
> struct omap_dss_board_info *pdata = pdev->dev.platform_data;
> @@ -224,6 +249,8 @@ static int __init omap_dss_probe(struct platform_device *pdev)
> else if (pdata->default_device)
> core.default_display_name = pdata->default_device->name;
>
> + register_pm_notifier(&omap_dss_pm_notif_block);
> +
> return 0;
>
> err_debugfs:
> @@ -233,6 +260,8 @@ err_debugfs:
>
> static int omap_dss_remove(struct platform_device *pdev)
> {
> + unregister_pm_notifier(&omap_dss_pm_notif_block);
> +
> dss_uninitialize_debugfs();
>
> dss_uninit_overlays(pdev);
> @@ -247,25 +276,9 @@ static void omap_dss_shutdown(struct platform_device *pdev)
> dss_disable_all_devices();
> }
>
> -static int omap_dss_suspend(struct platform_device *pdev, pm_message_t state)
> -{
> - DSSDBG("suspend %d\n", state.event);
> -
> - return dss_suspend_all_devices();
> -}
> -
> -static int omap_dss_resume(struct platform_device *pdev)
> -{
> - DSSDBG("resume\n");
> -
> - return dss_resume_all_devices();
> -}
> -
> static struct platform_driver omap_dss_driver = {
> .remove = omap_dss_remove,
> .shutdown = omap_dss_shutdown,
> - .suspend = omap_dss_suspend,
> - .resume = omap_dss_resume,
> .driver = {
> .name = "omapdss",
> .owner = THIS_MODULE,
>
--
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Tomi Valkeinen @ 2012-06-26 15:01 UTC (permalink / raw)
To: Alan Stern
Cc: Grazvydas Ignotas, Rajendra Nayak, jaswinder.singh, mythripk,
linux-omap, linux-fbdev, andy.green, n-dechesne,
Rafael J. Wysocki, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.1206261031450.1636-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote:
> On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
>
> > CCing some PM people, maybe they can comment?
> >
> > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> > >>
> > >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
> > >> Are they supposed to handle the error values returned by runtime PM
> > >> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
> > >
> > > hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would
> > > be stubbed to return success and not failure.
>
> Not exactly. They are stubbed to indicate that the device cannot be
> suspended, that it is always active.
>
> Failure to suspend a device should not be regarded as particularly bad,
> because it doesn't affect the device's functionality. That's true even
> when CONFIG_RUNTIME_PM is enabled.
This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_runtime_get_sync()
will return 1, meaning the HW is already enabled, and using
pm_runtime_put_sync() will return -ENOSYS, meaning the hardware cannot
be suspended.
With CONFIG_RUNTIME_PM=y, it's a bit more complex. If I read the code
correctly, when I call pm_runtime_get_sync(), the usage counter is
always increased, even if the pm_runtime_resume() fails. So a get()
needs to be always matched with a put(), even if get() has returned an
error.
But if pm_runtime_get_sync() returns an error, it means the HW has not
been resumed successfully, and is not operational, so the code should
bail out somehow. So basically I'd use this kind of pattern everywhere I
use pm_runtime_get_sync():
---
r = pm_runtime_get_sync(dev);
if (r < 0) {
pm_runtime_put_sync(dev);
/* handle error */
return -ESOMETHING;
}
/* do the work */
pm_runtime_put_sync(dev);
---
Is this correct?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Tomi Valkeinen @ 2012-06-26 15:08 UTC (permalink / raw)
To: Jassi Brar; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <CAJe_ZhcxVAUuuMDZ8p1LVae4N2aZb_vFs_nRLfb7atJ2j6j=Sg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >
> >> Seems similar, but I only tested OMAP4 HDMI.
> >
> > Would something like this one below work for you? It fixes the issues on
> > my overo board.
> >
> I think this should work too (I will get to test it only tomorrow).
>
> Though I don't think it'll fix stack spew when run without
> CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the
> xxx_runtime_put() as Alan noted?
Yes, that's a different issue. I'll look at that also.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Alan Stern @ 2012-06-26 15:11 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Grazvydas Ignotas, Rajendra Nayak, jaswinder.singh, mythripk,
linux-omap, linux-fbdev, andy.green, n-dechesne,
Rafael J. Wysocki, linux-pm
In-Reply-To: <1340722875.24530.66.camel@deskari>
On Tue, 26 Jun 2012, Tomi Valkeinen wrote:
> > Failure to suspend a device should not be regarded as particularly bad,
> > because it doesn't affect the device's functionality. That's true even
> > when CONFIG_RUNTIME_PM is enabled.
>
> This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_runtime_get_sync()
> will return 1, meaning the HW is already enabled, and using
> pm_runtime_put_sync() will return -ENOSYS, meaning the hardware cannot
> be suspended.
>
> With CONFIG_RUNTIME_PM=y, it's a bit more complex. If I read the code
> correctly, when I call pm_runtime_get_sync(), the usage counter is
> always increased, even if the pm_runtime_resume() fails. So a get()
> needs to be always matched with a put(), even if get() has returned an
> error.
Right. Of course, it doesn't hurt to match a get() with a put() even
when CONFIG_RUNTIME_PM=n.
> But if pm_runtime_get_sync() returns an error, it means the HW has not
> been resumed successfully, and is not operational, so the code should
> bail out somehow. So basically I'd use this kind of pattern everywhere I
> use pm_runtime_get_sync():
>
> ---
>
> r = pm_runtime_get_sync(dev);
> if (r < 0) {
> pm_runtime_put_sync(dev);
Here you could just as well call pm_runtime_put_noidle(). Since the
device wasn't resumed, the put operation doesn't need to try to suspend
it.
> /* handle error */
> return -ESOMETHING;
> }
>
> /* do the work */
>
> pm_runtime_put_sync(dev);
>
> ---
>
> Is this correct?
Yep, you've got it.
Alan Stern
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Tomi Valkeinen @ 2012-06-26 15:11 UTC (permalink / raw)
To: Jassi Brar; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <CAJe_ZheMN_sqaANSMepmhDDp2a2sQAVPYD1-owBWpwwbxqAtHQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
> On 26 June 2012 20:38, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> >> On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >> >
> >> >> Seems similar, but I only tested OMAP4 HDMI.
> >> >
> >> > Would something like this one below work for you? It fixes the issues on
> >> > my overo board.
> >> >
> >> I think this should work too (I will get to test it only tomorrow).
> >>
> >> Though I don't think it'll fix stack spew when run without
> >> CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the
> >> xxx_runtime_put() as Alan noted?
> >
> > Yes, that's a different issue. I'll look at that also.
> >
> Well, my patch took care of that also. But I agree, that could be
> added separately as well.
Well, I don't agree that your patch is correct =). I don't think it's
right to skip runtime get and put when pm_runtime_enabled() returns
false.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Jassi Brar @ 2012-06-26 15:21 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <1340723296.24530.68.camel@deskari>
On 26 June 2012 20:38, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>> >
>> >> Seems similar, but I only tested OMAP4 HDMI.
>> >
>> > Would something like this one below work for you? It fixes the issues on
>> > my overo board.
>> >
>> I think this should work too (I will get to test it only tomorrow).
>>
>> Though I don't think it'll fix stack spew when run without
>> CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the
>> xxx_runtime_put() as Alan noted?
>
> Yes, that's a different issue. I'll look at that also.
>
Well, my patch took care of that also. But I agree, that could be
added separately as well.
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Jassi Brar @ 2012-06-26 17:13 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <1340723514.24530.70.camel@deskari>
On 26 June 2012 20:41, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
>> On 26 June 2012 20:38, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> >> On 26 June 2012 17:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> >> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>> >> >
>> >> >> Seems similar, but I only tested OMAP4 HDMI.
>> >> >
>> >> > Would something like this one below work for you? It fixes the issues on
>> >> > my overo board.
>> >> >
>> >> I think this should work too (I will get to test it only tomorrow).
>> >>
>> >> Though I don't think it'll fix stack spew when run without
>> >> CONFIG_PM_RUNTIME. Maybe we could simply remove the WARN_ON in the
>> >> xxx_runtime_put() as Alan noted?
>> >
>> > Yes, that's a different issue. I'll look at that also.
>> >
>> Well, my patch took care of that also. But I agree, that could be
>> added separately as well.
>
> Well, I don't agree that your patch is correct =). I don't think it's
> right to skip runtime get and put when pm_runtime_enabled() returns
> false.
>
While I think your patch is simpler and achieve the same, I also think
your fears about this patch are unfounded.
A quick snack for thought...
>
> But if pm_runtime_get_sync() returns an error, it means the HW has not
> been resumed successfully, and is not operational,
>
Not always. The HW could be in RPM_ACTIVE state while PM on it could
be disabled, if the returned error is -EACCESS. And
pm_runtime_enabled() only catches a potential -EACCESS.
BTW, I just tested your patch and it worked for me as well. But as
suspected, it doesn't help the stack spew of CONFIG_PM_RUNTIME:=n
So I understand, I only need to resend the other three patches ?
Thanks.
^ permalink raw reply
* Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
From: Tomi Valkeinen @ 2012-06-26 18:44 UTC (permalink / raw)
To: Jassi Brar; +Cc: mythripk, linux-omap, linux-fbdev, andy.green, n-dechesne
In-Reply-To: <CAJe_ZheXSquxOtOD9iPyQjZ-jxWKzVGZHYkjM=wC37qgMZeJug@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote:
> While I think your patch is simpler and achieve the same, I also think
> your fears about this patch are unfounded.
Perhaps. But I do get a bad feeling from your patch, and I don't like
when that happens =). What I fear with changes like you made is that
they'll hide problems that should be fixed in other ways.
And I think that was the case here also. I think we should not call
dispc_runtime_get() during suspend. If pm_runtime_get returns -EACCES,
we do have a possible problem, and we should not silently ignore it.
> A quick snack for thought...
> >
> > But if pm_runtime_get_sync() returns an error, it means the HW has not
> > been resumed successfully, and is not operational,
> >
> Not always. The HW could be in RPM_ACTIVE state while PM on it could
> be disabled, if the returned error is -EACCESS. And
> pm_runtime_enabled() only catches a potential -EACCESS.
True. But the HW could also be in disabled state. And that would lead to
a crash when accessing the registers.
It is not a fatal error if pm_runtime_get returns -EACCES, but we sure
shouldn't ignore it (or avoid it with pm_runtime_enabled()), but handle
it. In some rare cases it could be ok to get -EACCES, but that's a
special case, not standard.
> BTW, I just tested your patch and it worked for me as well. But as
> suspected, it doesn't help the stack spew of CONFIG_PM_RUNTIME:=n
>
> So I understand, I only need to resend the other three patches ?
Yes, please.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
From: Mike Turquette @ 2012-06-27 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1340630090.3395.85.camel@deskari>
On 20120625-16:14, Tomi Valkeinen wrote:
> A question about clk_prepare/unprepare, not directly related: let's say
> I have a driver for some HW block. The driver doesn't use clk functions,
> but uses runtime PM. The driver also sets pm_runtime_irq_safe().
>
> Now, the driver can call pm_runtime_get_sync() in an atomic context, and
> this would lead to the underlying framework (hwmod, omap_device, I don't
> know who =) enabling the func clock for that HW. But this would happen
> in atomic context, so the underlying framework can't use clk_prepare.
>
> How does the underlying framework handle that case? (sorry if that's a
> stupid question =).
>
I think it's a good question!
If we're going to call clk_prepare_enable from within a runtime pm
callback then I think we'll need to check if _irq_safe() is set and
conditionally call only clk_enable in such a case.
I'm not a runtime pm expert, but if the driver owns the responsibility
of calling pm_runtime_irq_safe then the driver has the proper context
to know that it should call clk_prepare BEFORE calling
pm_runtime_get_sync.
However if some other framework (outside of the driver) calls
pm_runtime_irq_safe then it will be difficult for the driver to know
what to do...
Regards,
Mike
> Tomi
>
^ permalink raw reply
* Re: [PATCH 05/11] OMAPDSS: add clk_prepare and clk_unprepare
From: Tomi Valkeinen @ 2012-06-27 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120627004709.GA22766@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
> On 20120625-16:14, Tomi Valkeinen wrote:
> > A question about clk_prepare/unprepare, not directly related: let's say
> > I have a driver for some HW block. The driver doesn't use clk functions,
> > but uses runtime PM. The driver also sets pm_runtime_irq_safe().
> >
> > Now, the driver can call pm_runtime_get_sync() in an atomic context, and
> > this would lead to the underlying framework (hwmod, omap_device, I don't
> > know who =) enabling the func clock for that HW. But this would happen
> > in atomic context, so the underlying framework can't use clk_prepare.
> >
> > How does the underlying framework handle that case? (sorry if that's a
> > stupid question =).
> >
>
> I think it's a good question!
>
> If we're going to call clk_prepare_enable from within a runtime pm
> callback then I think we'll need to check if _irq_safe() is set and
> conditionally call only clk_enable in such a case.
>
> I'm not a runtime pm expert, but if the driver owns the responsibility
> of calling pm_runtime_irq_safe then the driver has the proper context
> to know that it should call clk_prepare BEFORE calling
> pm_runtime_get_sync.
That's not quite what I meant. If it's the driver that does clk_enable,
be it in runtime PM callback or not, it's driver's responsibility.
But some clocks are not handled by the driver, but the hwmod/omap_device
framework. Mainly I think this is for the functional and interface
clocks. The driver has no visibility to those, they are implicitly
enabled via pm_runtime_get.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox