date:20120925

This series prepares the low level DISPC driver(dispc.c) to configure writeback
registers. Original series can be seen here:

http://marc.info/?l=linux-fbdevm=134753851619354w=2

Changes since v2:

- Removed patches which rename dispc_ovl_* functions to dispc_plane_*
- Revisited the scaling related code a bit. Removed the usage of 'output rate'
  to fit in writeback. Instead, added a new parameter called mem_to_mem, passed
  by APPLY. This tells whether we have to consider a display pixel clock for
  scaling limitations or not.
- All 'Scalar' references renamed to 'Scaler'.
- Minor cleanups.

Reference branch:

git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 
1-writeback-dispc

Archit Taneja (18):
  OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
  OMAPDSS: DISPC: Simplify function names for setting pipeline input
and output sizes
  OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane
functions
  OMAPDSS: OVERLAY: Add position and replication as overlay caps
  OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
  OMAPDSS: DISPC: Don't pass channel out when configuring overlays
  OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory
mode
  OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
  OMAPDSS: DISPC: Add writeback register offsets and dss features
structs
  OMAPDSS: DISPC: Configure input and output sizes for writeback
  OMAPDSS: DISPC: Downscale chroma if plane is writeback
  OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
  OMAPDSS: DISPC: Add function to set channel in for writeback
  OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
  OMAPDSS: DISPC: Configure writeback specific parameters in
dispc_wb_setup()
  OMAPDSS: DISPC: Configure writeback FIFOs
  OMAPDSS: DISPC: Add manager like functions for writeback
  OMAPDSS: DISPC: Configure color conversion coefficients for writeback

 drivers/video/omap2/dss/apply.c|2 +-
 drivers/video/omap2/dss/dispc.c|  561 ++--
 drivers/video/omap2/dss/dispc.h|   33 ++
 drivers/video/omap2/dss/dss.h  |   25 +-
 drivers/video/omap2/dss/dss_features.c |   57 +++-
 drivers/video/omap2/dss/dss_features.h |1 +
 include/video/omapdss.h|   15 +
 7 files changed, 510 insertions(+), 184 deletions(-)

-- 
1.7.9.5

--
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

[PATCH v2 00/18] OMAPDSS: DISPC changes for writeback pipeline

This series prepares the low level DISPC driver(dispc.c) to configure writeback
registers. Original series can be seen here:

http://marc.info/?l=linux-fbdevm=134753851619354w=2

Changes since v2:

- Removed patches which rename dispc_ovl_* functions to dispc_plane_*
- Revisited the scaling related code a bit. Removed the usage of 'output rate'
  to fit in writeback. Instead, added a new parameter called mem_to_mem, passed
  by APPLY. This tells whether we have to consider a display pixel clock for
  scaling limitations or not.
- All 'Scalar' references renamed to 'Scaler'.
- Minor cleanups.

Reference branch:

git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 
1-writeback-dispc

Archit Taneja (18):
  OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()
  OMAPDSS: DISPC: Simplify function names for setting pipeline input
and output sizes
  OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane
functions
  OMAPDSS: OVERLAY: Add position and replication as overlay caps
  OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common
  OMAPDSS: DISPC: Don't pass channel out when configuring overlays
  OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory
mode
  OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma
  OMAPDSS: DISPC: Add writeback register offsets and dss features
structs
  OMAPDSS: DISPC: Configure input and output sizes for writeback
  OMAPDSS: DISPC: Downscale chroma if plane is writeback
  OMAPDSS: DISPC: Don't set chroma resampling bit for writeback
  OMAPDSS: DISPC: Add function to set channel in for writeback
  OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup
  OMAPDSS: DISPC: Configure writeback specific parameters in
dispc_wb_setup()
  OMAPDSS: DISPC: Configure writeback FIFOs
  OMAPDSS: DISPC: Add manager like functions for writeback
  OMAPDSS: DISPC: Configure color conversion coefficients for writeback

 drivers/video/omap2/dss/apply.c|2 +-
 drivers/video/omap2/dss/dispc.c|  561 ++--
 drivers/video/omap2/dss/dispc.h|   33 ++
 drivers/video/omap2/dss/dss.h  |   25 +-
 drivers/video/omap2/dss/dss_features.c |   57 +++-
 drivers/video/omap2/dss/dss_features.h |1 +
 include/video/omapdss.h|   15 +
 7 files changed, 510 insertions(+), 184 deletions(-)

-- 
1.7.9.5

--
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

[PATCH v2 01/18] OMAPDSS: DISPC: Constify omap_overlay_info in dispc_ovl_setup()

The struct omap_overlay_info passed to dispc_ovl_setup() is used to configure
DISPC registers. It shouldn't modify the overlay_info structure. The pos_y field
was being changed in dispc_ovl_setup in the case of interlaced displays. Fix
this and const qualifier to the omap_overlay_info argument.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |9 +
 drivers/video/omap2/dss/dss.h   |2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 33db882..cd3d532 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2253,7 +2253,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return 0;
 }
 
-int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
+int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings)
 {
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
@@ -2271,6 +2271,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct 
omap_overlay_info *oi,
enum omap_channel channel;
int x_predecim = 1, y_predecim = 1;
bool ilace = mgr_timings-interlace;
+   u16 pos_y = oi-pos_y;
 
channel = dispc_ovl_get_channel_out(plane);
 
@@ -2293,12 +2294,12 @@ int dispc_ovl_setup(enum omap_plane plane, struct 
omap_overlay_info *oi,
if (ilace) {
if (fieldmode)
in_height /= 2;
-   oi-pos_y /= 2;
+   pos_y /= 2;
out_height /= 2;
 
DSSDBG(adjusting for ilace: height %d, pos_y %d, 
out_height %d\n,
-   in_height, oi-pos_y, out_height);
+   in_height, pos_y, out_height);
}
 
if (!dss_feat_color_mode_supported(plane, oi-color_mode))
@@ -2381,7 +2382,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct 
omap_overlay_info *oi,
DSSDBG(%d,%d %dx%d - %dx%d\n, oi-pos_x, oi-pos_y, in_width,
in_height, out_width, out_height);
 
-   dispc_ovl_set_pos(plane, oi-pos_x, oi-pos_y);
+   dispc_ovl_set_pos(plane, oi-pos_x, pos_y);
 
dispc_ovl_set_pic_size(plane, in_width, in_height);
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c2bc092..43210b8 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -440,7 +440,7 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, 
u32 low, u32 high);
 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,
+int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
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,
-- 
1.7.9.5

--
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

[PATCH v2 02/18] OMAPDSS: DISPC: Simplify function names for setting pipeline input and output sizes

The DISPC pipeline register names in the TRM for setting the buffer size and
the output size are a bit misleading, for example, there are different register
names for setting the buffer size for VID and GFX pipes. Things get more
confusing when considering writeback pipeline.

Rename the functions so that they tell whether they are configuring the input
to the scalar or the output. These will be extended later to support writeback
registers.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd3d532..2c01e13 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -705,7 +705,8 @@ static void dispc_ovl_set_pos(enum omap_plane plane, int x, 
int y)
dispc_write_reg(DISPC_OVL_POSITION(plane), val);
 }
 
-static void dispc_ovl_set_pic_size(enum omap_plane plane, int width, int 
height)
+static void dispc_ovl_set_input_size(enum omap_plane plane, int width,
+   int height)
 {
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
 
@@ -715,7 +716,8 @@ static void dispc_ovl_set_pic_size(enum omap_plane plane, 
int width, int height)
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
 }
 
-static void dispc_ovl_set_vid_size(enum omap_plane plane, int width, int 
height)
+static void dispc_ovl_set_output_size(enum omap_plane plane, int width,
+   int height)
 {
u32 val;
 
@@ -2384,13 +2386,14 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
 
dispc_ovl_set_pos(plane, oi-pos_x, pos_y);
 
-   dispc_ovl_set_pic_size(plane, in_width, in_height);
+   dispc_ovl_set_input_size(plane, in_width, in_height);
 
if (ovl-caps  OMAP_DSS_OVL_CAP_SCALE) {
dispc_ovl_set_scaling(plane, in_width, in_height, out_width,
   out_height, ilace, five_taps, fieldmode,
   oi-color_mode, oi-rotation);
-   dispc_ovl_set_vid_size(plane, out_width, out_height);
+
+   dispc_ovl_set_output_size(plane, out_width, out_height);
dispc_ovl_set_vid_color_conv(plane, cconv);
}
 
-- 
1.7.9.5

--
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

[PATCH v2 04/18] OMAPDSS: OVERLAY: Add position and replication as overlay caps

Add position and replication as overlay caps, and pass overlay caps as an
argument to the corresponding functions. Adding position and replication to
overlay caps seems a bit unnecessary, but it allows us to use the
corresponding functions for writeback too.

These caps will be set for all overlays, but not for writeback. This is done
so writeback can reuse dispc_ovl_setup() to the maximum.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c|   20 -
 drivers/video/omap2/dss/dss_features.c |   38 +---
 include/video/omapdss.h|2 ++
 3 files changed, 42 insertions(+), 18 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 955db56..0ff1c07 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -698,9 +698,15 @@ static void dispc_ovl_set_ba1_uv(enum omap_plane plane, 
u32 paddr)
dispc_write_reg(DISPC_OVL_BA1_UV(plane), paddr);
 }
 
-static void dispc_ovl_set_pos(enum omap_plane plane, int x, int y)
+static void dispc_ovl_set_pos(enum omap_plane plane,
+   enum omap_overlay_caps caps, int x, int y)
 {
-   u32 val = FLD_VAL(y, 26, 16) | FLD_VAL(x, 10, 0);
+   u32 val;
+
+   if ((caps  OMAP_DSS_OVL_CAP_POS) == 0)
+   return;
+
+   val = FLD_VAL(y, 26, 16) | FLD_VAL(x, 10, 0);
 
dispc_write_reg(DISPC_OVL_POSITION(plane), val);
 }
@@ -1051,11 +1057,15 @@ static void dispc_ovl_set_vid_color_conv(enum 
omap_plane plane, bool enable)
dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), val);
 }
 
-static void dispc_ovl_enable_replication(enum omap_plane plane, bool enable)
+static void dispc_ovl_enable_replication(enum omap_plane plane,
+   enum omap_overlay_caps caps, bool enable)
 {
static const unsigned shifts[] = { 5, 10, 10, 10 };
int shift;
 
+   if ((caps  OMAP_DSS_OVL_CAP_REPLICATION) == 0)
+   return;
+
shift = shifts[plane];
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable, shift, shift);
 }
@@ -2383,7 +2393,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
DSSDBG(%d,%d %dx%d - %dx%d\n, oi-pos_x, oi-pos_y, in_width,
in_height, out_width, out_height);
 
-   dispc_ovl_set_pos(plane, oi-pos_x, pos_y);
+   dispc_ovl_set_pos(plane, caps, oi-pos_x, pos_y);
 
dispc_ovl_set_input_size(plane, in_width, in_height);
 
@@ -2403,7 +2413,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
dispc_ovl_set_pre_mult_alpha(plane, caps, oi-pre_mult_alpha);
dispc_ovl_setup_global_alpha(plane, caps, oi-global_alpha);
 
-   dispc_ovl_enable_replication(plane, replication);
+   dispc_ovl_enable_replication(plane, caps, replication);
 
return 0;
 }
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 63d109f..8b6c79f 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -269,54 +269,66 @@ static const enum omap_color_mode 
omap4_dss_supported_color_modes[] = {
 
 static const enum omap_overlay_caps omap2_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
-   0,
+   OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO1 */
-   OMAP_DSS_OVL_CAP_SCALE,
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+   OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO2 */
-   OMAP_DSS_OVL_CAP_SCALE,
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+   OMAP_DSS_OVL_CAP_REPLICATION,
 };
 
 static const enum omap_overlay_caps omap3430_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
-   OMAP_DSS_OVL_CAP_GLOBAL_ALPHA,
+   OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_POS |
+   OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO1 */
-   OMAP_DSS_OVL_CAP_SCALE,
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+   OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO2 */
-   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA,
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA |
+   OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
 };
 
 static const enum omap_overlay_caps omap3630_dss_overlay_caps[] = {
/* OMAP_DSS_GFX */
-   OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA,
+   OMAP_DSS_OVL_CAP_GLOBAL_ALPHA | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA |
+   OMAP_DSS_OVL_CAP_POS | OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO1 */
-   OMAP_DSS_OVL_CAP_SCALE,
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_POS |
+   OMAP_DSS_OVL_CAP_REPLICATION,
 
/* OMAP_DSS_VIDEO2 */
OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_GLOBAL_ALPHA |
-   OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA,
+

[PATCH v2 05/18] OMAPDSS: DISPC: Make dispc_ovl_setup call dispc_ovl_setup_common

Add a new static function called dispc_ovl_setup_common(). This function is 
used by
dispc_ovl_setup() to configure the overlay registers. This split is done so that
dispc_wb_setup() can reuse overlay register configuration related code.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |  128 ++-
 1 file changed, 71 insertions(+), 57 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 0ff1c07..782de44 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2262,43 +2262,35 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return 0;
 }
 
-int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
+static int dispc_ovl_setup_common(enum omap_plane plane,
+   enum omap_channel channel, enum omap_overlay_caps caps,
+   u32 paddr, u32 p_uv_addr, u16 screen_width, int pos_x,
+   int pos_y, u16 width, u16 height, u16 out_width, u16 out_height,
+   enum omap_color_mode color_mode, u8 rotation, bool mirror,
+   u8 zorder, u8 pre_mult_alpha, u8 global_alpha,
+   enum omap_dss_rotation_type rotation_type,
bool replication, const struct omap_video_timings *mgr_timings)
 {
-   struct omap_overlay *ovl = omap_dss_get_overlay(plane);
-   enum omap_overlay_caps caps = ovl-caps;
bool five_taps = true;
bool fieldmode = 0;
int r, cconv = 0;
unsigned offset0, offset1;
s32 row_inc;
s32 pix_inc;
-   u16 frame_height = oi-height;
+   u16 frame_height = height;
unsigned int field_offset = 0;
-   u16 in_height = oi-height;
-   u16 in_width = oi-width;
-   u16 out_width, out_height;
-   enum omap_channel channel;
+   u16 in_height = height;
+   u16 in_width = width;
int x_predecim = 1, y_predecim = 1;
bool ilace = mgr_timings-interlace;
-   u16 pos_y = oi-pos_y;
-
-   channel = dispc_ovl_get_channel_out(plane);
-
-   DSSDBG(dispc_ovl_setup %d, pa %x, pa_uv %x, sw %d, %d,%d, %dx%d - 
-   %dx%d, cmode %x, rot %d, mir %d, ilace %d chan %d repl %d\n,
-   plane, oi-paddr, oi-p_uv_addr,
-   oi-screen_width, oi-pos_x, oi-pos_y, oi-width, oi-height,
-   oi-out_width, oi-out_height, oi-color_mode, oi-rotation,
-   oi-mirror, ilace, channel, replication);
 
-   if (oi-paddr == 0)
+   if (paddr == 0)
return -EINVAL;
 
-   out_width = oi-out_width == 0 ? oi-width : oi-out_width;
-   out_height = oi-out_height == 0 ? oi-height : oi-out_height;
+   out_width = out_width == 0 ? width : out_width;
+   out_height = out_height == 0 ? height : out_height;
 
-   if (ilace  oi-height == out_height)
+   if (ilace  height == out_height)
fieldmode = 1;
 
if (ilace) {
@@ -2308,26 +2300,26 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
out_height /= 2;
 
DSSDBG(adjusting for ilace: height %d, pos_y %d, 
-   out_height %d\n,
-   in_height, pos_y, out_height);
+   out_height %d\n, in_height, pos_y,
+   out_height);
}
 
-   if (!dss_feat_color_mode_supported(plane, oi-color_mode))
+   if (!dss_feat_color_mode_supported(plane, color_mode))
return -EINVAL;
 
r = dispc_ovl_calc_scaling(plane, caps, channel, mgr_timings,
in_width, in_height, out_width, out_height,
-   oi-color_mode, five_taps, x_predecim, y_predecim,
-   oi-pos_x);
+   color_mode, five_taps, x_predecim, y_predecim,
+   pos_x);
if (r)
return r;
 
in_width = DIV_ROUND_UP(in_width, x_predecim);
in_height = DIV_ROUND_UP(in_height, y_predecim);
 
-   if (oi-color_mode == OMAP_DSS_COLOR_YUV2 ||
-   oi-color_mode == OMAP_DSS_COLOR_UYVY ||
-   oi-color_mode == OMAP_DSS_COLOR_NV12)
+   if (color_mode == OMAP_DSS_COLOR_YUV2 ||
+   color_mode == OMAP_DSS_COLOR_UYVY ||
+   color_mode == OMAP_DSS_COLOR_NV12)
cconv = 1;
 
if (ilace  !fieldmode) {
@@ -2353,71 +2345,93 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
row_inc = 0;
pix_inc = 0;
 
-   if (oi-rotation_type == OMAP_DSS_ROT_TILER)
-   calc_tiler_rotation_offset(oi-screen_width, in_width,
-   oi-color_mode, fieldmode, field_offset,
+   if (rotation_type == OMAP_DSS_ROT_TILER)
+   calc_tiler_rotation_offset(screen_width, in_width,
+   color_mode,

[PATCH v2 03/18] OMAPDSS: DISPC: Pass overlay caps as a parameter to dispc plane functions

Currently, the functions below take the omap_plane parameter and derive the
overlay caps within them. Pass the overlay caps as a parameter to the function
to allow these to be used by writeback too.

- dispc_ovl_set_zorder()
- dispc_ovl_set_pre_mult_alpha()
- dispc_ovl_setup_global_alpha()
- dispc_ovl_calc_scaling()
- dispc_ovl_setup()

These functions will be used for writeback later, and the caps will help in
deciding if they are to be used for writeback or not. This allows reuse of
overlay caps for writeback.

Using omap_overlay_caps for writeback seems a bit incorrect, but caps is
something already in use by users of OMAPDSS(omapfb/omap_vout), so we use
overlay caps for overlay like features of writeback too.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   41 +++
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 2c01e13..955db56 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -728,11 +728,10 @@ static void dispc_ovl_set_output_size(enum omap_plane 
plane, int width,
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
 }
 
-static void dispc_ovl_set_zorder(enum omap_plane plane, u8 zorder)
+static void dispc_ovl_set_zorder(enum omap_plane plane,
+   enum omap_overlay_caps caps, u8 zorder)
 {
-   struct omap_overlay *ovl = omap_dss_get_overlay(plane);
-
-   if ((ovl-caps  OMAP_DSS_OVL_CAP_ZORDER) == 0)
+   if ((caps  OMAP_DSS_OVL_CAP_ZORDER) == 0)
return;
 
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), zorder, 27, 26);
@@ -749,23 +748,22 @@ static void dispc_ovl_enable_zorder_planes(void)
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(i), 1, 25, 25);
 }
 
-static void dispc_ovl_set_pre_mult_alpha(enum omap_plane plane, bool enable)
+static void dispc_ovl_set_pre_mult_alpha(enum omap_plane plane,
+   enum omap_overlay_caps caps, bool enable)
 {
-   struct omap_overlay *ovl = omap_dss_get_overlay(plane);
-
-   if ((ovl-caps  OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA) == 0)
+   if ((caps  OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA) == 0)
return;
 
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 28, 28);
 }
 
-static void dispc_ovl_setup_global_alpha(enum omap_plane plane, u8 
global_alpha)
+static void dispc_ovl_setup_global_alpha(enum omap_plane plane,
+   enum omap_overlay_caps caps, u8 global_alpha)
 {
static const unsigned shifts[] = { 0, 8, 16, 24, };
int shift;
-   struct omap_overlay *ovl = omap_dss_get_overlay(plane);
 
-   if ((ovl-caps  OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
+   if ((caps  OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
return;
 
shift = shifts[plane];
@@ -2193,13 +2191,12 @@ static int dispc_ovl_calc_scaling_44xx(enum 
omap_channel channel,
 }
 
 static int dispc_ovl_calc_scaling(enum omap_plane plane,
-   enum omap_channel channel,
+   enum omap_overlay_caps caps, enum omap_channel channel,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, u16 pos_x)
 {
-   struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
const int max_decim_limit = 16;
unsigned long core_clk = 0;
@@ -2208,7 +2205,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (width == out_width  height == out_height)
return 0;
 
-   if ((ovl-caps  OMAP_DSS_OVL_CAP_SCALE) == 0)
+   if ((caps  OMAP_DSS_OVL_CAP_SCALE) == 0)
return -EINVAL;
 
*x_predecim = max_decim_limit;
@@ -2259,6 +2256,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings)
 {
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
+   enum omap_overlay_caps caps = ovl-caps;
bool five_taps = true;
bool fieldmode = 0;
int r, cconv = 0;
@@ -2307,9 +2305,10 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
if (!dss_feat_color_mode_supported(plane, oi-color_mode))
return -EINVAL;
 
-   r = dispc_ovl_calc_scaling(plane, channel, mgr_timings, in_width,
-   in_height, out_width, out_height, oi-color_mode,
-   five_taps, x_predecim, y_predecim, oi-pos_x);
+   r = dispc_ovl_calc_scaling(plane, caps, channel, mgr_timings,
+   in_width, in_height, out_width, out_height,
+   oi-color_mode, five_taps, x_predecim, y_predecim,
+   oi-pos_x);

[PATCH v2 06/18] OMAPDSS: DISPC: Don't pass channel out when configuring overlays

dispc_ovl_setup_common() is to be used by both overlays and writeback. We pass
channel out to figure out what manager the overlay is connected to, to determine
the pixel clock rate. This is used to decide the scaling limitations for that
overlay.

writeback doesn't have a channel out, it has a channel in field which tells
where writeback gets its input from. These are 2 different fields, and this
prevents us reusing the overlay configuration code for writeback.

To overcome this, we now pass omap_plane to overlay related functions rather
than passing channel out. We create helper functions which can derive pclk/lclk
from the omap_plane id.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |  115 ++-
 1 file changed, 66 insertions(+), 49 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 782de44..edb31fd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -86,13 +86,13 @@ struct dispc_features {
u16 sw_max;
u16 vp_max;
u16 hp_max;
-   int (*calc_scaling) (enum omap_channel channel,
+   int (*calc_scaling) (enum omap_plane plane,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
u16 pos_x, unsigned long *core_clk);
-   unsigned long (*calc_core_clk) (enum omap_channel channel,
+   unsigned long (*calc_core_clk) (enum omap_plane plane,
u16 width, u16 height, u16 out_width, u16 out_height);
u8 num_fifos;
 
@@ -236,6 +236,8 @@ static const struct {
 };
 
 static void _omap_dispc_set_irqs(void);
+static unsigned long dispc_plane_pclk_rate(enum omap_plane plane);
+static unsigned long dispc_plane_lclk_rate(enum omap_plane plane);
 
 static inline void dispc_write_reg(const u16 idx, u32 val)
 {
@@ -1919,22 +1921,19 @@ static void calc_tiler_rotation_offset(u16 
screen_width, u16 width,
  * This function is used to avoid synclosts in OMAP3, because of some
  * undocumented horizontal position and timing related limitations.
  */
-static int check_horiz_timing_omap3(enum omap_channel channel,
+static int check_horiz_timing_omap3(enum omap_plane plane,
const struct omap_video_timings *t, u16 pos_x,
u16 width, u16 height, u16 out_width, u16 out_height)
 {
int DS = DIV_ROUND_UP(height, out_height);
-   unsigned long nonactive, lclk, pclk;
+   unsigned long nonactive;
static const u8 limits[3] = { 8, 10, 20 };
u64 val, blank;
+   unsigned long pclk = dispc_plane_pclk_rate(plane);
+   unsigned long lclk = dispc_plane_lclk_rate(plane);
int i;
 
nonactive = t-x_res + t-hfp + t-hsw + t-hbp - out_width;
-   pclk = dispc_mgr_pclk_rate(channel);
-   if (dss_mgr_is_lcd(channel))
-   lclk = dispc_mgr_lclk_rate(channel);
-   else
-   lclk = dispc_fclk_rate();
 
i = 0;
if (out_height  height)
@@ -1971,13 +1970,14 @@ static int check_horiz_timing_omap3(enum omap_channel 
channel,
return 0;
 }
 
-static unsigned long calc_core_clk_five_taps(enum omap_channel channel,
+static unsigned long calc_core_clk_five_taps(enum omap_plane plane,
const struct omap_video_timings *mgr_timings, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
 {
u32 core_clk = 0;
-   u64 tmp, pclk = dispc_mgr_pclk_rate(channel);
+   u64 tmp;
+   unsigned long pclk = dispc_plane_pclk_rate(plane);
 
if (height = out_height  width = out_width)
return (unsigned long) pclk;
@@ -2011,10 +2011,10 @@ static unsigned long calc_core_clk_five_taps(enum 
omap_channel channel,
return core_clk;
 }
 
-static unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
+static unsigned long calc_core_clk_24xx(enum omap_plane plane, u16 width,
u16 height, u16 out_width, u16 out_height)
 {
-   unsigned long pclk = dispc_mgr_pclk_rate(channel);
+   unsigned long pclk = dispc_plane_pclk_rate(plane);
 
if (height  out_height  width  out_width)
return pclk * 4;
@@ -2022,11 +2022,11 @@ static unsigned long calc_core_clk_24xx(enum 
omap_channel channel, u16 width,
return pclk * 2;
 }
 
-static unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
+static unsigned long calc_core_clk_34xx(enum omap_plane plane, u16 width,
u16 height, u16 out_width, u16 out_height)
 {
unsigned int hf, vf;
-   unsigned long pclk = dispc_mgr_pclk_rate(channel);
+   unsigned long pclk = dispc_plane_pclk_rate(plane);
 
/*
 * FIXME how to determine

[PATCH v2 07/18] OMAPDSS: DIPSC: Relax scaling limitations when in memory to memory mode

The scalers of overlays and writeback do not have any constraints on downscale
ratio when operating in memory to memory mode.

This is because in memory to memory mode, we aren't connected to a display which
needs data output at the rate of pixel clock. The scalers can perform as much
downscaling as needed, the rate at which the scaler outputs is adjusted
accordingly.

Relax constraints related to downscaling based on whether the input overlays are
connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
will later be configured to the correct value based on whether the overlay is
connected to writeback or not. Do the same later for writeback when writeback is
configured.

In the scaling calculation code, we calculate the minimum amount of core clock 
we
need to achieve the required downscaling. If we are in memory to memory mode, we
set this to a very small value(1 in this case), this value would always be
lesser than the actual DISPC core clock value, and hence the scaling checks
would succeed.

We take care that pixel clock isn't calculated for writeback and the overlays
connected to it when in memory to memory mode. A pixel clock in such cases
doesn't make sense.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/apply.c |2 +-
 drivers/video/omap2/dss/dispc.c |   60 ++-
 drivers/video/omap2/dss/dss.h   |3 +-
 3 files changed, 44 insertions(+), 21 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 2b1fa85..19d66f4 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -584,7 +584,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
 
replication = dss_ovl_use_replication(mp-lcd_config, oi-color_mode);
 
-   r = dispc_ovl_setup(ovl-id, oi, replication, mp-timings);
+   r = dispc_ovl_setup(ovl-id, oi, replication, mp-timings, false);
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 edb31fd..ba65ebd 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -91,9 +91,10 @@ struct dispc_features {
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
-   u16 pos_x, unsigned long *core_clk);
+   u16 pos_x, unsigned long *core_clk, bool mem_to_mem);
unsigned long (*calc_core_clk) (enum omap_plane plane,
-   u16 width, u16 height, u16 out_width, u16 out_height);
+   u16 width, u16 height, u16 out_width, u16 out_height,
+   bool mem_to_mem);
u8 num_fifos;
 
/* swap GFX  WB fifos */
@@ -2012,7 +2013,7 @@ static unsigned long calc_core_clk_five_taps(enum 
omap_plane plane,
 }
 
 static unsigned long calc_core_clk_24xx(enum omap_plane plane, u16 width,
-   u16 height, u16 out_width, u16 out_height)
+   u16 height, u16 out_width, u16 out_height, bool mem_to_mem)
 {
unsigned long pclk = dispc_plane_pclk_rate(plane);
 
@@ -2023,7 +2024,7 @@ static unsigned long calc_core_clk_24xx(enum omap_plane 
plane, u16 width,
 }
 
 static unsigned long calc_core_clk_34xx(enum omap_plane plane, u16 width,
-   u16 height, u16 out_width, u16 out_height)
+   u16 height, u16 out_width, u16 out_height, bool mem_to_mem)
 {
unsigned int hf, vf;
unsigned long pclk = dispc_plane_pclk_rate(plane);
@@ -2050,9 +2051,20 @@ static unsigned long calc_core_clk_34xx(enum omap_plane 
plane, u16 width,
 }
 
 static unsigned long calc_core_clk_44xx(enum omap_plane plane, u16 width,
-   u16 height, u16 out_width, u16 out_height)
+   u16 height, u16 out_width, u16 out_height, bool mem_to_mem)
 {
-   unsigned long pclk = dispc_plane_pclk_rate(plane);
+   unsigned long pclk;
+
+   /*
+* If the overlay/writeback is in mem to mem mode, there are no
+* downscaling limitations with respect to pixel clock, return 1 as
+* required core clock to represent that we have sufficient enough
+* core clock to do maximum downscaling
+*/
+   if (mem_to_mem)
+   return 1;
+
+   pclk = dispc_plane_pclk_rate(plane);
 
if (width  out_width)
return DIV_ROUND_UP(pclk, out_width) * width;
@@ -2065,7 +2077,7 @@ static int dispc_ovl_calc_scaling_24xx(enum omap_plane 
plane,
u16 width, u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
-   u16 pos_x,

[PATCH v2 08/18] OMAPDSS: DISPC: Allow both upscaling and downscaling of chroma

In the function dispc_plane_set_scaling_uv(), create a parameter which tells if
we want to upscale or downscale the chroma plane.

Downscaling of chroma is required by writeback pipeline for converting the input
YUV444 color format to YUV422 or NV12.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ba65ebd..e42e902 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1457,6 +1457,7 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane 
plane,
 {
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
+   bool chroma_upscale = true;
 
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
@@ -1473,23 +1474,34 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane 
plane,
 
switch (color_mode) {
case OMAP_DSS_COLOR_NV12:
-   /* UV is subsampled by 2 vertically*/
-   orig_height = 1;
-   /* UV is subsampled by 2 horz.*/
-   orig_width = 1;
+   if (chroma_upscale) {
+   /* UV is subsampled by 2 horizontally and vertically */
+   orig_height = 1;
+   orig_width = 1;
+   } else {
+   /* UV is downsampled by 2 horizontally and vertically */
+   orig_height = 1;
+   orig_width = 1;
+   }
+
break;
case OMAP_DSS_COLOR_YUV2:
case OMAP_DSS_COLOR_UYVY:
-   /*For YUV422 with 90/270 rotation,
-*we don't upsample chroma
-*/
+   /* For YUV422 with 90/270 rotation, we don't upsample chroma */
if (rotation == OMAP_DSS_ROT_0 ||
-   rotation == OMAP_DSS_ROT_180)
-   /* UV is subsampled by 2 hrz*/
-   orig_width = 1;
+   rotation == OMAP_DSS_ROT_180) {
+   if (chroma_upscale)
+   /* UV is subsampled by 2 horizontally */
+   orig_width = 1;
+   else
+   /* UV is downsampled by 2 horizontally */
+   orig_width = 1;
+   }
+
/* must use FIR for YUV422 if rotated */
if (rotation != OMAP_DSS_ROT_0)
scale_x = scale_y = true;
+
break;
default:
BUG();
-- 
1.7.9.5

--
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

[PATCH v2 09/18] OMAPDSS: DISPC: Add writeback register offsets and dss features structs

Since writeback has many overlay like properties, and most of it's registers are
similar to that of overlays, it's possible to reuse most of the overlay related
DISPC code for writeback when considering it as a plane. Writeback was added as
a plane in the omap_plane field as OMAP_DSS_WB.

Add the writeback register offsets in dispc.h, add minimal WB plane related info
needed in dss_features. Add a function which returns the number of writeback
pipelines an OMAP version has.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.h|   33 
 drivers/video/omap2/dss/dss_features.c |   19 ++
 drivers/video/omap2/dss/dss_features.h |1 +
 3 files changed, 53 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 42e56cc..222363c 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -373,6 +373,7 @@ static inline u16 DISPC_BA0_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0008;
default:
BUG();
@@ -388,6 +389,7 @@ static inline u16 DISPC_BA1_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x0004;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x000C;
default:
BUG();
@@ -407,6 +409,8 @@ static inline u16 DISPC_BA0_UV_OFFSET(enum omap_plane plane)
return 0x04BC;
case OMAP_DSS_VIDEO3:
return 0x0310;
+   case OMAP_DSS_WB:
+   return 0x0118;
default:
BUG();
return 0;
@@ -425,6 +429,8 @@ static inline u16 DISPC_BA1_UV_OFFSET(enum omap_plane plane)
return 0x04C0;
case OMAP_DSS_VIDEO3:
return 0x0314;
+   case OMAP_DSS_WB:
+   return 0x011C;
default:
BUG();
return 0;
@@ -454,6 +460,7 @@ static inline u16 DISPC_SIZE_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x000C;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x00A8;
default:
BUG();
@@ -470,6 +477,7 @@ static inline u16 DISPC_ATTR_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x0010;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0070;
default:
BUG();
@@ -489,6 +497,8 @@ static inline u16 DISPC_ATTR2_OFFSET(enum omap_plane plane)
return 0x04DC;
case OMAP_DSS_VIDEO3:
return 0x032C;
+   case OMAP_DSS_WB:
+   return 0x0310;
default:
BUG();
return 0;
@@ -504,6 +514,7 @@ static inline u16 DISPC_FIFO_THRESH_OFFSET(enum omap_plane 
plane)
case OMAP_DSS_VIDEO2:
return 0x0014;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x008C;
default:
BUG();
@@ -537,6 +548,7 @@ static inline u16 DISPC_ROW_INC_OFFSET(enum omap_plane 
plane)
case OMAP_DSS_VIDEO2:
return 0x001C;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x00A4;
default:
BUG();
@@ -553,6 +565,7 @@ static inline u16 DISPC_PIX_INC_OFFSET(enum omap_plane 
plane)
case OMAP_DSS_VIDEO2:
return 0x0020;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0098;
default:
BUG();
@@ -602,6 +615,7 @@ static inline u16 DISPC_FIR_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x0024;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0090;
default:
BUG();
@@ -621,6 +635,8 @@ static inline u16 DISPC_FIR2_OFFSET(enum omap_plane plane)
return 0x055C;
case OMAP_DSS_VIDEO3:
return 0x0424;
+   case OMAP_DSS_WB:
+   return 0x290;
default:
BUG();
return 0;
@@ -637,6 +653,7 @@ static inline u16 DISPC_PIC_SIZE_OFFSET(enum omap_plane 
plane)
case OMAP_DSS_VIDEO2:
return 0x0028;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0094;
default:
BUG();
@@ -655,6 +672,7 @@ static inline u16 DISPC_ACCU0_OFFSET(enum omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x002C;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x;
default:
BUG();
@@ -674,6 +692,8 @@ static inline u16 DISPC_ACCU2_0_OFFSET(enum omap_plane 
plane)
return 0x0560;
case OMAP_DSS_VIDEO3:
return 0x0428;
+

[PATCH v2 10/18] OMAPDSS: DISPC: Configure input and output sizes for writeback

Writeback uses the WB_PICTURE_SIZE register to define the size of the content
written to memory, this is the output of the scaler. It uses the WB_SIZE
register to define the size of the content coming from the overlay/manager to
which it is connected, this is the input to the scaler. This naming is different
as compared to overlays.

Add checks for writeback in dispc_ovl_set_input_size() and
dispc_ovl_set_output_size() to write to the correct registers.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e42e902..04fdd33 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -719,7 +719,7 @@ static void dispc_ovl_set_input_size(enum omap_plane plane, 
int width,
 {
u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
 
-   if (plane == OMAP_DSS_GFX)
+   if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
dispc_write_reg(DISPC_OVL_SIZE(plane), val);
else
dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
@@ -734,7 +734,10 @@ static void dispc_ovl_set_output_size(enum omap_plane 
plane, int width,
 
val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
 
-   dispc_write_reg(DISPC_OVL_SIZE(plane), val);
+   if (plane == OMAP_DSS_WB)
+   dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
+   else
+   dispc_write_reg(DISPC_OVL_SIZE(plane), val);
 }
 
 static void dispc_ovl_set_zorder(enum omap_plane plane,
-- 
1.7.9.5

--
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

[PATCH v2 11/18] OMAPDSS: DISPC: Downscale chroma if plane is writeback

When converting YUYV444 content to YUV422 or NV12 formats through writeback
pipeline, the scaler needs to downscale the chroma plane. Ensure that chroma
is downscaled when the pipeline is writeback.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 04fdd33..4f36e83 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1460,7 +1460,7 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane 
plane,
 {
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
-   bool chroma_upscale = true;
+   bool chroma_upscale = plane != OMAP_DSS_WB ? true : false;
 
if (!dss_has_feature(FEAT_HANDLE_UV_SEPARATE))
return;
-- 
1.7.9.5

--
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

[PATCH v2 12/18] OMAPDSS: DISPC: Don't set chroma resampling bit for writeback

The bit YUVCHROMARESAMPLING isn't there for writeback in DISPC_WB_ATTRIBUTES2.
It isn't there because we don't upsample chroma like for video pipelines, we
downsample chroma in writeback to get YUV422 or NV12 formats from the YUV444
input.

Ignore this bit in dispc_ovl_set_scaling_uv() if the plane is OMAP_DSS_WB.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4f36e83..d9ca7bf 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1468,7 +1468,8 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane 
plane,
color_mode != OMAP_DSS_COLOR_UYVY 
color_mode != OMAP_DSS_COLOR_NV12)) {
/* reset chroma resampling for RGB formats  */
-   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
+   if (plane != OMAP_DSS_WB)
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane), 0, 8, 8);
return;
}
 
@@ -1520,8 +1521,10 @@ static void dispc_ovl_set_scaling_uv(enum omap_plane 
plane,
out_width, out_height, five_taps,
rotation, DISPC_COLOR_COMPONENT_UV);
 
-   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),
-   (scale_x || scale_y) ? 1 : 0, 8, 8);
+   if (plane != OMAP_DSS_WB)
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES2(plane),
+   (scale_x || scale_y) ? 1 : 0, 8, 8);
+
/* set H scaling */
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), scale_x ? 1 : 0, 5, 5);
/* set V scaling */
-- 
1.7.9.5

--
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

[PATCH v2 13/18] OMAPDSS: DISPC: Add function to set channel in for writeback

Writeback can take input from either one of the overlays, or one of the overlay
managers. Add an enum which represents the channel_in for writeback, and maps
to the register field programming.

Add a function to configure channel in for writeback. This will be used later in
APPLY.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |7 +++
 drivers/video/omap2/dss/dss.h   |   13 +
 2 files changed, 20 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d9ca7bf..6d482f5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -983,6 +983,13 @@ static enum omap_channel dispc_ovl_get_channel_out(enum 
omap_plane plane)
return channel;
 }
 
+void dispc_wb_set_channel_in(enum dss_writeback_channel channel)
+{
+   enum omap_plane plane = OMAP_DSS_WB;
+
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), channel, 18, 16);
+}
+
 static void dispc_ovl_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
 {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 04a1eda..872e420 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -113,6 +113,17 @@ enum dss_dsi_content_type {
DSS_DSI_CONTENT_GENERIC,
 };
 
+enum dss_writeback_channel {
+   DSS_WB_LCD1_MGR =   0,
+   DSS_WB_LCD2_MGR =   1,
+   DSS_WB_TV_MGR = 2,
+   DSS_WB_OVL0 =   3,
+   DSS_WB_OVL1 =   4,
+   DSS_WB_OVL2 =   5,
+   DSS_WB_OVL3 =   6,
+   DSS_WB_LCD3_MGR =   7,
+};
+
 struct dss_clock_info {
/* rates that we get with dividers below */
unsigned long fck;
@@ -471,6 +482,8 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
 void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
 
+void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
+
 /* VENC */
 #ifdef CONFIG_OMAP2_DSS_VENC
 int venc_init_platform_driver(void) __init;
-- 
1.7.9.5

--
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

[PATCH v2 14/18] OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup

Create struct omap_dss_writeback_info, this is similar to omap_overlay_info,
the major difference is that there is no parameter which describes the input
size to writeback, this is because this is always fixed, and decided by the
connected overlay or overlay manager. One more difference is that screen_width
is renamed to buf_width, to give the value of stride the writeback buffer has.

Call dispc_ovl_setup_common() through dispc_wb_setup() to configure overlay-like
parameters. The parameters in dispc_ovl_setup_common() which do not hold for
writeback are filled passed as zeroes or false, the code takes care of not
configuring them as they won't possess the needed overlay caps.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   27 +++
 drivers/video/omap2/dss/dss.h   |2 ++
 include/video/omapdss.h |   13 +
 3 files changed, 42 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6d482f5..2e5f033 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2479,6 +2479,33 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
return r;
 }
 
+int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
+   const struct omap_video_timings *mgr_timings)
+{
+   int r;
+   enum omap_plane plane = OMAP_DSS_WB;
+   const int pos_x = 0, pos_y = 0;
+   const u8 zorder = 0, global_alpha = 0;
+   const bool replication = false;
+   int in_width = mgr_timings-x_res;
+   int in_height = mgr_timings-y_res;
+   enum omap_overlay_caps caps =
+   OMAP_DSS_OVL_CAP_SCALE | OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA;
+
+   DSSDBG(dispc_wb_setup, pa %x, pa_uv %x, %d,%d - %dx%d, cmode %x, 
+   rot %d, mir %d\n, wi-paddr, wi-p_uv_addr, in_width,
+   in_height, wi-width, wi-height, wi-color_mode, wi-rotation,
+   wi-mirror);
+
+   r = dispc_ovl_setup_common(plane, caps, wi-paddr, wi-p_uv_addr,
+   wi-buf_width, pos_x, pos_y, in_width, in_height, wi-width,
+   wi-height, wi-color_mode, wi-rotation, wi-mirror, zorder,
+   wi-pre_mult_alpha, global_alpha, wi-rotation_type,
+   replication, mgr_timings, false);
+
+   return r;
+}
+
 int dispc_ovl_enable(enum omap_plane plane, bool enable)
 {
DSSDBG(dispc_enable_plane %d, %d\n, plane, enable);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 872e420..1a09f00 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -483,6 +483,8 @@ void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
 
 void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
+int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
+   const struct omap_video_timings *timings);
 
 /* VENC */
 #ifdef CONFIG_OMAP2_DSS_VENC
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 46097bd..3729173 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -510,6 +510,19 @@ struct omap_dsi_pin_config {
int pins[OMAP_DSS_MAX_DSI_PINS];
 };
 
+struct omap_dss_writeback_info {
+   u32 paddr;
+   u32 p_uv_addr;
+   u16 buf_width;
+   u16 width;
+   u16 height;
+   enum omap_color_mode color_mode;
+   u8 rotation;
+   enum omap_dss_rotation_type rotation_type;
+   bool mirror;
+   u8 pre_mult_alpha;
+};
+
 struct omap_dss_output {
struct list_head list;
 
-- 
1.7.9.5

--
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

[PATCH v2 15/18] OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup()

Configure some of the writeback specific parameters in dispc_wb_setup(). The
writeback parameters configured are:

truncation: This needs to be set if the color depth input to writeback is more
than the color depth of the color mode we want to store in memory.

writeback mode: This configures whether we want to use writeback in mem to mem
or capture mode. This information will be directly passed by APPLY later.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   28 ++--
 drivers/video/omap2/dss/dss.h   |2 +-
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 2e5f033..ca28a88 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2480,13 +2480,15 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
 }
 
 int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
-   const struct omap_video_timings *mgr_timings)
+   bool mem_to_mem, const struct omap_video_timings *mgr_timings)
 {
int r;
+   u32 l;
enum omap_plane plane = OMAP_DSS_WB;
const int pos_x = 0, pos_y = 0;
const u8 zorder = 0, global_alpha = 0;
const bool replication = false;
+   bool truncation;
int in_width = mgr_timings-x_res;
int in_height = mgr_timings-y_res;
enum omap_overlay_caps caps =
@@ -2501,7 +2503,29 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
wi-buf_width, pos_x, pos_y, in_width, in_height, wi-width,
wi-height, wi-color_mode, wi-rotation, wi-mirror, zorder,
wi-pre_mult_alpha, global_alpha, wi-rotation_type,
-   replication, mgr_timings, false);
+   replication, mgr_timings, mem_to_mem);
+
+   switch (wi-color_mode) {
+   case OMAP_DSS_COLOR_RGB16:
+   case OMAP_DSS_COLOR_RGB24P:
+   case OMAP_DSS_COLOR_ARGB16:
+   case OMAP_DSS_COLOR_RGBA16:
+   case OMAP_DSS_COLOR_RGB12U:
+   case OMAP_DSS_COLOR_ARGB16_1555:
+   case OMAP_DSS_COLOR_XRGB16_1555:
+   case OMAP_DSS_COLOR_RGBX16:
+   truncation = true;
+   break;
+   default:
+   truncation = false;
+   break;
+   }
+
+   /* setup extra DISPC_WB_ATTRIBUTES */
+   l = dispc_read_reg(DISPC_OVL_ATTRIBUTES(plane));
+   l = FLD_MOD(l, truncation, 10, 10); /* TRUNCATIONENABLE */
+   l = FLD_MOD(l, mem_to_mem, 19, 19); /* WRITEBACKMODE */
+   dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), l);
 
return r;
 }
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 1a09f00..442c06a 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -484,7 +484,7 @@ void dispc_mgr_setup(enum omap_channel channel,
 
 void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
 int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
-   const struct omap_video_timings *timings);
+   bool mem_to_mem, const struct omap_video_timings *timings);
 
 /* VENC */
 #ifdef CONFIG_OMAP2_DSS_VENC
-- 
1.7.9.5

--
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

[PATCH v2 16/18] OMAPDSS: DISPC: Configure writeback FIFOs

Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.

The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ca28a88..d6f120d 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -993,7 +993,7 @@ void dispc_wb_set_channel_in(enum dss_writeback_channel 
channel)
 static void dispc_ovl_set_burst_size(enum omap_plane plane,
enum omap_burst_size burst_size)
 {
-   static const unsigned shifts[] = { 6, 14, 14, 14, };
+   static const unsigned shifts[] = { 6, 14, 14, 14, 14, };
int shift;
 
shift = shifts[plane];
@@ -1225,6 +1225,14 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane 
plane,
if (manual_update  dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) {
*fifo_low = ovl_fifo_size - burst_size * 2;
*fifo_high = total_fifo_size - burst_size;
+   } else if (plane == OMAP_DSS_WB) {
+   /*
+* Most optimal configuration for writeback is to push out data
+* to the interconnect the moment writeback pushes enough pixels
+* in the FIFO to form a burst
+*/
+   *fifo_low = 0;
+   *fifo_high = burst_size;
} else {
*fifo_low = ovl_fifo_size - burst_size;
*fifo_high = total_fifo_size - buf_unit;
-- 
1.7.9.5

--
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

[PATCH v2 17/18] OMAPDSS: DISPC: Add manager like functions for writeback

Add functions to enable writeback, and set/check state of GO bit. These bits are
identical in behaviour with the corresponding overlay manager bits. Configure
them in a similar way to mgr_enable() and mgr_go_* functions. Add a helper to
get the FRAMEDONE irq corresponding to writeback.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   70 +++
 drivers/video/omap2/dss/dss.h   |5 +++
 2 files changed, 75 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d6f120d..034ecb5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -536,6 +536,11 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
return mgr_desc[channel].framedone_irq;
 }
 
+u32 dispc_wb_get_framedone_irq(void)
+{
+   return DISPC_IRQ_FRAMEDONEWB;
+}
+
 bool dispc_mgr_go_busy(enum omap_channel channel)
 {
return mgr_fld_read(channel, DISPC_MGR_FLD_GO) == 1;
@@ -563,6 +568,30 @@ void dispc_mgr_go(enum omap_channel channel)
mgr_fld_write(channel, DISPC_MGR_FLD_GO, 1);
 }
 
+bool dispc_wb_go_busy(void)
+{
+   return REG_GET(DISPC_CONTROL2, 6, 6) == 1;
+}
+
+void dispc_wb_go(void)
+{
+   enum omap_plane plane = OMAP_DSS_WB;
+   bool enable, go;
+
+   enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) == 1;
+
+   if (!enable)
+   return;
+
+   go = REG_GET(DISPC_CONTROL2, 6, 6) == 1;
+   if (go) {
+   DSSERR(GO bit not down for WB\n);
+   return;
+   }
+
+   REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
+}
+
 static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32 value)
 {
dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane, reg), value);
@@ -2690,6 +2719,47 @@ void dispc_mgr_enable(enum omap_channel channel, bool 
enable)
BUG();
 }
 
+void dispc_wb_enable(bool enable)
+{
+   enum omap_plane plane = OMAP_DSS_WB;
+   struct completion frame_done_completion;
+   bool is_on;
+   int r;
+   u32 irq;
+
+   is_on = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+   irq = DISPC_IRQ_FRAMEDONEWB;
+
+   if (!enable  is_on) {
+   init_completion(frame_done_completion);
+
+   r = omap_dispc_register_isr(dispc_disable_isr,
+   frame_done_completion, irq);
+   if (r)
+   DSSERR(failed to register FRAMEDONEWB isr\n);
+   }
+
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), enable ? 1 : 0, 0, 0);
+
+   if (!enable  is_on) {
+   if (!wait_for_completion_timeout(frame_done_completion,
+   msecs_to_jiffies(100)))
+   DSSERR(timeout waiting for FRAMEDONEWB\n);
+
+   r = omap_dispc_unregister_isr(dispc_disable_isr,
+   frame_done_completion, irq);
+   if (r)
+   DSSERR(failed to unregister FRAMEDONEWB isr\n);
+   }
+}
+
+bool dispc_wb_is_enabled(void)
+{
+   enum omap_plane plane = OMAP_DSS_WB;
+
+   return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+}
+
 void dispc_lcd_enable_signal_polarity(bool act_high)
 {
if (!dss_has_feature(FEAT_LCDENABLEPOL))
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 442c06a..a71cc88 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -482,6 +482,11 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
 void dispc_mgr_setup(enum omap_channel channel,
struct omap_overlay_manager_info *info);
 
+u32 dispc_wb_get_framedone_irq(void);
+bool dispc_wb_go_busy(void);
+void dispc_wb_go(void);
+void dispc_wb_enable(bool enable);
+bool dispc_wb_is_enabled(void);
 void dispc_wb_set_channel_in(enum dss_writeback_channel channel);
 int dispc_wb_setup(const struct omap_dss_writeback_info *wi,
bool mem_to_mem, const struct omap_video_timings *timings);
-- 
1.7.9.5

--
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

[PATCH v2 18/18] OMAPDSS: DISPC: Configure color conversion coefficients for writeback

Writeback pipeline receives RGB data from one of the overlays or one of the
overlay managers. If the target color mode is YUV422 or NV12, we need to convert
the RGB pixels to YUV. The scaler in WB then converts it to the target color
mode.

Hence, the color conversion coefficients that need to be programmed are the ones
which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
pipeline.

Rearrange the code a bit to configure different coefficients for overlays and
writeback.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   61 +--
 1 file changed, 33 insertions(+), 28 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 034ecb5..1f03690 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -236,6 +236,11 @@ static const struct {
},
 };
 
+struct color_conv_coef {
+   int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
+   int full_range;
+};
+
 static void _omap_dispc_set_irqs(void);
 static unsigned long dispc_plane_pclk_rate(enum omap_plane plane);
 static unsigned long dispc_plane_lclk_rate(enum omap_plane plane);
@@ -674,41 +679,41 @@ static void dispc_ovl_set_scale_coef(enum omap_plane 
plane, int fir_hinc,
}
 }
 
-static void _dispc_setup_color_conv_coef(void)
-{
-   int i;
-   const struct color_conv_coef {
-   int  ry,  rcr,  rcb,   gy,  gcr,  gcb,   by,  bcr,  bcb;
-   int  full_range;
-   }  ctbl_bt601_5 = {
-   298,  409,0,  298, -208, -100,  298,0,  517, 0,
-   };
-
-   const struct color_conv_coef *ct;
 
+static void dispc_ovl_write_color_conv_coef(enum omap_plane plane,
+   const struct color_conv_coef *ct)
+{
 #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
 
-   ct = ctbl_bt601_5;
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 0), CVAL(ct-rcr, ct-ry));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 1), CVAL(ct-gy,  ct-rcb));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 2), CVAL(ct-gcb, ct-gcr));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 3), CVAL(ct-bcr, ct-by));
+   dispc_write_reg(DISPC_OVL_CONV_COEF(plane, 4), CVAL(0, ct-bcb));
 
-   for (i = 1; i  dss_feat_get_num_ovls(); i++) {
-   dispc_write_reg(DISPC_OVL_CONV_COEF(i, 0),
-   CVAL(ct-rcr, ct-ry));
-   dispc_write_reg(DISPC_OVL_CONV_COEF(i, 1),
-   CVAL(ct-gy,  ct-rcb));
-   dispc_write_reg(DISPC_OVL_CONV_COEF(i, 2),
-   CVAL(ct-gcb, ct-gcr));
-   dispc_write_reg(DISPC_OVL_CONV_COEF(i, 3),
-   CVAL(ct-bcr, ct-by));
-   dispc_write_reg(DISPC_OVL_CONV_COEF(i, 4),
-   CVAL(0, ct-bcb));
-
-   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(i), ct-full_range,
-   11, 11);
-   }
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), ct-full_range, 11, 11);
 
 #undef CVAL
 }
 
+static void dispc_setup_color_conv_coef(void)
+{
+   int i;
+   int num_ovl = dss_feat_get_num_ovls();
+   int num_wb = dss_feat_get_num_wbs();
+   const struct color_conv_coef ctbl_bt601_5_ovl = {
+   298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
+   };
+   const struct color_conv_coef ctbl_bt601_5_wb = {
+   66, 112, -38, 129, -94, -74, 25, -18, 112, 0,
+   };
+
+   for (i = 1; i  num_ovl; i++)
+   dispc_ovl_write_color_conv_coef(i, ctbl_bt601_5_ovl);
+
+   for (; i  num_wb; i++)
+   dispc_ovl_write_color_conv_coef(i, ctbl_bt601_5_wb);
+}
 
 static void dispc_ovl_set_ba0(enum omap_plane plane, u32 paddr)
 {
@@ -3973,7 +3978,7 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
 
-   _dispc_setup_color_conv_coef();
+   dispc_setup_color_conv_coef();
 
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
 
-- 
1.7.9.5

--
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: [PATCH] OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function

On Tue, 2012-09-25 at 11:33 +0530, Chandrabhanu Mahapatra wrote:
 The printk in DSSDBG function definition is replaced with dynamic debug 
 enabled
 pr_debug(). The use of dynamic debugging provides more flexiblity as each 
 debug
 statement can be enabled or disabled dynamically on basis of source filename,
 line number, module name etc. by writing to a control file in debugfs
 filesystem. For better undertsanding please refer to
 Documentation/dynamic-debug-howto.txt.
 
 The DSSDBGF() differs from DSSDBG() by providing function name. However,
 function name, line number, module name and thread ID can be printed through
 dynamic debug by setting appropiate flags 'f','l','m' and 't' in the debugfs
 control file. So, DSSDBGF instances are replaced with DSSDBG.

Typos with: flexiblity, undertsanding, appropiate.

 Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
 ---
  drivers/video/omap2/dss/apply.c |8 
  drivers/video/omap2/dss/dsi.c   |   12 
  drivers/video/omap2/dss/dss.h   |   34 --
  3 files changed, 16 insertions(+), 38 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
 index 6354bb8..cb86d94 100644
 --- a/drivers/video/omap2/dss/apply.c
 +++ b/drivers/video/omap2/dss/apply.c
 @@ -559,7 +559,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
   struct mgr_priv_data *mp;
   int r;
  
 - DSSDBGF(%d, ovl-id);
 + DSSDBG(%d, ovl-id);

I don't think this is good. It's true that dyn-debug can print the
function name, but that's optional. The debug message should be somehow
sensible independently, but in this case only a number is printed which
is totally meaningless.

Either the messages should be modified to give a hint what's going on,
or the DSSDBGF could be kept for now. In the above case the debug
message could be something like writing ovl %d regs.

However, I think it'd be easier just to keep the DSSDBGF for now, and
remove it gradually.

   if (!op-enabled || !op-info_dirty)
   return;
 @@ -594,7 +594,7 @@ static void dss_ovl_write_regs_extra(struct omap_overlay 
 *ovl)
   struct ovl_priv_data *op = get_ovl_priv(ovl);
   struct mgr_priv_data *mp;
  
 - DSSDBGF(%d, ovl-id);
 + DSSDBG(%d, ovl-id);
  
   if (!op-extra_info_dirty)
   return;
 @@ -618,7 +618,7 @@ static void dss_mgr_write_regs(struct 
 omap_overlay_manager *mgr)
   struct mgr_priv_data *mp = get_mgr_priv(mgr);
   struct omap_overlay *ovl;
  
 - DSSDBGF(%d, mgr-id);
 + DSSDBG(%d, mgr-id);
  
   if (!mp-enabled)
   return;
 @@ -644,7 +644,7 @@ static void dss_mgr_write_regs_extra(struct 
 omap_overlay_manager *mgr)
  {
   struct mgr_priv_data *mp = get_mgr_priv(mgr);
  
 - DSSDBGF(%d, mgr-id);
 + DSSDBG(%d, mgr-id);
  
   if (!mp-extra_info_dirty)
   return;
 diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
 index 8d815e3..8304cc6b 100644
 --- a/drivers/video/omap2/dss/dsi.c
 +++ b/drivers/video/omap2/dss/dsi.c
 @@ -1525,8 +1525,6 @@ int dsi_pll_set_clock_div(struct platform_device 
 *dsidev,
   u8 regn_start, regn_end, regm_start, regm_end;
   u8 regm_dispc_start, regm_dispc_end, regm_dsi_start, regm_dsi_end;
  
 - DSSDBGF();
 -
   dsi-current_cinfo.clkin = cinfo-clkin;
   dsi-current_cinfo.fint = cinfo-fint;
   dsi-current_cinfo.clkin4ddr = cinfo-clkin4ddr;
 @@ -2334,8 +2332,6 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
   int r;
   u32 l;
  
 - DSSDBGF();
 -
   r = dss_dsi_enable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
   if (r)
   return r;
 @@ -2686,7 +2682,7 @@ static void dsi_vc_initial_config(struct 
 platform_device *dsidev, int channel)
  {
   u32 r;
  
 - DSSDBGF(%d, channel);
 + DSSDBG(%d, channel);
  
   r = dsi_read_reg(dsidev, DSI_VC_CTRL(channel));
  
 @@ -2718,7 +2714,7 @@ static int dsi_vc_config_source(struct platform_device 
 *dsidev, int channel,
   if (dsi-vc[channel].source == source)
   return 0;
  
 - DSSDBGF(%d, channel);
 + DSSDBG(%d, channel);
  
   dsi_sync_vc(dsidev, channel);
  
 @@ -3475,7 +3471,7 @@ static int dsi_enter_ulps(struct platform_device 
 *dsidev)
   int r, i;
   unsigned mask;
  
 - DSSDBGF();
 + DSSDBG();

This debug message is even less meaningful than the overlay number =).
Again, I think either keep the DSSDBGF, or print something sensible,
like entering ULPS.

  
   WARN_ON(!dsi_bus_is_locked(dsidev));
  
 @@ -4184,7 +4180,7 @@ int omapdss_dsi_set_clocks(struct omap_dss_device 
 *dssdev,
   unsigned long pck;
   int r;
  
 - DSSDBGF(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);
 + DSSDBG(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);
  
   mutex_lock(dsi-lock);
  
 diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
 index 5e9fd769..3a2caab 100644

Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock

2012-09-25 Thread R, Sricharan

Hi Tony,

[snip..]

  index dbf1e03..2bc51fb 100644
  --- a/arch/arm/plat-omap/counter_32k.c
  +++ b/arch/arm/plat-omap/counter_32k.c
  @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
* nsecs and adds to a monotonically increasing timespec.
*/
   static struct timespec persistent_ts;
  -static cycles_t cycles, last_cycles;
  +static cycles_t cycles;
   static unsigned int persistent_mult, persistent_shift;
  +static DEFINE_SPINLOCK(read_persistent_clock_lock);
  +
   static void omap_read_persistent_clock(struct timespec *ts)
   {
  unsigned long long nsecs;
  -   cycles_t delta;
  -   struct timespec *tsp = persistent_ts;
  +   cycles_t last_cycles;
  +   unsigned long flags;
  +
  +   spin_lock_irqsave(read_persistent_clock_lock, flags);
 
  last_cycles = cycles;
  cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
  -   delta = cycles - last_cycles;
 
  -   nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
  +   nsecs = clocksource_cyc2ns(cycles - last_cycles,
  +   persistent_mult, persistent_shift);

 ..I think there's another bug here where cycles - last_cycles
 returns wrong value when the timer wraps around as cycles_t is
 64 bits and the counter is 32 bits. It seems it's been there
 since when the read_persistent_clock was added with commit
 d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?

 It seems that after this patch cycles should not be cycles_t
 but u32, and the result of cycles - last_cycles should also
 be u32.

 cycles_t is defined as  typedef unsigned long cycles_t;
 Am i missing something here ?

Thanks,
 Sricharan
--
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: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS

Hi,

On Mon, Sep 24, 2012 at 09:09:14AM -0700, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [120924 06:08]:
  Hi,
  
  On Mon, Sep 24, 2012 at 03:54:22PM +0300, Philippe De Swert wrote:
   Hi,
   
   On 24/09/2012, Felipe Balbi ba...@ti.com wrote:
SoB's mail doesn't From mail.
   
   Well still in the progress of migrating of my personal to work laptop.
   Since the patch does not seem correct the replacement will have
   matching addresses.
   
/*-*/
   
 #if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_SOC_OMAP3430) || \
-  defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500)
+  defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_ARCH_U8500) || \
+  defined(CONFIG_ARCH_OMAP2PLUS)
   
Weird, how can you build OMAP2PLUS without SOC_OMAP ??
   
   It seems entirely possible. I quickly tried to look if it got defined
   somewhere and it does not seem to be set anywhere.  That is why I got
   the impression it was replaced by CONFIG_ARCH_OMAP2PLUS. I'll dig
   deeper to find out why SOC_OMAP is not set if it should be.
   
   From the .config I got (used menuconfig)
   
   #
   # TI OMAP2/3/4 Specific Features
   #
   CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
   CONFIG_SOC_HAS_OMAP2_SDRC=y
   # CONFIG_ARCH_OMAP2 is not set
   CONFIG_ARCH_OMAP3=y
   # CONFIG_ARCH_OMAP4 is not set
   # CONFIG_SOC_OMAP5 is not set
   # CONFIG_SOC_OMAP3430 is not set
   # CONFIG_SOC_TI81XX is not set
   # CONFIG_SOC_AM33XX is not set
   CONFIG_OMAP_PACKAGE_CBB=y
   
   Not a mention of CONFIG_SOC_OMAP2430 and  CONFIG_SOC_OMAP3430 did not
   get set (while it is not a 3430 but a 3630 I am using). Maybe
   CONFIG_ARCH_OMAP3 would have been a better choice then?
  
  that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all
  OMAP3 boards ? And another question: why don't we have a matching
  SOC_OMAP3530, SOC_OMAP3630 and so on ?
 
 ARCH_OMAP3 will probably eventually just disappear and
 be replaced with ARCH_OMAP2PLUS + SOC_. But there's
 no need to do it right now as most of that should be
 internal to arch/arm/mach-omap2 anyways. I would just
 set the driver to depend on ARCH_OMAP2PLUS, and rely on
 the platform_data and DT to do something if specified.
 That means that on 2420 musb should not probe unless
 tusb6010 in specified.
 
 It seems that things like fifo_mode and generic_interrupt
 can all be set during the probe based on the platform_data
 or DT passed information?

Then maybe it's best to just remove the ifdefs and always provide
generic_interrupt() ?

Anyone against it ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
 How should I change the patch to make it proper? SA is broken anyway:

No it isn't.  This is what it produces _today_, and has done for the last
5-10 years without modification

# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_LEDS=y
CONFIG_LEDS_CPU=y

 config FORCE_MAX_ZONEORDER
 int Maximum zone order if ARCH_SHMOBILE
 range 11 64 if ARCH_SHMOBILE
 default 9 if SA
 default 11
 
 AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE,

No it doens't.

int Maximum zone order if ARCH_SHMOBILE

is far from being the same as:

int Maximum zone order
depends on ARCH_SHMOBILE

The former defines a condition upon which the option is offered in GUIs -
or to put it another way, it defines the visibility of the option.

The latter defines a dependency which must be met for the option to be
both visible and appear in the resulting configuration file.

 so SA won't be evaluated (at least if I select SA

And did you check that SA remains selected?  I bet you didn't.  Or
maybe you tested your patched version.  Whatever.  The original works,
and has been known to work for years.  Your patch breaks it.  It's
really as simple as that.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

2012-09-25 Thread Poddar, Sourav

Hi Greg,

Ping on this?

On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar sourav.pod...@ti.com wrote:
 Greg's tty-next is not booting on 2420 based N800. The failure is
 observed at serial init itself. The reason might be that n800 tries to
 resume even though it is not suspended before.

 Reported-by: Paul Walmsley p...@pwsan.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 This patch is developed on top of greg's tty-next branch
 CommitId: e740d8f tty: serial: Samsung: Fix return value +
 the following patch which I have already posted to the mailing list.
 http://comments.gmane.org/gmane.linux.ports.arm.omap/84729

  drivers/tty/serial/omap-serial.c |   11 ++-
  1 files changed, 10 insertions(+), 1 deletions(-)

 diff --git a/drivers/tty/serial/omap-serial.c 
 b/drivers/tty/serial/omap-serial.c
 index 3c05c5e..bc355f2 100644
 --- a/drivers/tty/serial/omap-serial.c
 +++ b/drivers/tty/serial/omap-serial.c
 @@ -110,6 +110,7 @@ struct uart_omap_port {
 u32 calc_latency;
 struct work_struct  qos_work;
 struct pinctrl  *pins;
 +   unsigned intsuspended:1;
  };

  #define to_uart_omap_port(p)   ((container_of((p), struct uart_omap_port, 
 port)))
 @@ -1545,14 +1546,20 @@ static int serial_omap_runtime_suspend(struct device 
 *dev)
 up-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
 schedule_work(up-qos_work);

 +   up-suspended = true;
 +
 return 0;
  }

  static int serial_omap_runtime_resume(struct device *dev)
  {
 struct uart_omap_port *up = dev_get_drvdata(dev);
 +   u32 loss_cnt;
 +
 +   if (!up-suspended)
 +   return 0;

 -   u32 loss_cnt = serial_omap_get_context_loss_count(up);
 +   loss_cnt = serial_omap_get_context_loss_count(up);

 if (up-context_loss_cnt != loss_cnt)
 serial_omap_restore_context(up);
 @@ -1560,6 +1567,8 @@ static int serial_omap_runtime_resume(struct device 
 *dev)
 up-latency = up-calc_latency;
 schedule_work(up-qos_work);

 +   up-suspended = false;
 +
 return 0;
  }
  #endif
 --
 1.7.1


~Sourav
--
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

[PATCH v2] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

2012-09-25 Thread yegorslists

From: Yegor Yefremov yegorsli...@googlemail.com

FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
of consistent DMA memory (da8xx frame buffer driver).

Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
Changes:
v2: fix SA breakage

 arch/arm/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..b5f242e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1766,8 +1766,8 @@ config HW_PERF_EVENTS
 source mm/Kconfig
 
 config FORCE_MAX_ZONEORDER
-   int Maximum zone order if ARCH_SHMOBILE
-   range 11 64 if ARCH_SHMOBILE
+   int Maximum zone order if ARCH_SHMOBILE || SOC_AM33XX
+   range 11 64 if ARCH_SHMOBILE || SOC_AM33XX
default 9 if SA
default 11
help
-- 
1.7.7

--
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: [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

2012-09-25 Thread Yegor Yefremov

On 25.09.2012 10:14, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 10:05:30AM +0200, Yegor Yefremov wrote:
 How should I change the patch to make it proper? SA is broken anyway:
 No it isn't.  This is what it produces _today_, and has done for the last
 5-10 years without modification

 # CONFIG_CLEANCACHE is not set
 # CONFIG_FRONTSWAP is not set
 CONFIG_FORCE_MAX_ZONEORDER=9
 CONFIG_LEDS=y
 CONFIG_LEDS_CPU=y

 config FORCE_MAX_ZONEORDER
 int Maximum zone order if ARCH_SHMOBILE
 range 11 64 if ARCH_SHMOBILE
 default 9 if SA
 default 11

 AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE,
 No it doens't.

   int Maximum zone order if ARCH_SHMOBILE

 is far from being the same as:

   int Maximum zone order
   depends on ARCH_SHMOBILE

 The former defines a condition upon which the option is offered in GUIs -
 or to put it another way, it defines the visibility of the option.

 The latter defines a dependency which must be met for the option to be
 both visible and appear in the resulting configuration file.

 so SA won't be evaluated (at least if I select SA
 And did you check that SA remains selected?  I bet you didn't.  Or
 maybe you tested your patched version.  Whatever.  The original works,
 and has been known to work for years.  Your patch breaks it.  It's
 really as simple as that.

Thanks for explanation. I think I've got it now. Please review the v2 version.

Yegor

--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote:
 Hi Greg,
 
 Ping on this?
 
 On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar sourav.pod...@ti.com wrote:
  Greg's tty-next is not booting on 2420 based N800. The failure is
  observed at serial init itself. The reason might be that n800 tries to
  resume even though it is not suspended before.

How is this happening?  I think that needs proper investigation - or if
it's had more investigation, then the results needs to be included in
the commit description so that everyone can understand the issue here.

We should not be resuming a device which hasn't been suspended.  Maybe
the runtime PM enable sequence is wrong, and that's what should be fixed
instead?  

This sequence in the probe() function:

pm_runtime_irq_safe(pdev-dev);
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);

would enable runtime PM while the s/w state indicates that it's disabled,
and then that pm_runtime_get_sync() will want to resume the device.  See
the section 5. Runtime PM Initialization, Device Probing and Removal
in Documentation/power/runtime_pm.txt, specifically the second paragraph
of that section.
--
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: [PATCH v2] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com
 
 FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
 of consistent DMA memory (da8xx frame buffer driver).

Okay, so the patch description says This needs to be 12 on this platform.

  config FORCE_MAX_ZONEORDER
 - int Maximum zone order if ARCH_SHMOBILE
 - range 11 64 if ARCH_SHMOBILE
 + int Maximum zone order if ARCH_SHMOBILE || SOC_AM33XX
 + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX

but you leave it up to the user to select something that may not be
suitable.  Wouldn't _just_ adding:

default 12 if SOC_AM33XX

after the range, and making no other changes be good enough and match
what the patch description says?
--
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: [PATCH] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

2012-09-25 Thread Yegor Yefremov

On 25.09.2012 02:37, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [120924 16:17]:
 On Mon, Sep 24, 2012 at 09:05:11PM +0200, Yegor Yefremov wrote:
 On Mon, Sep 24, 2012 at 7:18 PM, Tony Lindgren t...@atomide.com wrote:
 * yegorsli...@googlemail.com yegorsli...@googlemail.com [120703 07:26]:
 From: Yegor Yefremov yegorsli...@googlemail.com

 FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
 of consistent DMA memory (da8xx frame buffer driver).

 Sorry for the delay on this one, looks like this one is
 still valid. I'll apply it.

 Thanks.

 Yegor

 Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com
 Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
 ---
  arch/arm/Kconfig |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index e876819..ff14c1e 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1725,8 +1725,9 @@ config HW_PERF_EVENTS
  source mm/Kconfig

  config FORCE_MAX_ZONEORDER
 - int Maximum zone order if ARCH_SHMOBILE
 - range 11 64 if ARCH_SHMOBILE
 + int Maximum zone order
 + depends on ARCH_SHMOBILE || SOC_AM33XX
 + range 11 64 if ARCH_SHMOBILE || SOC_AM33XX
   default 9 if SA
   default 11

 NAK.  This patch breaks SA platforms.  To see why, read the patch.
 
 OK let's drop this.

How should I change the patch to make it proper? SA is broken anyway:

config FORCE_MAX_ZONEORDER
int Maximum zone order if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
default 9 if SA
default 11

AFAIK if ARCH_SHMOBILE defines dependency on ARCH_SHMOBILE, so SA won't be 
evaluated (at least if I select SA include/generated/autoconf.h shows 
11). If I add SA to dependency list like this:

depends on ARCH_SHMOBILE || SOC_AM33XX || SA

the prompt in Kernel features becomes visible, but it doesn't have the 
default value of 9, but 11.

Am I missing something?

Yegor
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 01:52:03PM +0530, Poddar, Sourav wrote:
  Hi Greg,
  
  Ping on this?
  
  On Tue, Sep 18, 2012 at 6:10 PM, Sourav Poddar sourav.pod...@ti.com wrote:
   Greg's tty-next is not booting on 2420 based N800. The failure is
   observed at serial init itself. The reason might be that n800 tries to
   resume even though it is not suspended before.
 
 How is this happening?  I think that needs proper investigation - or if
 it's had more investigation, then the results needs to be included in
 the commit description so that everyone can understand the issue here.
 
 We should not be resuming a device which hasn't been suspended.  Maybe
 the runtime PM enable sequence is wrong, and that's what should be fixed
 instead?  
 
 This sequence in the probe() function:
 
 pm_runtime_irq_safe(pdev-dev);
 pm_runtime_enable(pdev-dev);
 pm_runtime_get_sync(pdev-dev);
 
 would enable runtime PM while the s/w state indicates that it's disabled,
 and then that pm_runtime_get_sync() will want to resume the device.  See
 the section 5. Runtime PM Initialization, Device Probing and Removal
 in Documentation/power/runtime_pm.txt, specifically the second paragraph
 of that section.

that was tested. It worked in pandaboard but didn't work on beagleboard
XM. Sourav tried to start a discussion about that, but it simply died...

In any case, pm_runtime_get_sync() in probe will always call
runtime_resume callback, right ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] arm: increase FORCE_MAX_ZONEORDER for TI AM33XX

2012-09-25 Thread yegorslists

From: Yegor Yefremov yegorsli...@googlemail.com

FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
of consistent DMA memory (da8xx frame buffer driver).

Signed-off-by: Dejan Gacnik dejan.gac...@gmail.com
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
 arch/arm/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..06d489e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1768,6 +1768,7 @@ source mm/Kconfig
 config FORCE_MAX_ZONEORDER
int Maximum zone order if ARCH_SHMOBILE
range 11 64 if ARCH_SHMOBILE
+   default 12 if SOC_AM33XX
default 9 if SA
default 11
help
-- 
1.7.7

--
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: [PATCH v2] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

2012-09-25 Thread Yegor Yefremov

On 25.09.2012 10:32, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote:
 From: Yegor Yefremov yegorsli...@googlemail.com

 FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
 of consistent DMA memory (da8xx frame buffer driver).
 
 Okay, so the patch description says This needs to be 12 on this platform.
 
  config FORCE_MAX_ZONEORDER
 -int Maximum zone order if ARCH_SHMOBILE
 -range 11 64 if ARCH_SHMOBILE
 +int Maximum zone order if ARCH_SHMOBILE || SOC_AM33XX
 +range 11 64 if ARCH_SHMOBILE || SOC_AM33XX
 
 but you leave it up to the user to select something that may not be
 suitable.  Wouldn't _just_ adding:
 
   default 12 if SOC_AM33XX
 
 after the range, and making no other changes be good enough and match
 what the patch description says?

You're right. As we don't allocate anything, but increase the possible size, it 
shouldn't break anything. Tony is it O.K. with you?

Patch sent.

Yegor

--
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: [PATCH v3] ARM: OMAP4: twl-common: Support for additional devices on i2c1 bus

2012-09-25 Thread Peter Ujfalusi

Hi Tony,

On 09/24/2012 08:34 PM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [120924 08:44]:
 * Peter Ujfalusi peter.ujfal...@ti.com [120924 02:24]:
 On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
 Manufacturers can opt to use different codec than twl6040 and also can add
 audio related IC to the bus (external amplifier for example on SDP4430).

 Make it possible to add different set of additional devices to i2c1 bus on
 OMAP4 boards.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
 Hi Tony,

 I have refreshed the patch on top of arm-soc/for-next branch. Would it be
 possible to queue this patch via arm-soc so it will be in 3.7-rc1 already?
 Originally this patch was sent for 3.6...

 Yes sorry the platform code has been been badly ignored
 lately.. Let's see if we can still get it in now that there's
 -rc7 tagged.
 
 I've updated this for the sparse IRQ changes that remove irqs.h.
 Updated patch below.

Looks good to me.

Thank you,
Péter

 
 Tony
 
 
 From: Peter Ujfalusi peter.ujfal...@ti.com
 Date: Mon, 24 Sep 2012 12:24:48 +0300
 Subject: [PATCH] ARM: OMAP4: twl-common: Support for additional devices on
  i2c1 bus
 
 On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices.
 Manufacturers can opt to use different codec than twl6040 and also can add
 audio related IC to the bus (external amplifier for example on SDP4430).
 
 Make it possible to add different set of additional devices to i2c1 bus on
 OMAP4 boards.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 [t...@atomide.com: updated for removal of irqs.h]
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index e82098f..749ce96 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -545,6 +545,14 @@ static struct twl6040_platform_data twl6040_data = {
   .audpwron_gpio  = 127,
  };
  
 +static struct i2c_board_info __initdata sdp4430_i2c_1_boardinfo[] = {
 + {
 + I2C_BOARD_INFO(twl6040, 0x4b),
 + .irq = 119 + OMAP44XX_IRQ_GIC_START,
 + .platform_data = twl6040_data,
 + },
 +};
 +
  static struct twl4030_platform_data sdp4430_twldata = {
   /* Regulators */
   .vusim  = sdp4430_vusim,
 @@ -578,8 +586,8 @@ static int __init omap4_i2c_init(void)
   TWL_COMMON_REGULATOR_CLK32KG |
   TWL_COMMON_REGULATOR_V1V8 |
   TWL_COMMON_REGULATOR_V2V1);
 - omap4_pmic_init(twl6030, sdp4430_twldata,
 - twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
 + omap4_pmic_init(twl6030, sdp4430_twldata, sdp4430_i2c_1_boardinfo,
 + ARRAY_SIZE(sdp4430_i2c_1_boardinfo));
   omap_register_i2c_bus(2, 400, NULL, 0);
   omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
   ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index 45fe2d3..7b592d3 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -264,6 +264,14 @@ static struct twl6040_platform_data twl6040_data = {
   .audpwron_gpio  = 127,
  };
  
 +static struct i2c_board_info __initdata panda_i2c_1_boardinfo[] = {
 + {
 + I2C_BOARD_INFO(twl6040, 0x4b),
 + .irq = 119 + OMAP44XX_IRQ_GIC_START,
 + .platform_data = twl6040_data,
 + },
 +};
 +
  /* Panda board uses the common PMIC configuration */
  static struct twl4030_platform_data omap4_panda_twldata;
  
 @@ -291,8 +299,8 @@ static int __init omap4_panda_i2c_init(void)
   TWL_COMMON_REGULATOR_CLK32KG |
   TWL_COMMON_REGULATOR_V1V8 |
   TWL_COMMON_REGULATOR_V2V1);
 - omap4_pmic_init(twl6030, omap4_panda_twldata,
 - twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
 + omap4_pmic_init(twl6030, omap4_panda_twldata, panda_i2c_1_boardinfo,
 + ARRAY_SIZE(panda_i2c_1_boardinfo));
   omap_register_i2c_bus(2, 400, NULL, 0);
   /*
* Bus 3 is attached to the DVI port where devices like the pico DLP
 diff --git a/arch/arm/mach-omap2/twl-common.c 
 b/arch/arm/mach-omap2/twl-common.c
 index 99be94e..af93acc 100644
 --- a/arch/arm/mach-omap2/twl-common.c
 +++ b/arch/arm/mach-omap2/twl-common.c
 @@ -40,16 +40,6 @@ static struct i2c_board_info __initdata 
 pmic_i2c_board_info = {
   .flags  = I2C_CLIENT_WAKE,
  };
  
 -static struct i2c_board_info __initdata omap4_i2c1_board_info[] = {
 - {
 - .addr   = 0x48,
 - .flags  = I2C_CLIENT_WAKE,
 - },
 - {
 - I2C_BOARD_INFO(twl6040, 0x4b),
 - },
 -};
 -
  #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
  static int twl_set_voltage(void *data, int target_uV)

Re: query on [PATCH 2/3] usb: otg: add device tree support to otg library

2012-09-25 Thread Marc Kleine-Budde

Hi Afzal,

On 09/25/2012 10:47 AM, Mohammed, Afzal wrote:
 This is a query regarding patch,
 usb: otg: add device tree support to otg library [1]
 
 It seems there is so far no consensus on this change.

After I have posted this patch, Kishon had posted a better solution [2].
We discussed the patch, but he has not posted any updates since then.

 Do you have ideas to proceed on this ? is there something
 that I can help you to proceed on this ?

I'm interested in to get these patches into the kernel soon. Kishon any
news on this patch?

 Something like this would be required for USB support
 on beagle bone (AM335X), which has 2 phy's of same type.
 
 Or is the plan to use generic phy framework instead ?

Yes, Kishon's patches look more generic than mine.

Marc

[2] https://patchwork.kernel.org/patch/1457801/
-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] usb: Include generic_interrupt for OMAP2_PLUS

2012-09-25 Thread Philippe De Swert

Hi,
On 25/09/2012, Felipe Balbi ba...@ti.com wrote:
   Not a mention of CONFIG_SOC_OMAP2430 and  CONFIG_SOC_OMAP3430 did not
   get set (while it is not a 3430 but a 3630 I am using). Maybe
   CONFIG_ARCH_OMAP3 would have been a better choice then?
 
  that's quite f**ked up. Tony, why doesn't SOC_OMAP3430 get set for all
  OMAP3 boards ? And another question: why don't we have a matching
  SOC_OMAP3530, SOC_OMAP3630 and so on ?

 ARCH_OMAP3 will probably eventually just disappear and
 be replaced with ARCH_OMAP2PLUS + SOC_. But there's
 no need to do it right now as most of that should be
 internal to arch/arm/mach-omap2 anyways. I would just
 set the driver to depend on ARCH_OMAP2PLUS, and rely on
 the platform_data and DT to do something if specified.
 That means that on 2420 musb should not probe unless
 tusb6010 in specified.

 It seems that things like fifo_mode and generic_interrupt
 can all be set during the probe based on the platform_data
 or DT passed information?

 Then maybe it's best to just remove the ifdefs and always provide
 generic_interrupt() ?

 Anyone against it ?

Well it seems there are only two drivers that use it omap2430 and
ux500. Maybe we somehow link it to the drivers that need it? (I might
have missed other drivers but it looks like it is just those two)

Regards,

Philippe
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
 On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
  How is this happening?  I think that needs proper investigation - or if
  it's had more investigation, then the results needs to be included in
  the commit description so that everyone can understand the issue here.
  
  We should not be resuming a device which hasn't been suspended.  Maybe
  the runtime PM enable sequence is wrong, and that's what should be fixed
  instead?  
  
  This sequence in the probe() function:
  
  pm_runtime_irq_safe(pdev-dev);
  pm_runtime_enable(pdev-dev);
  pm_runtime_get_sync(pdev-dev);
  
  would enable runtime PM while the s/w state indicates that it's disabled,
  and then that pm_runtime_get_sync() will want to resume the device.  See
  the section 5. Runtime PM Initialization, Device Probing and Removal
  in Documentation/power/runtime_pm.txt, specifically the second paragraph
  of that section.
 
 that was tested. It worked in pandaboard but didn't work on beagleboard
 XM. Sourav tried to start a discussion about that, but it simply died...
 
 In any case, pm_runtime_get_sync() in probe will always call
 runtime_resume callback, right ?

Well, if the runtime PM state says it's suspended, and then you enable
runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
attempt.  The patch description is complaining about resume events without
there being a preceding suspend event.

This could well be why.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
  On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
   How is this happening?  I think that needs proper investigation - or if
   it's had more investigation, then the results needs to be included in
   the commit description so that everyone can understand the issue here.
   
   We should not be resuming a device which hasn't been suspended.  Maybe
   the runtime PM enable sequence is wrong, and that's what should be fixed
   instead?  
   
   This sequence in the probe() function:
   
   pm_runtime_irq_safe(pdev-dev);
   pm_runtime_enable(pdev-dev);
   pm_runtime_get_sync(pdev-dev);
   
   would enable runtime PM while the s/w state indicates that it's disabled,
   and then that pm_runtime_get_sync() will want to resume the device.  See
   the section 5. Runtime PM Initialization, Device Probing and Removal
   in Documentation/power/runtime_pm.txt, specifically the second paragraph
   of that section.
  
  that was tested. It worked in pandaboard but didn't work on beagleboard
  XM. Sourav tried to start a discussion about that, but it simply died...
  
  In any case, pm_runtime_get_sync() in probe will always call
  runtime_resume callback, right ?
 
 Well, if the runtime PM state says it's suspended, and then you enable
 runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
 attempt.  The patch description is complaining about resume events without
 there being a preceding suspend event.
 
 This could well be why.

that's most likely, of course. But should we cause a regression to
beagleboard XM because of that ? Also, if you look into chapter 9 of the
runtime_pm documentation, starting on line 822 you'll see documentation
suggests the use of mystruct-is_suspended flag.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
 On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
  On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
   On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
How is this happening?  I think that needs proper investigation - or if
it's had more investigation, then the results needs to be included in
the commit description so that everyone can understand the issue here.

We should not be resuming a device which hasn't been suspended.  Maybe
the runtime PM enable sequence is wrong, and that's what should be fixed
instead?  

This sequence in the probe() function:

pm_runtime_irq_safe(pdev-dev);
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);

would enable runtime PM while the s/w state indicates that it's 
disabled,
and then that pm_runtime_get_sync() will want to resume the device.  See
the section 5. Runtime PM Initialization, Device Probing and Removal
in Documentation/power/runtime_pm.txt, specifically the second paragraph
of that section.
   
   that was tested. It worked in pandaboard but didn't work on beagleboard
   XM. Sourav tried to start a discussion about that, but it simply died...
   
   In any case, pm_runtime_get_sync() in probe will always call
   runtime_resume callback, right ?
  
  Well, if the runtime PM state says it's suspended, and then you enable
  runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
  attempt.  The patch description is complaining about resume events without
  there being a preceding suspend event.
  
  This could well be why.
 
 that's most likely, of course. But should we cause a regression to
 beagleboard XM because of that ?

What would cause a regression on beagleboard XM?  I have not suggested
any change other than more investigation of the issue and a fuller patch
description - yet you're screaming (idiotically IMHO) that mere
investigation would break beagleboard.

Well, if it's _that_ fragile, that mere investigation of this issue by
someone elsewhere on the planet would break your beagleboard, maybe it
deserves to be broken!
--
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: [PATCH] OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function

2012-09-25 Thread Mahapatra, Chandrabhanu

 diff --git a/drivers/video/omap2/dss/apply.c 
 b/drivers/video/omap2/dss/apply.c
 index 6354bb8..cb86d94 100644
 --- a/drivers/video/omap2/dss/apply.c
 +++ b/drivers/video/omap2/dss/apply.c
 @@ -559,7 +559,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
   struct mgr_priv_data *mp;
   int r;

 - DSSDBGF(%d, ovl-id);
 + DSSDBG(%d, ovl-id);

 I don't think this is good. It's true that dyn-debug can print the
 function name, but that's optional. The debug message should be somehow
 sensible independently, but in this case only a number is printed which
 is totally meaningless.

 Either the messages should be modified to give a hint what's going on,
 or the DSSDBGF could be kept for now. In the above case the debug
 message could be something like writing ovl %d regs.

 However, I think it'd be easier just to keep the DSSDBGF for now, and
 remove it gradually.

   if (!op-enabled || !op-info_dirty)
   return;
 @@ -594,7 +594,7 @@ static void dss_ovl_write_regs_extra(struct omap_overlay 
 *ovl)
   struct ovl_priv_data *op = get_ovl_priv(ovl);
   struct mgr_priv_data *mp;

 - DSSDBGF(%d, ovl-id);
 + DSSDBG(%d, ovl-id);

   if (!op-extra_info_dirty)
   return;
 @@ -618,7 +618,7 @@ static void dss_mgr_write_regs(struct 
 omap_overlay_manager *mgr)
   struct mgr_priv_data *mp = get_mgr_priv(mgr);
   struct omap_overlay *ovl;

 - DSSDBGF(%d, mgr-id);
 + DSSDBG(%d, mgr-id);

   if (!mp-enabled)
   return;
 @@ -644,7 +644,7 @@ static void dss_mgr_write_regs_extra(struct 
 omap_overlay_manager *mgr)
  {
   struct mgr_priv_data *mp = get_mgr_priv(mgr);

 - DSSDBGF(%d, mgr-id);
 + DSSDBG(%d, mgr-id);

   if (!mp-extra_info_dirty)
   return;
 diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
 index 8d815e3..8304cc6b 100644
 --- a/drivers/video/omap2/dss/dsi.c
 +++ b/drivers/video/omap2/dss/dsi.c
 @@ -1525,8 +1525,6 @@ int dsi_pll_set_clock_div(struct platform_device 
 *dsidev,
   u8 regn_start, regn_end, regm_start, regm_end;
   u8 regm_dispc_start, regm_dispc_end, regm_dsi_start, regm_dsi_end;

 - DSSDBGF();
 -
   dsi-current_cinfo.clkin = cinfo-clkin;
   dsi-current_cinfo.fint = cinfo-fint;
   dsi-current_cinfo.clkin4ddr = cinfo-clkin4ddr;
 @@ -2334,8 +2332,6 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
   int r;
   u32 l;

 - DSSDBGF();
 -
   r = dss_dsi_enable_pads(dsi-module_id, dsi_get_lane_mask(dssdev));
   if (r)
   return r;
 @@ -2686,7 +2682,7 @@ static void dsi_vc_initial_config(struct 
 platform_device *dsidev, int channel)
  {
   u32 r;

 - DSSDBGF(%d, channel);
 + DSSDBG(%d, channel);

   r = dsi_read_reg(dsidev, DSI_VC_CTRL(channel));

 @@ -2718,7 +2714,7 @@ static int dsi_vc_config_source(struct platform_device 
 *dsidev, int channel,
   if (dsi-vc[channel].source == source)
   return 0;

 - DSSDBGF(%d, channel);
 + DSSDBG(%d, channel);

   dsi_sync_vc(dsidev, channel);

 @@ -3475,7 +3471,7 @@ static int dsi_enter_ulps(struct platform_device 
 *dsidev)
   int r, i;
   unsigned mask;

 - DSSDBGF();
 + DSSDBG();

 This debug message is even less meaningful than the overlay number =).
 Again, I think either keep the DSSDBGF, or print something sensible,
 like entering ULPS.


I dont think it would be wise enough to update code for one and keep
the older version for another when both DSSDBG and DSSDBGF are almost
one and the same. Its better to add something meaningful to the prints
as you have mentioned like writing ovl %d regs and DSI entering
ULPS.


   WARN_ON(!dsi_bus_is_locked(dsidev));

 @@ -4184,7 +4180,7 @@ int omapdss_dsi_set_clocks(struct omap_dss_device 
 *dssdev,
   unsigned long pck;
   int r;

 - DSSDBGF(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);
 + DSSDBG(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);

   mutex_lock(dsi-lock);

 diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
 index 5e9fd769..3a2caab 100644
 --- a/drivers/video/omap2/dss/dss.h
 +++ b/drivers/video/omap2/dss/dss.h
 @@ -29,38 +29,20 @@

  #ifdef DEBUG
  extern bool dss_debug;

 You still left the dss_debug option here, even if it's not used by the
 DSSDBG anymore. What's your plan about this?

  Tomi


dss_debug and DEBUG need to remain here as it is being used by
functions omap_dispc_irq_handler() and _dsi_print_reset_status() in
dispc.c and dsi.c. I am little bit unsure of how to deal with it.
There could be a single print in omap_dispc_irq_handler() but it is a
bit tricky in _dsi_print_reset_status().

May be a macro like this one can be used in _dsi_print_reset_status()

#define DSI_FLD_GET(fld, start, end)\
  FLD_GET(dsi_read_reg(dsidev, DSI_##fld), start, end);

pr_debug(PLL (%d) CIO (%d) \n PHY (%x%x%x, %d, %d, %d) \n,
 DSI_FLD_GET(PLL_STATUS, 0, 0),

[PATCHv5 00/10] ARM: OMAP: PM usecounting changes

Hi,

Changes compared to previous version:

- Fixed OMAP4 support (patches 7-10)
- Dropped debugging support from this set for now
- Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code
  (omap4 support easier to test with these)
- Patch #1:
  * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs
  * clkdm_clk_enable / disable are used now instead
  * some code ordering changed for the new setup to work properly
  * changed BUG_ON calls to WARN_ON
- Patch #2:
  * added spinlock for protecting voltdm callbacks
  * pwrdm lock extended to protect pwrdm callbacks
- Patch #3:
  * dropped generic API call for the cpu pwrdm idle / wakeup
  * instead use pwrdm_clkdm_enable / disable calls directly from PM code
  * omap4 support fixed to work properly with SMP, added omap4 specific
CPU pwrdm idle / wakeup calls for this purpose
- Patch #4:
  * no changes
  * added 'Reviewed-by' tag for Rajendra
- Patch #5:
  * no changes, just rebase
- Patch #6:
  * no changes

Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards.

I will be posting new versions for the voltdm fixes + auto retention +
panda board tps6236x support code later on today, which are based on top
of this set.

Branch also available here:

git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.6-rc5-pwrdm-changes-v5

-Tero


--
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

[PATCHv5 01/10] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking

This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/clkt_iclk.c |   21 ++
 arch/arm/mach-omap2/clockdomain.c   |   15 -
 arch/arm/mach-omap2/dpll3xxx.c  |   19 
 arch/arm/mach-omap2/powerdomain.c   |   35 +++
 arch/arm/mach-omap2/powerdomain.h   |4 +++
 arch/arm/plat-omap/clock.c  |6 +
 arch/arm/plat-omap/include/plat/clock.h |2 +
 7 files changed, 101 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..1afc599 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
 #include clock2xxx.h
 #include cm2xxx_3xxx.h
 #include cm-regbits-24xx.h
+#include clockdomain.h
 
 /* Private functions */
 
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1  clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+   /* Remove this clock from parent clockdomain usecounts */
+   if (clk-usecount  clk-clkdm)
+   clkdm_clk_disable(clk-clkdm, clk);
+
+   /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+   clk-autoidle = true;
 }
 
 /* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v = ~(1  clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+   /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+   clk-autoidle = false;
+
+   /* Add clock back to parent clockdomain usecount */
+   if (clk-usecount  clk-clkdm)
+   clkdm_clk_enable(clk-clkdm, clk);
 }
 
 /* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..8c8518c 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -910,6 +910,7 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
 static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
 {
unsigned long flags;
+   int usecount;
 
if (!clkdm || !arch_clkdm || !arch_clkdm-clkdm_clk_enable)
return -EINVAL;
@@ -919,11 +920,14 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain 
*clkdm)
 * should be called for every clock instance or hwmod that is
 * enabled, so the clkdm can be force woken up.
 */
-   if ((atomic_inc_return(clkdm-usecount)  1)  autodeps)
+   usecount = atomic_inc_return(clkdm-usecount);
+   if (usecount  1  autodeps)
return 0;
 
spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_enable(clkdm);
+   if (usecount == 1)
+   pwrdm_clkdm_enable(clkdm-pwrdm.ptr);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
 
@@ -949,6 +953,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain 
*clkdm)
 
spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_disable(clkdm);
+   pwrdm_clkdm_disable(clkdm-pwrdm.ptr);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
 
@@ -981,6 +986,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk 
*clk)
if (!clk)
return -EINVAL;
 
+   /* If autoidle clock, do not update clkdm usecounts */
+   if (clk-autoidle)
+   return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
 }
 
@@ -1007,6 +1016,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct 
clk *clk)
if (!clk)
return -EINVAL;
 
+   /* If autoidle clock, do not update clkdm usecounts */
+   if (clk-autoidle)
+   return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
 }
 
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index b9c8d2f..da660d2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,7 @@
 #include clock.h
 #include cm2xxx_3xxx.h
 #include cm-regbits-34xx.h
+#include clockdomain.h
 
 /* CM_AUTOIDLE_PLL*.AUTO_* bit values */
 #define DPLL_AUTOIDLE_DISABLE  0x0
@@ -571,6 +572,15 @@ void omap3_dpll_allow_idle(struct clk *clk)
v |= DPLL_AUTOIDLE_LOW_POWER_STOP

[PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts

These are updated based on powerdomain usecounts. Also added support
for voltdm-sleep and voltdm-wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |   17 +-
 arch/arm/mach-omap2/voltage.c |   62 +
 arch/arm/mach-omap2/voltage.h |   13 
 3 files changed, 91 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index ba49029..ca54aec 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
  */
 void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
 {
+   unsigned long flags;
+
if (!pwrdm)
return;
 
-   atomic_inc(pwrdm-usecount);
+   if (atomic_inc_return(pwrdm-usecount) == 1) {
+   spin_lock_irqsave(pwrdm-lock, flags);
+   voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
+   spin_unlock_irqrestore(pwrdm-lock, flags);
+   }
 }
 
 /**
@@ -1492,12 +1500,19 @@ void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
 void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
 {
int val;
+   unsigned long flags;
 
if (!pwrdm)
return;
 
val = atomic_dec_return(pwrdm-usecount);
 
+   if (!val) {
+   spin_lock_irqsave(pwrdm-lock, flags);
+   voltdm_pwrdm_disable(pwrdm-voltdm.ptr);
+   spin_unlock_irqrestore(pwrdm-lock, flags);
+   }
+
WARN_ON(val  0);
 }
 
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4dc60e8..9eb1a4b 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -340,6 +340,67 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct 
powerdomain *pwrdm)
 }
 
 /**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain-wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+   unsigned long flags;
+
+   if (!voltdm)
+   return;
+
+   if (atomic_inc_return(voltdm-usecount) == 1  voltdm-wakeup) {
+   spin_lock_irqsave(voltdm-lock, flags);
+   voltdm-wakeup(voltdm);
+   spin_unlock_irqrestore(voltdm-lock, flags);
+   }
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain-sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+   u8 target_state = PWRDM_POWER_OFF;
+   int state;
+   struct powerdomain *pwrdm;
+   int val;
+   unsigned long flags;
+
+   if (!voltdm)
+   return;
+
+   val = atomic_dec_return(voltdm-usecount);
+
+   WARN_ON(val  0);
+
+   if (val == 0) {
+   spin_lock_irqsave(voltdm-lock, flags);
+   /* Determine target state for voltdm */
+   list_for_each_entry(pwrdm, voltdm-pwrdm_list, voltdm_node) {
+   state = pwrdm_read_next_pwrst(pwrdm);
+   if (state  target_state)
+   target_state = state;
+   }
+   voltdm-target_state = target_state;
+   if (voltdm-sleep)
+   voltdm-sleep(voltdm);
+   spin_unlock_irqrestore(voltdm-lock, flags);
+   }
+}
+
+/**
  * voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
  * @voltdm: struct voltagedomain * to iterate over
  * @fn: callback function *
@@ -402,6 +463,7 @@ static int _voltdm_register(struct voltagedomain *voltdm)
INIT_LIST_HEAD(voltdm-pwrdm_list);
list_add(voltdm-node, voltdm_list);
 
+   spin_lock_init(voltdm-lock);
pr_debug(voltagedomain: registered %s\n, voltdm-name);
 
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 0ac2caf..7f4f99d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -15,6 +15,7 @@
 #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
 
 #include linux/err.h
+#include linux/spinlock.h
 
 #include plat/voltage.h
 
@@ -56,10 +57,14 @@ struct omap_vfsm_instance {
  * @pwrdm_list: list_head linking all powerdomains in this voltagedomain
  * @vc:

[PATCHv5 03/10] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting

mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/common.h  |6 ++
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   72 -
 arch/arm/mach-omap2/omap-smp.c|2 +
 arch/arm/mach-omap2/pm34xx.c  |   21 
 4 files changed, 100 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 6ea837a..a445a02 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -292,6 +292,8 @@ extern int omap4_finish_suspend(unsigned long cpu_state);
 extern void omap4_cpu_resume(void);
 extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
 extern u32 omap4_mpuss_read_prev_context_state(void);
+extern void omap4_pm_cpu_online(void);
+extern void omap4_pm_cpu_offline(void);
 #else
 static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -323,6 +325,10 @@ static inline u32 omap4_mpuss_read_prev_context_state(void)
 {
return 0;
 }
+
+static inline void omap4_pm_cpu_online(void) { }
+
+static inline void omap4_pm_cpu_offline(void) { }
 #endif
 
 struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 230bdcd..0ad2337 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -72,8 +72,9 @@ struct omap4_cpu_pm_info {
 };
 
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
-static struct powerdomain *mpuss_pd;
+static struct powerdomain *mpuss_pd, *core_pd;
 static void __iomem *sar_base;
+static atomic_t __initdata init_cpu_online_count;
 
 /*
  * Program the wakeup routine address for the CPU0 and CPU1
@@ -216,6 +217,50 @@ static void save_l2x0_context(void)
 #endif
 
 /**
+ * omap4_pm_cpu_online - increase the number of online CPUs
+ *
+ * This function increases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is increased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_online(void)
+{
+   if (!mpuss_pd || !core_pd) {
+   atomic_inc(init_cpu_online_count);
+   return;
+   }
+
+   pwrdm_clkdm_enable(mpuss_pd);
+   pwrdm_clkdm_enable(core_pd);
+}
+
+/**
+ * omap4_pm_cpu_offline - decrease the number of online CPUs
+ *
+ * This function decreases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is decreased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_offline(void)
+{
+   if (!mpuss_pd || !core_pd) {
+   atomic_dec(init_cpu_online_count);
+   return;
+   }
+
+   pwrdm_clkdm_disable(mpuss_pd);
+   pwrdm_clkdm_disable(core_pd);
+}
+
+/**
  * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
  * The purpose of this function is to manage low power programming
  * of OMAP4 MPUSS subsystem
@@ -274,11 +319,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int 
power_state)
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
 
+   /* Decrement usecounts for MPU and CORE pd as we are entering idle */
+   omap4_pm_cpu_offline();
+
/*
 * Call low level function  with targeted low power state.
 */
cpu_suspend(save_state, omap4_finish_suspend);
 
+   /* Increment usecounts for MPU and CORE pd as we are leaving idle */
+   omap4_pm_cpu_online();
+
/*
 * Restore the CPUx power state to ON otherwise CPUx
 * power domain can transitions to programmed low power
@@ -315,6 +366,8 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned 
int power_state)
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));

[PATCHv5 05/10] ARM: OMAP: clockdomain: add support for preventing autodep delete

Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c |3 +++
 arch/arm/mach-omap2/clockdomain.h |4 
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 8c8518c..2fa433a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -201,6 +201,9 @@ void _clkdm_del_autodeps(struct clockdomain *clkdm)
if (!autodeps || clkdm-flags  CLKDM_NO_AUTODEPS)
return;
 
+   if (clkdm-flags  CLKDM_NO_AUTODEP_DISABLE)
+   return;
+
for (autodep = autodeps; autodep-clkdm.ptr; autodep++) {
if (IS_ERR(autodep-clkdm.ptr))
continue;
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 5601dc1..9b8733e 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -34,6 +34,9 @@
  * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
  * active whenever the MPU is active.  True for interconnects and
  * the WKUP clockdomains.
+ * CLKDM_NO_AUTODEP_DISABLE: Prevent clockdomain code from deleting autodeps.
+ * Needed for PER domain on omap3, as it will bug out with off-mode if
+ * wakedeps are removed.
  */
 #define CLKDM_CAN_FORCE_SLEEP  (1  0)
 #define CLKDM_CAN_FORCE_WAKEUP (1  1)
@@ -41,6 +44,7 @@
 #define CLKDM_CAN_DISABLE_AUTO (1  3)
 #define CLKDM_NO_AUTODEPS  (1  4)
 #define CLKDM_ACTIVE_WITH_MPU  (1  5)
+#define CLKDM_NO_AUTODEP_DISABLE   (1  6)
 
 #define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO | 
CLKDM_CAN_DISABLE_AUTO)
 #define CLKDM_CAN_SWSUP(CLKDM_CAN_FORCE_SLEEP | 
CLKDM_CAN_FORCE_WAKEUP)
-- 
1.7.4.1

--
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

[PATCHv5 04/10] ARM: OMAP3: set autoidle flag for sdrc_ick

sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm-sleep / wakeup calls to work properly.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/clock3xxx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..1ddc7fc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1739,6 +1739,7 @@ static struct clk sdrc_ick = {
.flags  = ENABLE_ON_INIT,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
+   .autoidle   = true,
 };
 
 static struct clk gpmc_fck = {
-- 
1.7.4.1

--
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

[PATCHv5 06/10] ARM: OMAP3: do not delete per_clkdm autodeps during idle

Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which means its autodeps are deleted.
Removing wakedeps for PER domain will cause multiple problems.
First of all, coming back from idle, PER domain remains idle as the
wakedeps have been disabled for the domain, and this causes a crash
with the GPIO code, as the resume code attempts to access domain
which is not active. Just enabling the interface clocks for the GPIO
does not help, as they are autoidled and don't bring the domain out
of idle. Secondly, there are multiple erratas for omap3, which say
that the wakedeps should be enabled for the PER domain, see e.g.
errata i582 for omap3630.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c 
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 56089c4..3b3c524 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -370,7 +370,7 @@ static struct clockdomain usbhost_am35x_clkdm = {
 static struct clockdomain per_clkdm = {
.name   = per_clkdm,
.pwrdm  = { .name = per_pwrdm },
-   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP | CLKDM_NO_AUTODEP_DISABLE,
.dep_bit= OMAP3430_EN_PER_SHIFT,
.wkdep_srcs = per_wkdeps,
.sleepdep_srcs  = per_sleepdeps,
-- 
1.7.4.1

--
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

[PATCHv5 08/10] ARM: OMAP4: hwmod: add support for hwmod autoidle flag

If a hwmod is in HWAUTO mode, it will idle automatically and should not
be accounted for in the clkdm / pwrdm usecounts. Thus, flag modules in
such mode as autoidle during init, and ignore these in subsequent
usecount calculations.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c|6 ++
 arch/arm/mach-omap2/omap_hwmod.c |3 +++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 2fa433a..0ee7d09a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1055,6 +1055,9 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
+   if (oh-flags  HWMOD_AUTOIDLE)
+   return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
 }
 
@@ -1086,6 +1089,9 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
+   if (oh-flags  HWMOD_AUTOIDLE)
+   return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
 }
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f826917..6807b02 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2377,6 +2377,9 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(oh-slave_ports);
spin_lock_init(oh-_lock);
 
+   if (cpu_is_omap44xx()  oh-prcm.omap4.modulemode == MODULEMODE_HWCTRL)
+   oh-flags |= HWMOD_AUTOIDLE;
+
oh-_state = _HWMOD_STATE_REGISTERED;
 
/*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0f840a9..36130f9 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -440,6 +440,7 @@ struct omap_hwmod_omap4_prcm {
  * in order to complete the reset. Optional clocks will be disabled
  * again after the reset.
  * HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_AUTOIDLE: Module is controlled automatically by hardware
  */
 #define HWMOD_SWSUP_SIDLE  (1  0)
 #define HWMOD_SWSUP_MSTANDBY   (1  1)
@@ -450,6 +451,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_IDLEST(1  6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1  7)
 #define HWMOD_16BIT_REG(1  8)
+#define HWMOD_AUTOIDLE (1  9)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.7.4.1

--
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

[PATCHv5 07/10] ARM: OMAP4: clock data: set autoidle flag for dss_fck

dss_fck is currently being used improperly within the hwmod database
as an interface clock for DSS hwmods. This causes the dss_fck to
be enabled even if the dss powerdomain itself is idle, resulting
in wrong data within the powerdomain usecounts. Marked dss_fck as
autoidle which makes the clock to disappear from usecounts for now.
This patch can be reverted once the interface clocks for DSS hwmods
have been properly fixed.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..95834d7 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1408,6 +1408,7 @@ static struct clk dss_fck = {
.clkdm_name = l3_dss_clkdm,
.parent = l3_div_ck,
.recalc = followparent_recalc,
+   .autoidle   = true,
 };
 
 static struct clk efuse_ctrl_cust_fck = {
-- 
1.7.4.1

--
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

[PATCHv5 09/10] ARM: OMAP4: hwmod data: set mpu hwmod modulemode to hwauto

This makes sure it is handled as autoidle type by the usecounting.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2d13b33..367de25 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2492,6 +2492,7 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MPU_MPU_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
},
},
 };
-- 
1.7.4.1

--
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

[PATCHv5 10/10] ARM: OMAP4: clock data: flag hw controlled clocks as autoidle

This makes sure these clocks are ignored by the clkdm / pwrdm usecounting.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 95834d7..d2fb4e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3356,8 +3356,11 @@ int __init omap4xxx_clk_init(void)
 */
 
for (c = omap44xx_clks; c  omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
- c++)
+ c++) {
+   if (c-lk.clk-enable_bit == OMAP4430_MODULEMODE_HWCTRL)
+   c-lk.clk-autoidle = true;
clk_preinit(c-lk.clk);
+   }
 
for (c = omap44xx_clks; c  omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
  c++)
-- 
1.7.4.1

--
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: [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts

On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
 diff --git a/arch/arm/mach-omap2/powerdomain.c 
 b/arch/arm/mach-omap2/powerdomain.c
 index ba49029..ca54aec 100644
 --- a/arch/arm/mach-omap2/powerdomain.c
 +++ b/arch/arm/mach-omap2/powerdomain.c
 @@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
   */
  void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
  {
 + unsigned long flags;
 +
   if (!pwrdm)
   return;
  
 - atomic_inc(pwrdm-usecount);
 + if (atomic_inc_return(pwrdm-usecount) == 1) {
 + spin_lock_irqsave(pwrdm-lock, flags);
 + voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
 + spin_unlock_irqrestore(pwrdm-lock, flags);
 + }

This looks like the classic I like atomic types because they have magic
properties brain-deadness.

What would happen to users of this if you had this sequence:

pwrdm-usecount starts off as 1.

Thread0 Thread1
atomic_inc_return() (returns 1)
atomic_inc_return() (returns 2)
starts using stuff in power domain
spin_lock_irqsave()
voltdm_pwrdm_enable()
spin_unlock_irqrestore()

?
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

Hi,

On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
  On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
   On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux 
wrote:
 How is this happening?  I think that needs proper investigation - or 
 if
 it's had more investigation, then the results needs to be included in
 the commit description so that everyone can understand the issue here.
 
 We should not be resuming a device which hasn't been suspended.  Maybe
 the runtime PM enable sequence is wrong, and that's what should be 
 fixed
 instead?  
 
 This sequence in the probe() function:
 
 pm_runtime_irq_safe(pdev-dev);
 pm_runtime_enable(pdev-dev);
 pm_runtime_get_sync(pdev-dev);
 
 would enable runtime PM while the s/w state indicates that it's 
 disabled,
 and then that pm_runtime_get_sync() will want to resume the device.  
 See
 the section 5. Runtime PM Initialization, Device Probing and Removal
 in Documentation/power/runtime_pm.txt, specifically the second 
 paragraph
 of that section.

that was tested. It worked in pandaboard but didn't work on beagleboard
XM. Sourav tried to start a discussion about that, but it simply died...

In any case, pm_runtime_get_sync() in probe will always call
runtime_resume callback, right ?
   
   Well, if the runtime PM state says it's suspended, and then you enable
   runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
   attempt.  The patch description is complaining about resume events without
   there being a preceding suspend event.
   
   This could well be why.
  
  that's most likely, of course. But should we cause a regression to
  beagleboard XM because of that ?
 
 What would cause a regression on beagleboard XM?  I have not suggested
 any change other than more investigation of the issue and a fuller patch
 description - yet you're screaming (idiotically IMHO) that mere
 investigation would break beagleboard.
 
 Well, if it's _that_ fragile, that mere investigation of this issue by
 someone elsewhere on the planet would break your beagleboard, maybe it
 deserves to be broken!

why are you always so over the top like that ? This is just
counter-productive to say the least.

What I'm trying to say here, is that there might be a bug either on pm
core or on OMAP3's implementation and I'd like to get input from Tony,
Santosh, Paul, etc before going forward. Maybe it's something they've
already been through, or maybe it rings a bell and points to somewhere
we should look for.

anyway, instead of feeding your ego, we can stop this discussion and let
Sourav see what he can come up with.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

2012-09-25 Thread Poddar, Sourav

Hi,

On Tue, Sep 25, 2012 at 2:51 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux wrote:
How is this happening? I think that needs proper investigation - or if
it's had more investigation, then the results needs to be included in
the commit description so that everyone can understand the issue here.

We should not be resuming a device which hasn't been suspended. Maybe
the runtime PM enable sequence is wrong, and that's what should be
fixed
instead?

This sequence in the probe() function:

pm_runtime_irq_safe(pdev-dev);
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);

would enable runtime PM while the s/w state indicates that it's
disabled,
and then that pm_runtime_get_sync() will want to resume the device.
See
the section 5. Runtime PM Initialization, Device Probing and Removal
in Documentation/power/runtime_pm.txt, specifically the second
paragraph
of that section.

that was tested. It worked in pandaboard but didn't work on beagleboard
XM. Sourav tried to start a discussion about that, but it simply died...

In any case, pm_runtime_get_sync() in probe will always call
runtime_resume callback, right ?

Well, if the runtime PM state says it's suspended, and then you enable
runtime PM, the first call to pm_runtime_get_sync() will trigger a resume
attempt. The patch description is complaining about resume events without
there being a preceding suspend event.

This could well be why.

that's most likely, of course. But should we cause a regression to
beagleboard XM because of that ?

What would cause a regression on beagleboard XM? I have not suggested
any change other than more investigation of the issue and a fuller patch
description - yet you're screaming (idiotically IMHO) that mere
investigation would break beagleboard.

Well, if it's _that_ fragile, that mere investigation of this issue by
someone elsewhere on the planet would break your beagleboard, maybe it
deserves to be broken!

The issue was observed at serial init itself in the N800 board and the
log does not
show up much.
http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt
What we thought the problem might be with n800 is that it tries to
resume when it didn't suspend before.

There are two ways through which we thought of handling this issue:

a) set device as active before enabling pm (which will prevent

pm_runtime_set_active(dev);
pm_runtime_enable(dev);

b) adding a suspended flag to struct omap_uart_port which gets set on
suspend and cleared on resume. Then on resume you can check:

if (!up-suspended)
return 0;

But using pm_runtime_set_active approach breaks things even on
beagle board xm, though
it works fine on Panda.
Therefore, we used the suspended flag approach.

So. I just wanted to get some feedback from community about how using
pm_runtime_set_active
behaves differently in omap3 and omap4.
--
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: [PATCH] OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function

On Tue, 2012-09-25 at 15:00 +0530, Mahapatra, Chandrabhanu wrote:

  This debug message is even less meaningful than the overlay number =).
  Again, I think either keep the DSSDBGF, or print something sensible,
  like entering ULPS.
 
 
 I dont think it would be wise enough to update code for one and keep
 the older version for another when both DSSDBG and DSSDBGF are almost
 one and the same. Its better to add something meaningful to the prints
 as you have mentioned like writing ovl %d regs and DSI entering
 ULPS.

I didn't mean to leave DSSDBGF unchanged. I meant that it should work as
it works now, printing the func name, but using pr_debug.

 
WARN_ON(!dsi_bus_is_locked(dsidev));
 
  @@ -4184,7 +4180,7 @@ int omapdss_dsi_set_clocks(struct omap_dss_device 
  *dssdev,
unsigned long pck;
int r;
 
  - DSSDBGF(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);
  + DSSDBG(ddr_clk %lu, lp_clk %lu, ddr_clk, lp_clk);
 
mutex_lock(dsi-lock);
 
  diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
  index 5e9fd769..3a2caab 100644
  --- a/drivers/video/omap2/dss/dss.h
  +++ b/drivers/video/omap2/dss/dss.h
  @@ -29,38 +29,20 @@
 
   #ifdef DEBUG
   extern bool dss_debug;
 
  You still left the dss_debug option here, even if it's not used by the
  DSSDBG anymore. What's your plan about this?
 
   Tomi
 
 
 dss_debug and DEBUG need to remain here as it is being used by
 functions omap_dispc_irq_handler() and _dsi_print_reset_status() in

It would be good to clean all this in one patch series.

 dispc.c and dsi.c. I am little bit unsure of how to deal with it.
 There could be a single print in omap_dispc_irq_handler() but it is a
 bit tricky in _dsi_print_reset_status().
 
 May be a macro like this one can be used in _dsi_print_reset_status()
 
 #define DSI_FLD_GET(fld, start, end)\
   FLD_GET(dsi_read_reg(dsidev, DSI_##fld), start, end);
 
 pr_debug(PLL (%d) CIO (%d) \n PHY (%x%x%x, %d, %d, %d) \n,
  DSI_FLD_GET(PLL_STATUS, 0, 0),
  DSI_FLD_GET(COMPLEXIO_CFG1, 29, 29),
  DSI_FLD_GET(DSIPHY_CFG5, bo, bo),
  DSI_FLD_GET(DSIPHY_CFG5, b1, b1),
..);
 This could be defined at the beginning of the function and later at its end.

Yes, I think something like that could work. I don't see any problem
with having temporary helper macros to help creating the debug message.

 As you had previously mentioned a print like
 
 #define PIS(x) (status  DSI_IRQ_##x) ? (#x  ) : 
 
 pr_debug(DSI IRQ: 0x%x: %s%s%s,
 status,
 PIS(WAKEUP),
 PIS(RESYNC),
 PIS(PLL_LOCK));
 
 could help in print_irq_status() but I am still unsure how to deal
 with conditional statements in print_irq_status() like
 if (dss_has_feature(FEAT_MGR_LCD3))
 PIS(SYNC_LOST3);
 Should we use approach like
 
 pr_debug(DSI IRQ: 0x%x: %s%s%s%s...,
 status,
 PIS(WAKEUP),
 PIS(RESYNC),
 PIS(PLL_LOCK)
 dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : 
   .. );

Yes, that looks fine to me.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/5] drivers: usb: phy: add a new driver for omap usb2 phy

2012-09-25 Thread ABRAHAM, KISHON VIJAY

Hi,

On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote:
 On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote:
 All phy related programming like enabling/disabling the clocks, powering
 on/off the phy is taken care of by this driver. It is also used for OTG
 related functionality like srp.

 This also includes device tree support for usb2 phy driver and
 the documentation with device tree binding information is updated.

 Currently writing to control module register is taken care in this
 driver which will be removed once the control module driver is in place.

 Cc: Felipe Balbi ba...@ti.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  Documentation/devicetree/bindings/usb/usb-phy.txt |   17 ++
  drivers/usb/phy/Kconfig   |9 +
  drivers/usb/phy/Makefile  |1 +
  drivers/usb/phy/omap-usb2.c   |  271 
 +
  include/linux/usb/omap_usb.h  |   46 
  include/linux/usb/phy_companion.h |   34 +++
  6 files changed, 378 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt
  create mode 100644 drivers/usb/phy/omap-usb2.c
  create mode 100644 include/linux/usb/omap_usb.h
  create mode 100644 include/linux/usb/phy_companion.h

 diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
 b/Documentation/devicetree/bindings/usb/usb-phy.txt
 new file mode 100644
 index 000..80d4148
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt

 This is a very generic name...

 @@ -0,0 +1,17 @@
 +USB PHY
 +
 +OMAP USB2 PHY
 +
 +Required properties:
 + - compatible: Should be ti,omap-usb2

 ...for a specific phy. However, I do think a generic binding to describe
 host ctrlr to phy connections is needed.

 + - reg : Address and length of the register set for the device. Also
 +add the address of control module dev conf register until a driver for
 +control module is added

 The dts should describe the h/w, not what you need for the current
 driver. The 2nd reg field does not belong here.

Indeed. This was discussed and agreed upon as a interim solution till
we have a control module driver in place to write to the control
module register.

 +
 +This is usually a subnode of ocp2scp to which it is connected.

 How is usb port to phy connection described?
Currently the usb controller to phy connection is established only by
type. We have a couple of patches being currently discussed in the
list to establish the connection by phandle.

https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework:
devm_of_phy_get())
http://www.spinics.net/lists/linux-usb/msg69547.html

Thanks
Kishon
--
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

Powering OMAP's pins

Hi Tony,

Each pin of OMAP requires a particular power to be enabled for the pin
to function (Ball Characteristics table from data manual). Is there a
plan how this is managed with pinctrl? Currently each driver needs to
make sure the correct regulators are enabled for the pins it uses, which
is platform specific and messy.

As a driver maintainer, I would wish that the pins would just get
enabled automatically when I call pm_runtime_get()...

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes

2012-09-25 Thread Rajendra Nayak


Hi Tero,

On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:

Hi,

Changes compared to previous version:


Did you get a chance to look at the issue I reported about autodeps?
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html

regards,
Rajendra



- Fixed OMAP4 support (patches 7-10)
- Dropped debugging support from this set for now
- Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code
   (omap4 support easier to test with these)
- Patch #1:
   * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs
   * clkdm_clk_enable / disable are used now instead
   * some code ordering changed for the new setup to work properly
   * changed BUG_ON calls to WARN_ON
- Patch #2:
   * added spinlock for protecting voltdm callbacks
   * pwrdm lock extended to protect pwrdm callbacks
- Patch #3:
   * dropped generic API call for the cpu pwrdm idle / wakeup
   * instead use pwrdm_clkdm_enable / disable calls directly from PM code
   * omap4 support fixed to work properly with SMP, added omap4 specific
 CPU pwrdm idle / wakeup calls for this purpose
- Patch #4:
   * no changes
   * added 'Reviewed-by' tag for Rajendra
- Patch #5:
   * no changes, just rebase
- Patch #6:
   * no changes

Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards.

I will be posting new versions for the voltdm fixes + auto retention +
panda board tps6236x support code later on today, which are based on top
of this set.

Branch also available here:

git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.6-rc5-pwrdm-changes-v5

-Tero


--
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



--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 12:48:16PM +0300, Felipe Balbi wrote:
 Hi,
 
 On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote:
  On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
   On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux wrote:
On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
 On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux 
 wrote:
  How is this happening?  I think that needs proper investigation - 
  or if
  it's had more investigation, then the results needs to be included 
  in
  the commit description so that everyone can understand the issue 
  here.
  
  We should not be resuming a device which hasn't been suspended.  
  Maybe
  the runtime PM enable sequence is wrong, and that's what should be 
  fixed
  instead?  
  
  This sequence in the probe() function:
  
  pm_runtime_irq_safe(pdev-dev);
  pm_runtime_enable(pdev-dev);
  pm_runtime_get_sync(pdev-dev);
  
  would enable runtime PM while the s/w state indicates that it's 
  disabled,
  and then that pm_runtime_get_sync() will want to resume the device. 
   See
  the section 5. Runtime PM Initialization, Device Probing and 
  Removal
  in Documentation/power/runtime_pm.txt, specifically the second 
  paragraph
  of that section.
 
 that was tested. It worked in pandaboard but didn't work on 
 beagleboard
 XM. Sourav tried to start a discussion about that, but it simply 
 died...
 
 In any case, pm_runtime_get_sync() in probe will always call
 runtime_resume callback, right ?

Well, if the runtime PM state says it's suspended, and then you enable
runtime PM, the first call to pm_runtime_get_sync() will trigger a 
resume
attempt.  The patch description is complaining about resume events 
without
there being a preceding suspend event.

This could well be why.
   
   that's most likely, of course. But should we cause a regression to
   beagleboard XM because of that ?
  
  What would cause a regression on beagleboard XM?  I have not suggested
  any change other than more investigation of the issue and a fuller patch
  description - yet you're screaming (idiotically IMHO) that mere
  investigation would break beagleboard.
  
  Well, if it's _that_ fragile, that mere investigation of this issue by
  someone elsewhere on the planet would break your beagleboard, maybe it
  deserves to be broken!
 
 why are you always so over the top like that ? This is just
 counter-productive to say the least.

Because you are accusing me of potentially breaking your beagleboard
for merely suggesting further investigation and a better commit message.

You are the one going over the top, not me.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 12:48:16PM +0300, Felipe Balbi wrote:
  Hi,
  
  On Tue, Sep 25, 2012 at 10:21:18AM +0100, Russell King - ARM Linux wrote:
   On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
On Tue, Sep 25, 2012 at 10:12:28AM +0100, Russell King - ARM Linux 
wrote:
 On Tue, Sep 25, 2012 at 11:31:20AM +0300, Felipe Balbi wrote:
  On Tue, Sep 25, 2012 at 09:30:29AM +0100, Russell King - ARM Linux 
  wrote:
   How is this happening?  I think that needs proper investigation - 
   or if
   it's had more investigation, then the results needs to be 
   included in
   the commit description so that everyone can understand the issue 
   here.
   
   We should not be resuming a device which hasn't been suspended.  
   Maybe
   the runtime PM enable sequence is wrong, and that's what should 
   be fixed
   instead?  
   
   This sequence in the probe() function:
   
   pm_runtime_irq_safe(pdev-dev);
   pm_runtime_enable(pdev-dev);
   pm_runtime_get_sync(pdev-dev);
   
   would enable runtime PM while the s/w state indicates that it's 
   disabled,
   and then that pm_runtime_get_sync() will want to resume the 
   device.  See
   the section 5. Runtime PM Initialization, Device Probing and 
   Removal
   in Documentation/power/runtime_pm.txt, specifically the second 
   paragraph
   of that section.
  
  that was tested. It worked in pandaboard but didn't work on 
  beagleboard
  XM. Sourav tried to start a discussion about that, but it simply 
  died...
  
  In any case, pm_runtime_get_sync() in probe will always call
  runtime_resume callback, right ?
 
 Well, if the runtime PM state says it's suspended, and then you enable
 runtime PM, the first call to pm_runtime_get_sync() will trigger a 
 resume
 attempt.  The patch description is complaining about resume events 
 without
 there being a preceding suspend event.
 
 This could well be why.

that's most likely, of course. But should we cause a regression to
beagleboard XM because of that ?
   
   What would cause a regression on beagleboard XM?  I have not suggested
   any change other than more investigation of the issue and a fuller patch
   description - yet you're screaming (idiotically IMHO) that mere
   investigation would break beagleboard.
   
   Well, if it's _that_ fragile, that mere investigation of this issue by
   someone elsewhere on the planet would break your beagleboard, maybe it
   deserves to be broken!
  
  why are you always so over the top like that ? This is just
  counter-productive to say the least.
 
 Because you are accusing me of potentially breaking your beagleboard
 for merely suggesting further investigation and a better commit message.

Where did I accuse you of anyting ? I just mentioned we experienced a
regression with beagleboard XM when using pm_runtime_set_active().

here's my quote:

 that was tested. It worked in pandaboard but didn't work on
 beagleboard XM. Sourav tried to start a discussion about that, but it
 simply died...

To add extra info, here you go:

We pinged Paul and asked if he had seen that before, he had no
pointers... Because Documentation/power/runtime_pm.txt was using a
mystruct-is_suspended flag, we just decided to follow the same
design since no-one was able to suggest why pm_runtime_set_active()
was breaking beagleXM nor how it was supposed to actually work.

Reading the code: pm_runtime_set_active() would tell pm_runtime core
the device is actually active by setting runtime_status to RPM_ACTIVE,
thus the following pm_runtime_get_sync() wouldn't actually call
runtime_resume() callback, but it would increment usage_counter.

I can't see why this would fail on beagleXM, but it does and we'd like
to hear in which situations this could fail...

-- 
balbi


signature.asc
Description: Digital signature

Re: query on [PATCH 2/3] usb: otg: add device tree support to otg library

2012-09-25 Thread ABRAHAM, KISHON VIJAY

Hi,

On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de wrote:
 Hi Afzal,

 On 09/25/2012 10:47 AM, Mohammed, Afzal wrote:
 This is a query regarding patch,
 usb: otg: add device tree support to otg library [1]

 It seems there is so far no consensus on this change.

 After I have posted this patch, Kishon had posted a better solution [2].
 We discussed the patch, but he has not posted any updates since then.

 Do you have ideas to proceed on this ? is there something
 that I can help you to proceed on this ?

 I'm interested in to get these patches into the kernel soon. Kishon any
 news on this patch?

 Something like this would be required for USB support
 on beagle bone (AM335X), which has 2 phy's of same type.

 Or is the plan to use generic phy framework instead ?

 Yes, Kishon's patches look more generic than mine.
Will post the next version by this week.

Thanks
Kishon
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

Right, let's get this thread back onto a constructive footing and try
to understand the problems here.

On Tue, Sep 25, 2012 at 03:26:06PM +0530, Poddar, Sourav wrote:
The issue was observed at serial init itself in the N800 board and the
log does not show up much.
http://www.pwsan.com/omap/testlogs/test_tty_next_e36851d0/20120910020323/boot/2420n800/2420n800_log.txt

Right, so output stops when ttyO2 is initialized.

What we thought the problem might be with n800 is that it tries to
resume when it didn't suspend before.

There are two ways through which we thought of handling this issue:

a) set device as active before enabling pm (which will prevent

pm_runtime_set_active(dev);
pm_runtime_enable(dev);

b) adding a suspended flag to struct omap_uart_port which gets set on
suspend and cleared on resume. Then on resume you can check:

if (!up-suspended)
return 0;

But using pm_runtime_set_active approach breaks things even on
beagle board xm, though it works fine on Panda.

Right, so now the question becomes - what is different on the Beagle Board
that prevents solution (a) from working - or put it another way, have we
uncovered _another_ bug.

For N800, for ttyO0 and ttyO1 which aren't in use, it may be correct.
We don't know for certain. For ttyO2, the port is clearly already in
use as it's being used for console output. So that means it's _not_
in suspended state, and therefore the initial runtime PM state is
wrong.

For Beagleboard - who knows, we have no information on that. All we
know is that your (a) sequence causes a regression.

Anyway, let's analyse the code paths. What is pm_runtime_get_sync()
doing? Well, it calls __pm_runtime_resume(, RPM_GET_PUT). That alters
the parent device's state (which doesn't matter for this, as the platform
device is a child of the main platform device, which has no runtime PM.)

It then calls the resume callback (from the pm domain/type/class/bus/
driver) and then does an idle check.

OMAP devices have a pm domain, so this is the candidate for the callback
at this level, which gets us into _od_runtime_resume(). This calls
omap_device_enable() before then moving on to the driver's runtime resume
method, and at that point the runtime PM resume is complete.

So, with your (a) solution, what's different is that we omit calling
omap_device_enable(). Therefore, my hunch is the reason that Beagleboard
doesn't work is because it doesn't like missing that call.

I bet if you do this:

omap_device_enable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);

that this will solve your problem, and Beagleboard will continue working.

What we have is a mismatch in both your case, and the Beagleboard case,
between the real state of the hardware, the runtime PM state, and the
OMAP hwmod state, and the above should bring all those states entirely
into line with each other for _every_ case. It doesn't need any hacks
to prevent resume callbacks without prior suspends (which, incidentally,
the runtime PM core already guarantees provided you get the initial
state correct.)
--
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: query on [PATCH 2/3] usb: otg: add device tree support to otg library

2012-09-25 Thread Mohammed, Afzal

On Tue, Sep 25, 2012 at 16:21:39, ABRAHAM, KISHON VIJAY wrote:
 On Tue, Sep 25, 2012 at 2:24 PM, Marc Kleine-Budde m...@pengutronix.de 
 wrote:

  I'm interested in to get these patches into the kernel soon. Kishon any
  news on this patch?
 
  Something like this would be required for USB support
  on beagle bone (AM335X), which has 2 phy's of same type.
 
  Or is the plan to use generic phy framework instead ?
 
  Yes, Kishon's patches look more generic than mine.
 Will post the next version by this week.

Thanks Marc and Kishon

Regards
Afzal

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 01:37:03PM +0300, Felipe Balbi wrote:
 On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote:
  Because you are accusing me of potentially breaking your beagleboard
  for merely suggesting further investigation and a better commit message.
 
 Where did I accuse you of anyting ? I just mentioned we experienced a
 regression with beagleboard XM when using pm_runtime_set_active().

I quote:
: But should we cause a regression to beagleboard XM because of that ?
   

I say again: I was _only_ suggesting further investigation, yet you
were mouthing off about causing a regression to beagleboard because
of that, effectively saying that no, we should not do any further
investigation and this is the only fix.

 To add extra info, here you go:

Finally, something constructive.

 We pinged Paul and asked if he had seen that before, he had no
 pointers... Because Documentation/power/runtime_pm.txt was using a
 mystruct-is_suspended flag, we just decided to follow the same
 design since no-one was able to suggest why pm_runtime_set_active()
 was breaking beagleXM nor how it was supposed to actually work.
 
 Reading the code: pm_runtime_set_active() would tell pm_runtime core
 the device is actually active by setting runtime_status to RPM_ACTIVE,
 thus the following pm_runtime_get_sync() wouldn't actually call
 runtime_resume() callback, but it would increment usage_counter.
 
 I can't see why this would fail on beagleXM, but it does and we'd like
 to hear in which situations this could fail...

Well, I've just spent five minutes analysing the code paths - which I
hadn't looked at before - and I've pointed out what's probably causing
the problem for Beagle.  I think you owe me an appology over your
aggressive attitude towards my suggestions that there needed to be
some further investigation.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 12:11:14PM +0300, Felipe Balbi wrote:
 that's most likely, of course. But should we cause a regression to
 beagleboard XM because of that ? Also, if you look into chapter 9 of the
 runtime_pm documentation, starting on line 822 you'll see documentation
 suggests the use of mystruct-is_suspended flag.

BTW, I'll point out a fatal flaw in your justification above.

If you read the entire example, you'll see that the is_suspended flag
is _not_ used to prevent resumes without suspends, but is used as a
flag to control whether the driver processes requests or not.  That's
entirely functionally different from using a is_suspended flag in
the way you mention above.

Section 5 is quite clear about the requirements at initialization time
for runtime PM, and nothing in section 9 contradicts that, and the
is_suspended flag in that example has nothing to do with any of this.
--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

Hi,

On Tue, Sep 25, 2012 at 12:07:03PM +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 01:37:03PM +0300, Felipe Balbi wrote:
  On Tue, Sep 25, 2012 at 11:29:58AM +0100, Russell King - ARM Linux wrote:
   Because you are accusing me of potentially breaking your beagleboard
   for merely suggesting further investigation and a better commit message.
  
  Where did I accuse you of anyting ? I just mentioned we experienced a
  regression with beagleboard XM when using pm_runtime_set_active().
 
 I quote:
 : But should we cause a regression to beagleboard XM because of that ?


maybe that wasn't the best way to put it, but I was trying to point out
that either there was a bug on pm core or omap_device/hwmod, not that we
shouldn't investigate.

 I say again: I was _only_ suggesting further investigation, yet you
 were mouthing off about causing a regression to beagleboard because
 of that, effectively saying that no, we should not do any further
 investigation and this is the only fix.

not what I meant, but fair enough... The because of that was supposed
to mean because of pm_runtime_set_active(). I find the documentation
for that particular call to be rather poor and a bit confusing,
specially when further down, the very same document uses a
is_suspended flag which, in fact, shouldn't be needed when we have
pm_runtime_is_suspended() and the like.

  We pinged Paul and asked if he had seen that before, he had no
  pointers... Because Documentation/power/runtime_pm.txt was using a
  mystruct-is_suspended flag, we just decided to follow the same
  design since no-one was able to suggest why pm_runtime_set_active()
  was breaking beagleXM nor how it was supposed to actually work.
  
  Reading the code: pm_runtime_set_active() would tell pm_runtime core
  the device is actually active by setting runtime_status to RPM_ACTIVE,
  thus the following pm_runtime_get_sync() wouldn't actually call
  runtime_resume() callback, but it would increment usage_counter.
  
  I can't see why this would fail on beagleXM, but it does and we'd like
  to hear in which situations this could fail...
 
 Well, I've just spent five minutes analysing the code paths - which I
 hadn't looked at before - and I've pointed out what's probably causing
 the problem for Beagle.  I think you owe me an appology over your
 aggressive attitude towards my suggestions that there needed to be
 some further investigation.

I don't see any aggressive attitude towards what you suggested,
actually. Mailing list archives are available to check, but the one
cursing around was always yourself and THAT deserves an apology.

If you still think I've been at all aggressive, then sure, I apologize,
it wasn't what I meant though.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

On Tue, Sep 25, 2012 at 02:12:43PM +0300, Felipe Balbi wrote:
 I don't see any aggressive attitude towards what you suggested,
 actually. Mailing list archives are available to check, but the one
 cursing around was always yourself and THAT deserves an apology.

Total rubbish.  No apology, because I wasn't cursing you.  Whatever,
I'm not going to re-explain the email thread.

What I said was that your raising of beagleboard breakage (twice) was
idiotic to a request for investigation.  That's a statement I _still_
fully agree with, and I'll say it again if I have to.

Trying to shut down investigation because investigation may break
something _is_ idiotic - especially if the investigation reveals
potential reasons why that breakage would occur.  Further investigation
is precisely how we arrive at better solutions.
--
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: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes

On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote:
 Hi Tero,
 
 On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:
  Hi,
 
  Changes compared to previous version:
 
 Did you get a chance to look at the issue I reported about autodeps?
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html

Not really, I didn't think that bug report was meant for me, I kind of
thought it only happened with your set. But now looking at your email in
detail, I guess you are saying there is a bug in this code (the one that
touches iclk stuff), which causes the USB / DSS domains to follow
MPU/CORE, is that right?

-Tero

 
 regards,
 Rajendra
 
 
  - Fixed OMAP4 support (patches 7-10)
  - Dropped debugging support from this set for now
  - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code
 (omap4 support easier to test with these)
  - Patch #1:
 * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs
 * clkdm_clk_enable / disable are used now instead
 * some code ordering changed for the new setup to work properly
 * changed BUG_ON calls to WARN_ON
  - Patch #2:
 * added spinlock for protecting voltdm callbacks
 * pwrdm lock extended to protect pwrdm callbacks
  - Patch #3:
 * dropped generic API call for the cpu pwrdm idle / wakeup
 * instead use pwrdm_clkdm_enable / disable calls directly from PM code
 * omap4 support fixed to work properly with SMP, added omap4 specific
   CPU pwrdm idle / wakeup calls for this purpose
  - Patch #4:
 * no changes
 * added 'Reviewed-by' tag for Rajendra
  - Patch #5:
 * no changes, just rebase
  - Patch #6:
 * no changes
 
  Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards.
 
  I will be posting new versions for the voltdm fixes + auto retention +
  panda board tps6236x support code later on today, which are based on top
  of this set.
 
  Branch also available here:
 
  git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
  branch: mainline-3.6-rc5-pwrdm-changes-v5
 
  -Tero
 
 
  --
  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
 
 


--
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: [PATCHv5 02/10] ARM: OMAP3+: voltage: add support for voltagedomain usecounts

On Tue, 2012-09-25 at 10:41 +0100, Russell King - ARM Linux wrote:
 On Tue, Sep 25, 2012 at 12:32:37PM +0300, Tero Kristo wrote:
  diff --git a/arch/arm/mach-omap2/powerdomain.c 
  b/arch/arm/mach-omap2/powerdomain.c
  index ba49029..ca54aec 100644
  --- a/arch/arm/mach-omap2/powerdomain.c
  +++ b/arch/arm/mach-omap2/powerdomain.c
  @@ -1475,10 +1477,16 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
*/
   void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
   {
  +   unsigned long flags;
  +
  if (!pwrdm)
  return;
   
  -   atomic_inc(pwrdm-usecount);
  +   if (atomic_inc_return(pwrdm-usecount) == 1) {
  +   spin_lock_irqsave(pwrdm-lock, flags);
  +   voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
  +   spin_unlock_irqrestore(pwrdm-lock, flags);
  +   }
 
 This looks like the classic I like atomic types because they have magic
 properties brain-deadness.

Hi Russell,

Thats a good catch, I was actually thinking about this sequence myself
also, but decided to leave it as is here due to similarity with the
existing code in mach-omap2/clockdomain.c, see e.g.
_clkdm_clk_hwmod_enable. Maybe those parts should be fixed also...?

 
 What would happen to users of this if you had this sequence:
 
 pwrdm-usecount starts off as 1.
 
 Thread0   Thread1
 atomic_inc_return() (returns 1)
   atomic_inc_return() (returns 2)
   starts using stuff in power domain
 spin_lock_irqsave()
 voltdm_pwrdm_enable()
 spin_unlock_irqrestore()
 
 ?

That as such wouldn't break anything, as the callback isn't doing
anything too critical, but yes, for the sequencing of events it is bad.
The alternate implementation I was thinking was to drop the atomic_t and
just use an int for the usecount, and protect the usecount also with the
spinlock. However, there might be some performance issues if this is
done (but I think it is actually better than having some rather
mysterious bugs instead.)

-Tero


--
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: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes

2012-09-25 Thread Rajendra Nayak


On Tuesday 25 September 2012 05:23 PM, Tero Kristo wrote:

On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote:

Hi Tero,

On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:

Hi,

Changes compared to previous version:


Did you get a chance to look at the issue I reported about autodeps?
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html


Not really, I didn't think that bug report was meant for me, I kind of
thought it only happened with your set. But now looking at your email in
detail, I guess you are saying there is a bug in this code (the one that
touches iclk stuff), which causes the USB / DSS domains to follow
MPU/CORE, is that right?


Yes, basically the autodeps remain set, even while the module is not in
use at all, which causes them to come in and out of sleep along with MPU.



-Tero



regards,
Rajendra



- Fixed OMAP4 support (patches 7-10)
- Dropped debugging support from this set for now
- Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code
(omap4 support easier to test with these)
- Patch #1:
* dropped clkdm_usecount_inc / clkdm_usecount_dec APIs
* clkdm_clk_enable / disable are used now instead
* some code ordering changed for the new setup to work properly
* changed BUG_ON calls to WARN_ON
- Patch #2:
* added spinlock for protecting voltdm callbacks
* pwrdm lock extended to protect pwrdm callbacks
- Patch #3:
* dropped generic API call for the cpu pwrdm idle / wakeup
* instead use pwrdm_clkdm_enable / disable calls directly from PM code
* omap4 support fixed to work properly with SMP, added omap4 specific
  CPU pwrdm idle / wakeup calls for this purpose
- Patch #4:
* no changes
* added 'Reviewed-by' tag for Rajendra
- Patch #5:
* no changes, just rebase
- Patch #6:
* no changes

Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards.

I will be posting new versions for the voltdm fixes + auto retention +
panda board tps6236x support code later on today, which are based on top
of this set.

Branch also available here:

git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.6-rc5-pwrdm-changes-v5

-Tero


--
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








--
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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

2012-09-25 Thread Jassi Brar

On 19 September 2012 17:29, Felipe Balbi ba...@ti.com wrote:

 this is what I mean, actually. If we remove pm_runtime_get_sync() in
 exchange for pm_runtime_set_active() before pm_runtime_enable(), it
 works on PandaBoard, but breaks BeagleBoard.

Perhaps it suggests that OMAP4 (PandaBoard) serial port is already
activated but OMAP3 (BeagleBoard) isn't. So we need to reflect that
either by doing pm_runtime_set_active() only on OMAP4 or by bringing
up the OMAP3 too before the pm_runtime_set_active() call.
BTW I understand get_sync(), set_active() and enable() are for
different purposes, they can't be traded for one another.
--
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: [PATCH] OMAPDSS: DISPC: Add predecimation limit for TILER based rotations

On Mon, 2012-09-24 at 12:08 +0530, Chandrabhanu Mahapatra wrote:
 In OMAP4 and OMAP5 when TILER 2D burst mode is used, a maximum of one line can
 be skipped as per the respective TRMs. The MBlockStride OCP signal, which is
 sum of ROWINC and image width in memory, is only 17 bits wide. In 2D mode 
 TILER
 supports 8192, 16384, 32768 and 65536 values of MBlockStride. In case when 2 
 or
 more lines are skipped the ROWINC value exceeds 65536 resulting in OCP errors.
 So, maximum vertical predecimation achievable is 2.
 
 Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
 ---
  drivers/video/omap2/dss/dispc.c |9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

Thanks, looks fine to me.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCHv5 00/10] ARM: OMAP: PM usecounting changes

On Tue, 2012-09-25 at 17:53 +0530, Rajendra Nayak wrote:
 On Tuesday 25 September 2012 05:23 PM, Tero Kristo wrote:
  On Tue, 2012-09-25 at 15:56 +0530, Rajendra Nayak wrote:
  Hi Tero,
 
  On Tuesday 25 September 2012 03:02 PM, Tero Kristo wrote:
  Hi,
 
  Changes compared to previous version:
 
  Did you get a chance to look at the issue I reported about autodeps?
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg72876.html
 
  Not really, I didn't think that bug report was meant for me, I kind of
  thought it only happened with your set. But now looking at your email in
  detail, I guess you are saying there is a bug in this code (the one that
  touches iclk stuff), which causes the USB / DSS domains to follow
  MPU/CORE, is that right?
 
 Yes, basically the autodeps remain set, even while the module is not in
 use at all, which causes them to come in and out of sleep along with MPU.

Actually I think I accidentally fixed this problem with the latest rev,
due to the fact that I am using generic clkdm_clk_enable / disable calls
from iclk now.

I also just tested this (while fixing the complaint from Russell), and
it looks like both USB and DSS pwrdms are remaining nicely idle on
OMAP3.

-Tero

 
 
  -Tero
 
 
  regards,
  Rajendra
 
 
  - Fixed OMAP4 support (patches 7-10)
  - Dropped debugging support from this set for now
  - Rebased on top of 3.6-rc5 + func-pwrst + omap4-ret code
  (omap4 support easier to test with these)
  - Patch #1:
  * dropped clkdm_usecount_inc / clkdm_usecount_dec APIs
  * clkdm_clk_enable / disable are used now instead
  * some code ordering changed for the new setup to work properly
  * changed BUG_ON calls to WARN_ON
  - Patch #2:
  * added spinlock for protecting voltdm callbacks
  * pwrdm lock extended to protect pwrdm callbacks
  - Patch #3:
  * dropped generic API call for the cpu pwrdm idle / wakeup
  * instead use pwrdm_clkdm_enable / disable calls directly from PM code
  * omap4 support fixed to work properly with SMP, added omap4 specific
CPU pwrdm idle / wakeup calls for this purpose
  - Patch #4:
  * no changes
  * added 'Reviewed-by' tag for Rajendra
  - Patch #5:
  * no changes, just rebase
  - Patch #6:
  * no changes
 
  Tested with OMAP3 beagle, omap4460 GP panda + omap4430 EMU blaze boards.
 
  I will be posting new versions for the voltdm fixes + auto retention +
  panda board tps6236x support code later on today, which are based on top
  of this set.
 
  Branch also available here:
 
  git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
  branch: mainline-3.6-rc5-pwrdm-changes-v5
 
  -Tero
 
 
  --
  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
 
 
 
 
 


--
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: [PATCH v2 10/18] OMAPDSS: DISPC: Configure input and output sizes for writeback

On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
 Writeback uses the WB_PICTURE_SIZE register to define the size of the content
 written to memory, this is the output of the scaler. It uses the WB_SIZE
 register to define the size of the content coming from the overlay/manager to
 which it is connected, this is the input to the scaler. This naming is 
 different
 as compared to overlays.
 
 Add checks for writeback in dispc_ovl_set_input_size() and
 dispc_ovl_set_output_size() to write to the correct registers.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/dispc.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
 index e42e902..04fdd33 100644
 --- a/drivers/video/omap2/dss/dispc.c
 +++ b/drivers/video/omap2/dss/dispc.c
 @@ -719,7 +719,7 @@ static void dispc_ovl_set_input_size(enum omap_plane 
 plane, int width,
  {
   u32 val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
  
 - if (plane == OMAP_DSS_GFX)
 + if (plane == OMAP_DSS_GFX || plane == OMAP_DSS_WB)
   dispc_write_reg(DISPC_OVL_SIZE(plane), val);
   else
   dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
 @@ -734,7 +734,10 @@ static void dispc_ovl_set_output_size(enum omap_plane 
 plane, int width,
  
   val = FLD_VAL(height - 1, 26, 16) | FLD_VAL(width - 1, 10, 0);
  
 - dispc_write_reg(DISPC_OVL_SIZE(plane), val);
 + if (plane == OMAP_DSS_WB)
 + dispc_write_reg(DISPC_OVL_PICTURE_SIZE(plane), val);
 + else
 + dispc_write_reg(DISPC_OVL_SIZE(plane), val);
  }

Should we just rename the dispc registers to DISPC_OVL_IN_SIZE and
DISPC_OVL_OUT_SIZE, and then we could do without the ifs? The registers
have always confused me a bit, I don't know why they are named so in the
TRM.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 16/18] OMAPDSS: DISPC: Configure writeback FIFOs

On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
 Extend the DISPC fifo functions to also configure the writeback FIFO 
 thresholds.
 
 The most optimal configuration for writeback is to push out data to the
 interconnect the moment writeback pushes enough pixels in the FIFO to form a
 burst. This reduces the chance of writeback overflowing it's FIFO.

Hmm, why is this optimal?

The FIFO for WB is the output fifo, right? In mem-to-mem mode the whole
WB pipeline can stall, so the fifo can't overflow? If so, isn't it
better to collect more data and flush all that to the memory, instead of
sending each burst-size piece one by one?

Then again, if the input side is reading pixels from the memory all the
time, even if the output fifo helps to keep the output side idle for
longer periods, it probably doesn't help as the input side keeps the
memory bus awake.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH V2] ARM: OMAP: counter: add locking to read_persistent_clock

2012-09-25 Thread Tony Lindgren

* R, Sricharan r.sricha...@ti.com [120925 00:44]:
 Hi Tony,
 
 [snip..]
 
   index dbf1e03..2bc51fb 100644
   --- a/arch/arm/plat-omap/counter_32k.c
   +++ b/arch/arm/plat-omap/counter_32k.c
   @@ -55,22 +55,29 @@ static u32 notrace omap_32k_read_sched_clock(void)
 * nsecs and adds to a monotonically increasing timespec.
 */
static struct timespec persistent_ts;
   -static cycles_t cycles, last_cycles;
   +static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
   +static DEFINE_SPINLOCK(read_persistent_clock_lock);
   +
static void omap_read_persistent_clock(struct timespec *ts)
{
   unsigned long long nsecs;
   -   cycles_t delta;
   -   struct timespec *tsp = persistent_ts;
   +   cycles_t last_cycles;
   +   unsigned long flags;
   +
   +   spin_lock_irqsave(read_persistent_clock_lock, flags);
  
   last_cycles = cycles;
   cycles = sync32k_cnt_reg ? __raw_readl(sync32k_cnt_reg) : 0;
   -   delta = cycles - last_cycles;
  
   -   nsecs = clocksource_cyc2ns(delta, persistent_mult, persistent_shift);
   +   nsecs = clocksource_cyc2ns(cycles - last_cycles,
   +   persistent_mult, persistent_shift);
 
  ..I think there's another bug here where cycles - last_cycles
  returns wrong value when the timer wraps around as cycles_t is
  64 bits and the counter is 32 bits. It seems it's been there
  since when the read_persistent_clock was added with commit
  d92cfcbe (OMAP: timekeeping: time should not stop during suspend)?
 
  It seems that after this patch cycles should not be cycles_t
  but u32, and the result of cycles - last_cycles should also
  be u32.
 
  cycles_t is defined as  typedef unsigned long cycles_t;
  Am i missing something here ?

Oh right, cycles_t is unsigned long, it's OK then. Must
have grepped for it from some other arch.

Regards,

Tony
--
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: [PATCH v2] arm: make FORCE_MAX_ZONEORDER configurable for TI AM33XX

2012-09-25 Thread Tony Lindgren

* Yegor Yefremov yegor_s...@visionsystems.de [120925 01:47]:
 On 25.09.2012 10:32, Russell King - ARM Linux wrote:
  On Tue, Sep 25, 2012 at 10:26:30AM +0200, yegorsli...@googlemail.com wrote:
  From: Yegor Yefremov yegorsli...@googlemail.com
 
  FORCE_MAX_ZONEORDER of 12 is needed to allocation more than 4MB
  of consistent DMA memory (da8xx frame buffer driver).
  
  Okay, so the patch description says This needs to be 12 on this platform.
  
   config FORCE_MAX_ZONEORDER
  -  int Maximum zone order if ARCH_SHMOBILE
  -  range 11 64 if ARCH_SHMOBILE
  +  int Maximum zone order if ARCH_SHMOBILE || SOC_AM33XX
  +  range 11 64 if ARCH_SHMOBILE || SOC_AM33XX
  
  but you leave it up to the user to select something that may not be
  suitable.  Wouldn't _just_ adding:
  
  default 12 if SOC_AM33XX
  
  after the range, and making no other changes be good enough and match
  what the patch description says?
 
 You're right. As we don't allocate anything, but increase the possible size, 
 it shouldn't break anything. Tony is it O.K. with you?

Sure.

Tony
--
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: Powering OMAP's pins

2012-09-25 Thread Tony Lindgren

* Tomi Valkeinen tomi.valkei...@ti.com [120925 03:22]:
 Hi Tony,
 
 Each pin of OMAP requires a particular power to be enabled for the pin
 to function (Ball Characteristics table from data manual). Is there a
 plan how this is managed with pinctrl? Currently each driver needs to
 make sure the correct regulators are enabled for the pins it uses, which
 is platform specific and messy.
 
 As a driver maintainer, I would wish that the pins would just get
 enabled automatically when I call pm_runtime_get()...

Hmm can you clarify a bit what exactly do you want to do there
with pm_runtime_get()? Call the regulator framework?

Regards,

Tony
--
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

[PATCHv6 00/11]: ARM: OMAP: PM usecounting changes

Hi,

Changes compared to previous version:

- Added patch #1 for fixing a potential race condition within clockdomain
  code
- Fixed patch #3 (old patch #2) regarding a similar race condition within
  the voltagedomain code

Tested with OMAP3 beagle, OMAP4460 GP panda, OMAP4430 EMU blaze devices.

Branch available:

git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.6-rc5-pwrdm-changes-v6

-Tero

--
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

[PATCHv6 02/11] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking

This patch fixes the usecount tracking for omap3+, previously the
usecount numbers were rather bogus and were not really useful for
any purpose. Now usecount numbers track the number of really active
clients on each domain. This patch also adds support for usecount
tracking on powerdomain level and autoidle flag for clocks that
are hardware controlled and should be skipped in usecount
calculations.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/clkt_iclk.c |   21 ++
 arch/arm/mach-omap2/clockdomain.c   |   16 +-
 arch/arm/mach-omap2/dpll3xxx.c  |   19 
 arch/arm/mach-omap2/powerdomain.c   |   35 +++
 arch/arm/mach-omap2/powerdomain.h   |4 +++
 arch/arm/plat-omap/clock.c  |6 +
 arch/arm/plat-omap/include/plat/clock.h |2 +
 7 files changed, 102 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_iclk.c b/arch/arm/mach-omap2/clkt_iclk.c
index 3d43fba..1afc599 100644
--- a/arch/arm/mach-omap2/clkt_iclk.c
+++ b/arch/arm/mach-omap2/clkt_iclk.c
@@ -21,6 +21,7 @@
 #include clock2xxx.h
 #include cm2xxx_3xxx.h
 #include cm-regbits-24xx.h
+#include clockdomain.h
 
 /* Private functions */
 
@@ -34,6 +35,16 @@ void omap2_clkt_iclk_allow_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v |= (1  clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+   /* Remove this clock from parent clockdomain usecounts */
+   if (clk-usecount  clk-clkdm)
+   clkdm_clk_disable(clk-clkdm, clk);
+
+   /*
+* Mark as autoidle, so we continue to ignore this clock in
+* parent clkdm usecount calculations
+*/
+   clk-autoidle = true;
 }
 
 /* XXX */
@@ -46,6 +57,16 @@ void omap2_clkt_iclk_deny_idle(struct clk *clk)
v = __raw_readl((__force void __iomem *)r);
v = ~(1  clk-enable_bit);
__raw_writel(v, (__force void __iomem *)r);
+
+   /*
+* Disable autoidle flag so further clkdm usecounts take this
+* clock into account
+*/
+   clk-autoidle = false;
+
+   /* Add clock back to parent clockdomain usecount */
+   if (clk-usecount  clk-clkdm)
+   clkdm_clk_enable(clk-clkdm, clk);
 }
 
 /* Public data */
diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 173905d..7715353 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -910,6 +910,7 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
 static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
 {
unsigned long flags;
+   int usecount;
 
if (!clkdm || !arch_clkdm || !arch_clkdm-clkdm_clk_enable)
return -EINVAL;
@@ -921,12 +922,16 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain 
*clkdm)
 * should be called for every clock instance or hwmod that is
 * enabled, so the clkdm can be force woken up.
 */
-   if ((atomic_inc_return(clkdm-usecount)  1)  autodeps) {
+   usecount = atomic_inc_return(clkdm-usecount);
+
+   if (usecount  1  autodeps) {
spin_unlock_irqrestore(clkdm-lock, flags);
return 0;
}
 
arch_clkdm-clkdm_clk_enable(clkdm);
+   if (usecount == 1)
+   pwrdm_clkdm_enable(clkdm-pwrdm.ptr);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
 
@@ -956,6 +961,7 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain 
*clkdm)
}
 
arch_clkdm-clkdm_clk_disable(clkdm);
+   pwrdm_clkdm_disable(clkdm-pwrdm.ptr);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
 
@@ -988,6 +994,10 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk 
*clk)
if (!clk)
return -EINVAL;
 
+   /* If autoidle clock, do not update clkdm usecounts */
+   if (clk-autoidle)
+   return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
 }
 
@@ -1014,6 +1024,10 @@ int clkdm_clk_disable(struct clockdomain *clkdm, struct 
clk *clk)
if (!clk)
return -EINVAL;
 
+   /* If autoidle clock, do not update clkdm usecounts */
+   if (clk-autoidle)
+   return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
 }
 
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index b9c8d2f..da660d2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,7 @@
 #include clock.h
 #include cm2xxx_3xxx.h
 #include cm-regbits-34xx.h
+#include clockdomain.h
 
 /* CM_AUTOIDLE_PLL*.AUTO_* bit values */
 #define DPLL_AUTOIDLE_DISABLE  0x0
@@ -571,6 +572,15 @@ void omap3_dpll_allow_idle(struct clk *clk)
v |= DPLL_AUTOIDLE_LOW_POWER_STOP

[PATCHv6 03/11] ARM: OMAP3+: voltage: add support for voltagedomain usecounts

These are updated based on powerdomain usecounts. Also added support
for voltdm-sleep and voltdm-wakeup calls that will be invoked once
voltagedomain enters sleep or wakes up based on usecount numbers. These
will be used for controlling voltage scaling functionality.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/powerdomain.c |   17 +-
 arch/arm/mach-omap2/voltage.c |   65 +
 arch/arm/mach-omap2/voltage.h |   13 +++
 3 files changed, 94 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index ba49029..abc50c2 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1475,10 +1475,17 @@ int pwrdm_state_switch(struct powerdomain *pwrdm)
  */
 void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
 {
+   unsigned long flags;
+
if (!pwrdm)
return;
 
-   atomic_inc(pwrdm-usecount);
+   spin_lock_irqsave(pwrdm-lock, flags);
+
+   if (atomic_inc_return(pwrdm-usecount) == 1)
+   voltdm_pwrdm_enable(pwrdm-voltdm.ptr);
+
+   spin_unlock_irqrestore(pwrdm-lock, flags);
 }
 
 /**
@@ -1492,12 +1499,20 @@ void pwrdm_clkdm_enable(struct powerdomain *pwrdm)
 void pwrdm_clkdm_disable(struct powerdomain *pwrdm)
 {
int val;
+   unsigned long flags;
 
if (!pwrdm)
return;
 
+   spin_lock_irqsave(pwrdm-lock, flags);
+
val = atomic_dec_return(pwrdm-usecount);
 
+   if (!val)
+   voltdm_pwrdm_disable(pwrdm-voltdm.ptr);
+
+   spin_unlock_irqrestore(pwrdm-lock, flags);
+
WARN_ON(val  0);
 }
 
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 4dc60e8..0fc2a25 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -340,6 +340,70 @@ int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct 
powerdomain *pwrdm)
 }
 
 /**
+ * voltdm_pwrdm_enable - increase usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to increase count for
+ *
+ * Increases usecount for a given voltagedomain. If the usecount reaches
+ * 1, the domain is awakened from idle and the function will call the
+ * voltagedomain-wakeup callback for this domain.
+ */
+void voltdm_pwrdm_enable(struct voltagedomain *voltdm)
+{
+   unsigned long flags;
+
+   if (!voltdm)
+   return;
+
+   spin_lock_irqsave(voltdm-lock, flags);
+
+   if (atomic_inc_return(voltdm-usecount) == 1  voltdm-wakeup)
+   voltdm-wakeup(voltdm);
+
+   spin_unlock_irqrestore(voltdm-lock, flags);
+}
+
+/**
+ * voltdm_pwrdm_disable - decrease usecount for a voltagedomain
+ * @voltdm: struct voltagedomain * to decrease count for
+ *
+ * Decreases the usecount for a given voltagedomain. If the usecount
+ * reaches zero, the domain can idle and the function will call the
+ * voltagedomain-sleep callback, and calculate the overall target
+ * state for the voltagedomain.
+ */
+void voltdm_pwrdm_disable(struct voltagedomain *voltdm)
+{
+   u8 target_state = PWRDM_POWER_OFF;
+   int state;
+   struct powerdomain *pwrdm;
+   int val;
+   unsigned long flags;
+
+   if (!voltdm)
+   return;
+
+   spin_lock_irqsave(voltdm-lock, flags);
+
+   val = atomic_dec_return(voltdm-usecount);
+
+   WARN_ON(val  0);
+
+   if (val == 0) {
+   /* Determine target state for voltdm */
+   list_for_each_entry(pwrdm, voltdm-pwrdm_list, voltdm_node) {
+   state = pwrdm_read_next_pwrst(pwrdm);
+   if (state  target_state)
+   target_state = state;
+   }
+   voltdm-target_state = target_state;
+   if (voltdm-sleep)
+   voltdm-sleep(voltdm);
+   }
+
+   spin_unlock_irqrestore(voltdm-lock, flags);
+}
+
+/**
  * voltdm_for_each_pwrdm - call function for each pwrdm in a voltdm
  * @voltdm: struct voltagedomain * to iterate over
  * @fn: callback function *
@@ -402,6 +466,7 @@ static int _voltdm_register(struct voltagedomain *voltdm)
INIT_LIST_HEAD(voltdm-pwrdm_list);
list_add(voltdm-node, voltdm_list);
 
+   spin_lock_init(voltdm-lock);
pr_debug(voltagedomain: registered %s\n, voltdm-name);
 
return 0;
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 0ac2caf..7f4f99d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -15,6 +15,7 @@
 #define __ARCH_ARM_MACH_OMAP2_VOLTAGE_H
 
 #include linux/err.h
+#include linux/spinlock.h
 
 #include plat/voltage.h
 
@@ -56,10 +57,14 @@ struct omap_vfsm_instance {
  * @pwrdm_list: list_head linking all powerdomains in this voltagedomain
  * @vc: pointer to VC channel associated with this voltagedomain
  * @vp: pointer to VP

[PATCHv6 01/11] ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable

Previously the code only acquired spinlock after increasing / decreasing
the usecount value, which is wrong. This leaves a small window where
a task switch may occur between the check of the usecount and the actual
wakeup / sleep of the domain. Fixed by moving the spinlock locking before
the usecount access. Left the usecount as atomic_t if someone wants an
easy access to the parameter through atomic_read.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..173905d 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -914,15 +914,18 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain 
*clkdm)
if (!clkdm || !arch_clkdm || !arch_clkdm-clkdm_clk_enable)
return -EINVAL;
 
+   spin_lock_irqsave(clkdm-lock, flags);
+
/*
 * For arch's with no autodeps, clkcm_clk_enable
 * should be called for every clock instance or hwmod that is
 * enabled, so the clkdm can be force woken up.
 */
-   if ((atomic_inc_return(clkdm-usecount)  1)  autodeps)
+   if ((atomic_inc_return(clkdm-usecount)  1)  autodeps) {
+   spin_unlock_irqrestore(clkdm-lock, flags);
return 0;
+   }
 
-   spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_enable(clkdm);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
@@ -939,15 +942,19 @@ static int _clkdm_clk_hwmod_disable(struct clockdomain 
*clkdm)
if (!clkdm || !arch_clkdm || !arch_clkdm-clkdm_clk_disable)
return -EINVAL;
 
+   spin_lock_irqsave(clkdm-lock, flags);
+
if (atomic_read(clkdm-usecount) == 0) {
+   spin_unlock_irqrestore(clkdm-lock, flags);
WARN_ON(1); /* underflow */
return -ERANGE;
}
 
-   if (atomic_dec_return(clkdm-usecount)  0)
+   if (atomic_dec_return(clkdm-usecount)  0) {
+   spin_unlock_irqrestore(clkdm-lock, flags);
return 0;
+   }
 
-   spin_lock_irqsave(clkdm-lock, flags);
arch_clkdm-clkdm_clk_disable(clkdm);
pwrdm_state_switch(clkdm-pwrdm.ptr);
spin_unlock_irqrestore(clkdm-lock, flags);
-- 
1.7.4.1

--
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

[PATCHv6 05/11] ARM: OMAP3: set autoidle flag for sdrc_ick

sdrc_ick doesn't have autoidle flag on HW, but is always automatically
idled. Thus mark the autoidle flag statically as true for it to reflect
hardware behavior. The clock will no longer show as active in usecount
dumps and will allow the voltdm-sleep / wakeup calls to work properly.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/clock3xxx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 83bed9a..1ddc7fc 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1739,6 +1739,7 @@ static struct clk sdrc_ick = {
.flags  = ENABLE_ON_INIT,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
+   .autoidle   = true,
 };
 
 static struct clk gpmc_fck = {
-- 
1.7.4.1

--
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

[PATCHv6 06/11] ARM: OMAP: clockdomain: add support for preventing autodep delete

Some clockdomains bug out if their autodeps are deleted before idle.
This happens namely with OMAP3 PER domain, it will bug out if it
doesn't have wakedeps enabled when it enters off-mode. This patch
adds support for new flag 'CLKDM_NO_AUTODEP_DISABLE' which does this.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c |3 +++
 arch/arm/mach-omap2/clockdomain.h |4 
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 7715353..4f01c8f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -201,6 +201,9 @@ void _clkdm_del_autodeps(struct clockdomain *clkdm)
if (!autodeps || clkdm-flags  CLKDM_NO_AUTODEPS)
return;
 
+   if (clkdm-flags  CLKDM_NO_AUTODEP_DISABLE)
+   return;
+
for (autodep = autodeps; autodep-clkdm.ptr; autodep++) {
if (IS_ERR(autodep-clkdm.ptr))
continue;
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 5601dc1..9b8733e 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -34,6 +34,9 @@
  * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
  * active whenever the MPU is active.  True for interconnects and
  * the WKUP clockdomains.
+ * CLKDM_NO_AUTODEP_DISABLE: Prevent clockdomain code from deleting autodeps.
+ * Needed for PER domain on omap3, as it will bug out with off-mode if
+ * wakedeps are removed.
  */
 #define CLKDM_CAN_FORCE_SLEEP  (1  0)
 #define CLKDM_CAN_FORCE_WAKEUP (1  1)
@@ -41,6 +44,7 @@
 #define CLKDM_CAN_DISABLE_AUTO (1  3)
 #define CLKDM_NO_AUTODEPS  (1  4)
 #define CLKDM_ACTIVE_WITH_MPU  (1  5)
+#define CLKDM_NO_AUTODEP_DISABLE   (1  6)
 
 #define CLKDM_CAN_HWSUP(CLKDM_CAN_ENABLE_AUTO | 
CLKDM_CAN_DISABLE_AUTO)
 #define CLKDM_CAN_SWSUP(CLKDM_CAN_FORCE_SLEEP | 
CLKDM_CAN_FORCE_WAKEUP)
-- 
1.7.4.1

--
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

[PATCHv6 04/11] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting

mpu / core powerdomain usecounts are now statically increased
by 1 during MPU activity. This allows the domains to reflect
actual usage, and will allow the usecount to reach 0 just before
all CPUs are ready to idle. Proper powerdomain usecounts are
propageted to voltagedomain level also, and will allow vc
callbacks to be triggered at right point of time.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/common.h  |6 ++
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |   72 -
 arch/arm/mach-omap2/omap-smp.c|2 +
 arch/arm/mach-omap2/pm34xx.c  |   21 
 4 files changed, 100 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 6ea837a..a445a02 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -292,6 +292,8 @@ extern int omap4_finish_suspend(unsigned long cpu_state);
 extern void omap4_cpu_resume(void);
 extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
 extern u32 omap4_mpuss_read_prev_context_state(void);
+extern void omap4_pm_cpu_online(void);
+extern void omap4_pm_cpu_offline(void);
 #else
 static inline int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
@@ -323,6 +325,10 @@ static inline u32 omap4_mpuss_read_prev_context_state(void)
 {
return 0;
 }
+
+static inline void omap4_pm_cpu_online(void) { }
+
+static inline void omap4_pm_cpu_offline(void) { }
 #endif
 
 struct omap_sdrc_params;
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 230bdcd..0ad2337 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -72,8 +72,9 @@ struct omap4_cpu_pm_info {
 };
 
 static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
-static struct powerdomain *mpuss_pd;
+static struct powerdomain *mpuss_pd, *core_pd;
 static void __iomem *sar_base;
+static atomic_t __initdata init_cpu_online_count;
 
 /*
  * Program the wakeup routine address for the CPU0 and CPU1
@@ -216,6 +217,50 @@ static void save_l2x0_context(void)
 #endif
 
 /**
+ * omap4_pm_cpu_online - increase the number of online CPUs
+ *
+ * This function increases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is increased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_online(void)
+{
+   if (!mpuss_pd || !core_pd) {
+   atomic_inc(init_cpu_online_count);
+   return;
+   }
+
+   pwrdm_clkdm_enable(mpuss_pd);
+   pwrdm_clkdm_enable(core_pd);
+}
+
+/**
+ * omap4_pm_cpu_offline - decrease the number of online CPUs
+ *
+ * This function decreases the usecounts for MPU and CORE powerdomains,
+ * which allows the domains to properly reflect usage with online CPUs
+ * also. CORE powerdomain usecount is decreased, as MPU is using memories,
+ * which are powered through CORE powerdomain (SDRAM). If this function is
+ * called before PM init has completed (mpuss_pd / core_pd are not defined),
+ * a temporary init time variable is increased instead; its contents
+ * will be moved to the powerdomain usecounts once PM init completes.
+ */
+void omap4_pm_cpu_offline(void)
+{
+   if (!mpuss_pd || !core_pd) {
+   atomic_dec(init_cpu_online_count);
+   return;
+   }
+
+   pwrdm_clkdm_disable(mpuss_pd);
+   pwrdm_clkdm_disable(core_pd);
+}
+
+/**
  * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
  * The purpose of this function is to manage low power programming
  * of OMAP4 MPUSS subsystem
@@ -274,11 +319,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int 
power_state)
scu_pwrst_prepare(cpu, power_state);
l2x0_pwrst_prepare(cpu, save_state);
 
+   /* Decrement usecounts for MPU and CORE pd as we are entering idle */
+   omap4_pm_cpu_offline();
+
/*
 * Call low level function  with targeted low power state.
 */
cpu_suspend(save_state, omap4_finish_suspend);
 
+   /* Increment usecounts for MPU and CORE pd as we are leaving idle */
+   omap4_pm_cpu_online();
+
/*
 * Restore the CPUx power state to ON otherwise CPUx
 * power domain can transitions to programmed low power
@@ -315,6 +366,8 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned 
int power_state)
set_cpu_wakeup_addr(cpu, virt_to_phys(pm_info-secondary_startup));

[PATCHv6 08/11] ARM: OMAP4: clock data: set autoidle flag for dss_fck

dss_fck is currently being used improperly within the hwmod database
as an interface clock for DSS hwmods. This causes the dss_fck to
be enabled even if the dss powerdomain itself is idle, resulting
in wrong data within the powerdomain usecounts. Marked dss_fck as
autoidle which makes the clock to disappear from usecounts for now.
This patch can be reverted once the interface clocks for DSS hwmods
have been properly fixed.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..95834d7 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1408,6 +1408,7 @@ static struct clk dss_fck = {
.clkdm_name = l3_dss_clkdm,
.parent = l3_div_ck,
.recalc = followparent_recalc,
+   .autoidle   = true,
 };
 
 static struct clk efuse_ctrl_cust_fck = {
-- 
1.7.4.1

--
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

[PATCHv6 07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle

Previously, PER clock domain was always enabled, as the usecounts
for this domain incorrectly always showed positive value. On HW
level though, the domain enters idle as it is set in HW supervised
mode. Now, when the usecounts reflect real values, PER domain
will be put to HWSUP sleep mode, which means its autodeps are deleted.
Removing wakedeps for PER domain will cause multiple problems.
First of all, coming back from idle, PER domain remains idle as the
wakedeps have been disabled for the domain, and this causes a crash
with the GPIO code, as the resume code attempts to access domain
which is not active. Just enabling the interface clocks for the GPIO
does not help, as they are autoidled and don't bring the domain out
of idle. Secondly, there are multiple erratas for omap3, which say
that the wakedeps should be enabled for the PER domain, see e.g.
errata i582 for omap3630.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomains3xxx_data.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c 
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 56089c4..3b3c524 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -370,7 +370,7 @@ static struct clockdomain usbhost_am35x_clkdm = {
 static struct clockdomain per_clkdm = {
.name   = per_clkdm,
.pwrdm  = { .name = per_pwrdm },
-   .flags  = CLKDM_CAN_HWSUP_SWSUP,
+   .flags  = CLKDM_CAN_HWSUP_SWSUP | CLKDM_NO_AUTODEP_DISABLE,
.dep_bit= OMAP3430_EN_PER_SHIFT,
.wkdep_srcs = per_wkdeps,
.sleepdep_srcs  = per_sleepdeps,
-- 
1.7.4.1

--
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

[PATCHv6 10/11] ARM: OMAP4: hwmod data: set mpu hwmod modulemode to hwauto

This makes sure it is handled as autoidle type by the usecounting.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2d13b33..367de25 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2492,6 +2492,7 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap4 = {
.clkctrl_offs = OMAP4_CM_MPU_MPU_CLKCTRL_OFFSET,
.context_offs = OMAP4_RM_MPU_MPU_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
},
},
 };
-- 
1.7.4.1

--
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

[PATCHv6 09/11] ARM: OMAP4: hwmod: add support for hwmod autoidle flag

If a hwmod is in HWAUTO mode, it will idle automatically and should not
be accounted for in the clkdm / pwrdm usecounts. Thus, flag modules in
such mode as autoidle during init, and ignore these in subsequent
usecount calculations.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c|6 ++
 arch/arm/mach-omap2/omap_hwmod.c |3 +++
 arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 4f01c8f..af88ae5 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1063,6 +1063,9 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
+   if (oh-flags  HWMOD_AUTOIDLE)
+   return 0;
+
return _clkdm_clk_hwmod_enable(clkdm);
 }
 
@@ -1094,6 +1097,9 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
if (!oh)
return -EINVAL;
 
+   if (oh-flags  HWMOD_AUTOIDLE)
+   return 0;
+
return _clkdm_clk_hwmod_disable(clkdm);
 }
 
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f826917..6807b02 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2377,6 +2377,9 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(oh-slave_ports);
spin_lock_init(oh-_lock);
 
+   if (cpu_is_omap44xx()  oh-prcm.omap4.modulemode == MODULEMODE_HWCTRL)
+   oh-flags |= HWMOD_AUTOIDLE;
+
oh-_state = _HWMOD_STATE_REGISTERED;
 
/*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 0f840a9..36130f9 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -440,6 +440,7 @@ struct omap_hwmod_omap4_prcm {
  * in order to complete the reset. Optional clocks will be disabled
  * again after the reset.
  * HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_AUTOIDLE: Module is controlled automatically by hardware
  */
 #define HWMOD_SWSUP_SIDLE  (1  0)
 #define HWMOD_SWSUP_MSTANDBY   (1  1)
@@ -450,6 +451,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_IDLEST(1  6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET(1  7)
 #define HWMOD_16BIT_REG(1  8)
+#define HWMOD_AUTOIDLE (1  9)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.7.4.1

--
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

[PATCHv6 11/11] ARM: OMAP4: clock data: flag hw controlled clocks as autoidle

This makes sure these clocks are ignored by the clkdm / pwrdm usecounting.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/clock44xx_data.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 95834d7..d2fb4e8 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3356,8 +3356,11 @@ int __init omap4xxx_clk_init(void)
 */
 
for (c = omap44xx_clks; c  omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
- c++)
+ c++) {
+   if (c-lk.clk-enable_bit == OMAP4430_MODULEMODE_HWCTRL)
+   c-lk.clk-autoidle = true;
clk_preinit(c-lk.clk);
+   }
 
for (c = omap44xx_clks; c  omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
  c++)
-- 
1.7.4.1

--
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

[PATCHv7 00/21] ARM: OMAP3+: auto retention support

Hi,

This set applies on top of linux-3.6-rc5 + func-pwrst code (from Jean) +
omap4 core retention set (from me) + PM usecounting changes set (from me).

Changes compared to previous version:
- Added proper OMAP4 auto-retention support (now that the PM usecount set
  below supports OMAP4 also properly)
- Merged TPS6236x support to this set (patches 16,18-20), without this
  there will be an issue with patch #21, as panda board will misbehave
  without TPS support and auto-ret enabled
- Patch #15 fixes the addressing of voltage channels for OMAP4, without this
  the voltage channels either end up changing wrong voltage channel or not
  changing anything at all
- Patch #16 is new based on the discussion earlier on the separate TPS set
  * uses proper I2C parameters based on board data, this is still in a data
table though, as calculating these runtime would be rather complicated
(if even possible, as it requires some higher order mathematics according
 to my understanding)
- Patch #17 enables high speed I2C communication for voltage channel on OMAP4
  (this now works thanks to patch #16)
- Patch #18 is needed for 4460 boards, otherwise the boot-up OPP detection
  fails and voltage control doesn't work at all on 4460 boards
- Patch #19 was pulled from the TPS support set
- Patch #20 was pulled from the TPS support set, with following changes:
  * board setup for the GPIOs was sanitized a bit
  * dropped a number of unused defines from the code

Working branch available:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.6-rc5-omap-auto-ret-v7

Testing done:
- hw used: omap3 beagle rev c4, omap4460 gp panda, omap4430 emu blaze
- suspend + cpuidle
- measured core + mpu voltage rails on all setups to verify that the
  voltage transitions work properly during idle

-Tero

--
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

[PATCHv7 01/21] ARM: OMAP3+: PM: VP: use uV for max and min voltage limits

From: Nishanth Menon n...@ti.com

Every PMIC has it's own eccentricities, For example, one of the
PMIC has MSB set to 1 for a specific function - voltage enable!
using an hardcoded value specific for TWL when copied over to
such an implementation causes the system to crash as the MSB bit
was 0 and the voltage got disabled!.

Instead we use actual values and depend on the convertion routines
to abstract out the eccentricities of each PMIC.

With this, we can now move the voltages to a common location in
voltage.h as they are no longer dependent on PMICs and expect the
PMIC's conversion routines to set a cap if the voltage is out of
reach for the PMIC.

Reported-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_twl.c |   17 -
 arch/arm/mach-omap2/voltage.h  |   22 --
 arch/arm/mach-omap2/vp.c   |4 ++--
 3 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index f515a1a..df4e7c3 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -30,16 +30,6 @@
 #define OMAP3_VP_VSTEPMAX_VSTEPMAX 0x04
 #define OMAP3_VP_VLIMITTO_TIMEOUT_US   200
 
-#define OMAP3430_VP1_VLIMITTO_VDDMIN   0x14
-#define OMAP3430_VP1_VLIMITTO_VDDMAX   0x42
-#define OMAP3430_VP2_VLIMITTO_VDDMIN   0x18
-#define OMAP3430_VP2_VLIMITTO_VDDMAX   0x2c
-
-#define OMAP3630_VP1_VLIMITTO_VDDMIN   0x18
-#define OMAP3630_VP1_VLIMITTO_VDDMAX   0x3c
-#define OMAP3630_VP2_VLIMITTO_VDDMIN   0x18
-#define OMAP3630_VP2_VLIMITTO_VDDMAX   0x30
-
 #define OMAP4_SRI2C_SLAVE_ADDR 0x12
 #define OMAP4_VDD_MPU_SR_VOLT_REG  0x55
 #define OMAP4_VDD_MPU_SR_CMD_REG   0x56
@@ -53,13 +43,6 @@
 #define OMAP4_VP_VSTEPMAX_VSTEPMAX 0x04
 #define OMAP4_VP_VLIMITTO_TIMEOUT_US   200
 
-#define OMAP4_VP_MPU_VLIMITTO_VDDMIN   0xA
-#define OMAP4_VP_MPU_VLIMITTO_VDDMAX   0x39
-#define OMAP4_VP_IVA_VLIMITTO_VDDMIN   0xA
-#define OMAP4_VP_IVA_VLIMITTO_VDDMAX   0x2D
-#define OMAP4_VP_CORE_VLIMITTO_VDDMIN  0xA
-#define OMAP4_VP_CORE_VLIMITTO_VDDMAX  0x28
-
 static bool is_offset_valid;
 static u8 smps_offset;
 /*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 7f4f99d..622ec4b 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -103,6 +103,24 @@ struct voltagedomain {
spinlock_t lock;
 };
 
+/* Min and max voltages from OMAP perspective */
+#define OMAP3430_VP1_VLIMITTO_VDDMIN   85
+#define OMAP3430_VP1_VLIMITTO_VDDMAX   1425000
+#define OMAP3430_VP2_VLIMITTO_VDDMIN   90
+#define OMAP3430_VP2_VLIMITTO_VDDMAX   115
+
+#define OMAP3630_VP1_VLIMITTO_VDDMIN   90
+#define OMAP3630_VP1_VLIMITTO_VDDMAX   135
+#define OMAP3630_VP2_VLIMITTO_VDDMIN   90
+#define OMAP3630_VP2_VLIMITTO_VDDMAX   120
+
+#define OMAP4_VP_MPU_VLIMITTO_VDDMIN   83
+#define OMAP4_VP_MPU_VLIMITTO_VDDMAX   141
+#define OMAP4_VP_IVA_VLIMITTO_VDDMIN   83
+#define OMAP4_VP_IVA_VLIMITTO_VDDMAX   126
+#define OMAP4_VP_CORE_VLIMITTO_VDDMIN  83
+#define OMAP4_VP_CORE_VLIMITTO_VDDMAX  120
+
 /**
  * struct omap_voltdm_pmic - PMIC specific data required by voltage driver.
  * @slew_rate: PMIC slew rate (in uv/us)
@@ -129,8 +147,8 @@ struct omap_voltdm_pmic {
u8 vp_erroroffset;
u8 vp_vstepmin;
u8 vp_vstepmax;
-   u8 vp_vddmin;
-   u8 vp_vddmax;
+   u32 vp_vddmin;
+   u32 vp_vddmax;
u8 vp_timeout_us;
bool i2c_high_speed;
u8 i2c_mcode;
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index f95c1ba..40b3dcc 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -58,8 +58,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
sys_clk_rate = voltdm-sys_clk.rate / 1000;
 
timeout = (sys_clk_rate * voltdm-pmic-vp_timeout_us) / 1000;
-   vddmin = voltdm-pmic-vp_vddmin;
-   vddmax = voltdm-pmic-vp_vddmax;
+   vddmin = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmin);
+   vddmax = voltdm-pmic-uv_to_vsel(voltdm-pmic-vp_vddmax);
 
waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate,
1000 * voltdm-pmic-slew_rate);
-- 
1.7.4.1

--
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

[PATCHv7 02/21] ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields

These are now called vddmin and vddmax, as these fields will be used
globally for selecting voltage ranges for a pmic channel, and not
only for voltage processor.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_twl.c |   28 ++--
 arch/arm/mach-omap2/voltage.h  |4 ++--
 arch/arm/mach-omap2/vp.c   |4 ++--
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index df4e7c3..c38a530 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -149,8 +149,8 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
-   .vp_vddmin  = OMAP3430_VP1_VLIMITTO_VDDMIN,
-   .vp_vddmax  = OMAP3430_VP1_VLIMITTO_VDDMAX,
+   .vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
+   .vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
.vp_timeout_us  = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr  = OMAP3_VDD_MPU_SR_CONTROL_REG,
@@ -170,8 +170,8 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP3_VP_VSTEPMAX_VSTEPMAX,
-   .vp_vddmin  = OMAP3430_VP2_VLIMITTO_VDDMIN,
-   .vp_vddmax  = OMAP3430_VP2_VLIMITTO_VDDMAX,
+   .vddmin = OMAP3430_VP2_VLIMITTO_VDDMIN,
+   .vddmax = OMAP3430_VP2_VLIMITTO_VDDMAX,
.vp_timeout_us  = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr  = OMAP3_VDD_CORE_SR_CONTROL_REG,
@@ -191,8 +191,8 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
-   .vp_vddmin  = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
-   .vp_vddmax  = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
+   .vddmin = OMAP4_VP_MPU_VLIMITTO_VDDMIN,
+   .vddmax = OMAP4_VP_MPU_VLIMITTO_VDDMAX,
.vp_timeout_us  = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr  = OMAP4_VDD_MPU_SR_VOLT_REG,
@@ -213,8 +213,8 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
-   .vp_vddmin  = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
-   .vp_vddmax  = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
+   .vddmin = OMAP4_VP_IVA_VLIMITTO_VDDMIN,
+   .vddmax = OMAP4_VP_IVA_VLIMITTO_VDDMAX,
.vp_timeout_us  = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr  = OMAP4_VDD_IVA_SR_VOLT_REG,
@@ -235,8 +235,8 @@ static struct omap_voltdm_pmic omap4_core_pmic = {
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
.vp_vstepmax= OMAP4_VP_VSTEPMAX_VSTEPMAX,
-   .vp_vddmin  = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
-   .vp_vddmax  = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
+   .vddmin = OMAP4_VP_CORE_VLIMITTO_VDDMIN,
+   .vddmax = OMAP4_VP_CORE_VLIMITTO_VDDMAX,
.vp_timeout_us  = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr  = OMAP4_VDD_CORE_SR_VOLT_REG,
@@ -272,10 +272,10 @@ int __init omap3_twl_init(void)
return -ENODEV;
 
if (cpu_is_omap3630()) {
-   omap3_mpu_pmic.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
-   omap3_mpu_pmic.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
-   omap3_core_pmic.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
-   omap3_core_pmic.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
+   omap3_mpu_pmic.vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
+   omap3_mpu_pmic.vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
+   omap3_core_pmic.vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
+   omap3_core_pmic.vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
 
/*
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 622ec4b..2242735 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@

[PATCHv7 03/21] ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains

These new structs will hold the sleep voltage levels (omap_vc_params)
and voltage processor min / max voltages (omap_vp_params.) Previously
these were part of the PMIC struct, but they do not really belong there,
as they are OMAP chip specific, not PMIC specific parameters. voltdm
code is also changed to use the new structs.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/omap_twl.c|   20 --
 arch/arm/mach-omap2/vc.c  |   35 ++---
 arch/arm/mach-omap2/vc.h  |7 +
 arch/arm/mach-omap2/vc3xxx_data.c |   22 +++
 arch/arm/mach-omap2/vc44xx_data.c |   28 
 arch/arm/mach-omap2/voltage.h |   18 ++---
 arch/arm/mach-omap2/voltagedomains3xxx_data.c |5 +++
 arch/arm/mach-omap2/voltagedomains44xx_data.c |8 +
 arch/arm/mach-omap2/vp.h  |7 +
 arch/arm/mach-omap2/vp3xxx_data.c |   10 +++
 arch/arm/mach-omap2/vp44xx_data.c |   15 ++
 11 files changed, 147 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index c38a530..dca1d66 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -141,10 +141,6 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
 static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate  = 4000,
.step_size  = 12500,
-   .on_volt= 120,
-   .onlp_volt  = 100,
-   .ret_volt   = 975000,
-   .off_volt   = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -162,10 +158,6 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
 static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate  = 4000,
.step_size  = 12500,
-   .on_volt= 120,
-   .onlp_volt  = 100,
-   .ret_volt   = 975000,
-   .off_volt   = 60,
.volt_setup_time= 0xfff,
.vp_erroroffset = OMAP3_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP3_VP_VSTEPMIN_VSTEPMIN,
@@ -183,10 +175,6 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
 static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate  = 4000,
.step_size  = 12660,
-   .on_volt= 1375000,
-   .onlp_volt  = 1375000,
-   .ret_volt   = 83,
-   .off_volt   = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -205,10 +193,6 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
 static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate  = 4000,
.step_size  = 12660,
-   .on_volt= 1188000,
-   .onlp_volt  = 1188000,
-   .ret_volt   = 83,
-   .off_volt   = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
@@ -227,10 +211,6 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
 static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate  = 4000,
.step_size  = 12660,
-   .on_volt= 120,
-   .onlp_volt  = 120,
-   .ret_volt   = 83,
-   .off_volt   = 0,
.volt_setup_time= 0,
.vp_erroroffset = OMAP4_VP_CONFIG_ERROROFFSET,
.vp_vstepmin= OMAP4_VP_VSTEPMIN_VSTEPMIN,
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 84da34f..a1e0fd6 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -137,6 +137,8 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
vc_cmdval |= (*target_vsel  vc-common-cmd_on_shift);
voltdm-write(vc_cmdval, vc-cmdval_reg);
 
+   voltdm-vc_param-on = target_volt;
+
omap_vp_update_errorgain(voltdm, target_volt);
 
return 0;
@@ -286,6 +288,30 @@ static void __init omap_vc_i2c_init(struct voltagedomain 
*voltdm)
initialized = true;
 }
 
+/**
+ * omap_vc_calc_vsel - calculate vsel value for a channel
+ * @voltdm: channel to calculate value for
+ * @uvolt: microvolt value to convert to vsel
+ *
+ * Converts a microvolt value to vsel value for the used PMIC.
+ * This checks whether the microvolt value is out of bounds, and
+ * adjusts the value accordingly. If unsupported value detected,
+ * warning is thrown.
+ */
+static u8

[PATCHv7 04/21] ARM: OMAP3: VC: calculate ramp times

OMAP3 VC code now uses voltage deltas + slew rates for calculating actual
ramp times for voltage changes. Previously a static value was used.
Two calculation methods are provided: i2c_timings and off_timings.
I2C timings are used during retention or off mode transition which
is initiated over I2C, and OFF timings are used if PMIC signal
(nsleep) is used to control all the off mode voltages at the same time.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/vc.c |  108 ++---
 arch/arm/mach-omap2/vc.h |1 -
 2 files changed, 91 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index a1e0fd6..bba0d7c 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -206,29 +206,109 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
 }
 
-static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
+/**
+ * omap3_set_i2c_timings - sets i2c sleep timings for a channel
+ * @voltdm: channel to configure
+ * @off_mode: select whether retention or off mode values used
+ *
+ * Calculates and sets up voltage controller to use I2C based
+ * voltage scaling for sleep modes. This can be used for either off mode
+ * or retention. Off mode has additionally an option to use sys_off_mode
+ * pad, which uses a global signal to program the whole power IC to
+ * off-mode.
+ */
+static void omap3_set_i2c_timings(struct voltagedomain *voltdm, bool off_mode)
 {
+   unsigned long voltsetup1;
+   u32 tgt_volt;
+
+   if (off_mode)
+   tgt_volt = voltdm-vc_param-off;
+   else
+   tgt_volt = voltdm-vc_param-ret;
+
+   voltsetup1 = (voltdm-vc_param-on - tgt_volt) /
+   voltdm-pmic-slew_rate;
+
+   voltsetup1 = voltsetup1 * voltdm-sys_clk.rate / 8 / 100 + 1;
+
+   voltdm-rmw(voltdm-vfsm-voltsetup_mask,
+   voltsetup1  __ffs(voltdm-vfsm-voltsetup_mask),
+   voltdm-vfsm-voltsetup_reg);
+
/*
-* Voltage Manager FSM parameters init
-* XXX This data should be passed in from the board file
+* pmic is not controlling the voltage scaling during retention,
+* thus set voltsetup2 to 0
 */
-   voltdm-write(OMAP3_CLKSETUP, OMAP3_PRM_CLKSETUP_OFFSET);
-   voltdm-write(OMAP3_VOLTOFFSET, OMAP3_PRM_VOLTOFFSET_OFFSET);
-   voltdm-write(OMAP3_VOLTSETUP2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+   voltdm-write(0, OMAP3_PRM_VOLTSETUP2_OFFSET);
 }
 
-static void __init omap3_vc_init_channel(struct voltagedomain *voltdm)
+/**
+ * omap3_set_off_timings - sets off-mode timings for a channel
+ * @voltdm: channel to configure
+ *
+ * Calculates and sets up off-mode timings for a channel. Off-mode
+ * can use either I2C based voltage scaling, or alternatively
+ * sys_off_mode pad can be used to send a global command to power IC.
+ * This function first checks which mode is being used, and calls
+ * omap3_set_i2c_timings() if the system is using I2C control mode.
+ * sys_off_mode has the additional benefit that voltages can be
+ * scaled to zero volt level with TWL4030 / TWL5030, I2C can only
+ * scale to 600mV.
+ */
+static void omap3_set_off_timings(struct voltagedomain *voltdm)
 {
-   static bool is_initialized;
+   unsigned long clksetup;
+   unsigned long voltsetup2;
+   unsigned long voltsetup2_old;
+   u32 val;
 
-   if (is_initialized)
+   /* check if sys_off_mode is used to control off-mode voltages */
+   val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
+   if (!(val  OMAP3430_SEL_OFF_MASK)) {
+   /* No, omap is controlling them over I2C */
+   omap3_set_i2c_timings(voltdm, true);
return;
+   }
 
-   omap3_vfsm_init(voltdm);
+   clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
 
-   is_initialized = true;
+   /* voltsetup 2 in us */
+   voltsetup2 = voltdm-vc_param-on / voltdm-pmic-slew_rate;
+
+   /* convert to 32k clk cycles */
+   voltsetup2 = DIV_ROUND_UP(voltsetup2 * 32768, 100);
+
+   voltsetup2_old = voltdm-read(OMAP3_PRM_VOLTSETUP2_OFFSET);
+
+   /*
+* Update voltsetup2 if higher than current value (needed because
+* we have multiple channels with different ramp times), also
+* update voltoffset always to value recommended by TRM
+*/
+   if (voltsetup2  voltsetup2_old) {
+   voltdm-write(voltsetup2, OMAP3_PRM_VOLTSETUP2_OFFSET);
+   voltdm-write(clksetup - voltsetup2,
+   OMAP3_PRM_VOLTOFFSET_OFFSET);
+   } else
+   voltdm-write(clksetup - voltsetup2_old,
+   OMAP3_PRM_VOLTOFFSET_OFFSET);
+
+   /*
+* omap is not controlling voltage scaling during off-mode,
+* thus set voltsetup1 to 0
+*/
+   voltdm-rmw(voltdm-vfsm-voltsetup_mask, 0,
+   voltdm-vfsm-voltsetup_reg);
+
+   /*

[PATCHv7 05/21] ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register

OMAP4 has two VOLTSETUP registers. One is controlling retention and
sleep voltage setup times, the other one off mode setup times. Both
of these need to be setup for stable behavior of the device.
The code setting up the new register will be added in the next
patch.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/voltage.h |2 ++
 arch/arm/mach-omap2/voltagedomains44xx_data.c |3 +++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 94c6919..01ab2e5 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -41,12 +41,14 @@ struct powerdomain;
  * data
  * @voltsetup_mask: SETUP_TIME* bitmask in the PRM_VOLTSETUP* register
  * @voltsetup_reg: register offset of PRM_VOLTSETUP from PRM base
+ * @voltsetup_off_reg: register offset of PRM_VOLTSETUP_OFF from PRM base
  *
  * XXX What about VOLTOFFSET/VOLTCTRL?
  */
 struct omap_vfsm_instance {
u32 voltsetup_mask;
u8 voltsetup_reg;
+   u8 voltsetup_off_reg;
 };
 
 /**
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c 
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index a2d7d9c..7da35a6 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -34,14 +34,17 @@
 
 static const struct omap_vfsm_instance omap4_vdd_mpu_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_MPU_RET_SLEEP_OFFSET,
+   .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_MPU_OFF_OFFSET,
 };
 
 static const struct omap_vfsm_instance omap4_vdd_iva_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_IVA_RET_SLEEP_OFFSET,
+   .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_IVA_OFF_OFFSET,
 };
 
 static const struct omap_vfsm_instance omap4_vdd_core_vfsm = {
.voltsetup_reg = OMAP4_PRM_VOLTSETUP_CORE_RET_SLEEP_OFFSET,
+   .voltsetup_off_reg = OMAP4_PRM_VOLTSETUP_CORE_OFF_OFFSET,
 };
 
 static struct voltagedomain omap4_voltdm_mpu = {
-- 
1.7.4.1

--
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

[PATCHv7 08/21] ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax

Now we select the vddmin and vddmax values based on both pmic and
voltage processor data, this allows usage of different power ICs.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/vp.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index c585dfb..c9277c3 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -58,8 +58,10 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
sys_clk_rate = voltdm-sys_clk.rate / 1000;
 
timeout = (sys_clk_rate * voltdm-pmic-vp_timeout_us) / 1000;
-   vddmin = voltdm-pmic-uv_to_vsel(voltdm-pmic-vddmin);
-   vddmax = voltdm-pmic-uv_to_vsel(voltdm-pmic-vddmax);
+   vddmin = max(voltdm-vp_param-vddmin, voltdm-pmic-vddmin);
+   vddmax = min(voltdm-vp_param-vddmax, voltdm-pmic-vddmax);
+   vddmin = voltdm-pmic-uv_to_vsel(vddmin);
+   vddmax = voltdm-pmic-uv_to_vsel(vddmax);
 
waittime = DIV_ROUND_UP(voltdm-pmic-step_size * sys_clk_rate,
1000 * voltdm-pmic-slew_rate);
-- 
1.7.4.1

--
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

[PATCHv7 09/21] ARM: OMAP3+: voltage: use oscillator data to calculate setup times

We now use the previously defined oscillator setup / shutdown times
to calculate the register values for CLKSETUP.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/vc.c |   62 ++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 26750fe..a587506 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -11,14 +11,20 @@
 #include linux/delay.h
 #include linux/init.h
 #include linux/bug.h
+#include linux/io.h
+
+#include asm/div64.h
 
 #include plat/cpu.h
 
+#include iomap.h
 #include voltage.h
 #include vc.h
 #include prm-regbits-34xx.h
 #include prm-regbits-44xx.h
 #include prm44xx.h
+#include pm.h
+#include scrm44xx.h
 
 /**
  * struct omap_vc_channel_cfg - describe the cfg_channel bitfield
@@ -206,6 +212,18 @@ int omap_vc_bypass_scale(struct voltagedomain *voltdm,
return 0;
 }
 
+/* Convert microsecond value to number of 32kHz clock cycles */
+static inline u32 omap_usec_to_32k(u32 usec)
+{
+   return DIV_ROUND_UP_ULL(32768ULL * (u64)usec, 100ULL);
+}
+
+/* Set oscillator setup time for omap3 */
+static void omap3_set_clksetup(u32 usec, struct voltagedomain *voltdm)
+{
+   voltdm-write(omap_usec_to_32k(usec), OMAP3_PRM_CLKSETUP_OFFSET);
+}
+
 /**
  * omap3_set_i2c_timings - sets i2c sleep timings for a channel
  * @voltdm: channel to configure
@@ -222,6 +240,12 @@ static void omap3_set_i2c_timings(struct voltagedomain 
*voltdm, bool off_mode)
unsigned long voltsetup1;
u32 tgt_volt;
 
+   /*
+* Oscillator is shut down only if we are using sys_off_mode pad,
+* thus we set a minimal setup time here
+*/
+   omap3_set_clksetup(1, voltdm);
+
if (off_mode)
tgt_volt = voltdm-vc_param-off;
else
@@ -262,6 +286,7 @@ static void omap3_set_off_timings(struct voltagedomain 
*voltdm)
unsigned long voltsetup2;
unsigned long voltsetup2_old;
u32 val;
+   u32 tstart, tshut;
 
/* check if sys_off_mode is used to control off-mode voltages */
val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
@@ -271,6 +296,9 @@ static void omap3_set_off_timings(struct voltagedomain 
*voltdm)
return;
}
 
+   omap_pm_get_oscillator(tstart, tshut);
+   omap3_set_clksetup(tstart, voltdm);
+
clksetup = voltdm-read(OMAP3_PRM_CLKSETUP_OFFSET);
 
/* voltsetup 2 in us */
@@ -367,6 +395,30 @@ static u32 omap4_calc_volt_ramp(struct voltagedomain 
*voltdm, u32 voltage_diff)
 }
 
 /**
+ * omap4_usec_to_val_scrm - convert microsecond value to SCRM module bitfield
+ * @usec: microseconds
+ * @shift: number of bits to shift left
+ * @mask: bitfield mask
+ *
+ * Converts microsecond value to OMAP4 SCRM bitfield. Bitfield is
+ * shifted to requested position, and checked agains the mask value.
+ * If larger, forced to the max value of the field (i.e. the mask itself.)
+ * Returns the SCRM bitfield value.
+ */
+static u32 omap4_usec_to_val_scrm(u32 usec, int shift, u32 mask)
+{
+   u32 val;
+
+   val = omap_usec_to_32k(usec)  shift;
+
+   /* Check for overflow, if yes, force to max value */
+   if (val  mask)
+   val = mask;
+
+   return val;
+}
+
+/**
  * omap4_set_timings - set voltage ramp timings for a channel
  * @voltdm: channel to configure
  * @off_mode: whether off-mode values are used
@@ -378,6 +430,7 @@ static void omap4_set_timings(struct voltagedomain *voltdm, 
bool off_mode)
u32 val;
u32 ramp;
int offset;
+   u32 tstart, tshut;
 
if (off_mode) {
ramp = omap4_calc_volt_ramp(voltdm,
@@ -399,6 +452,15 @@ static void omap4_set_timings(struct voltagedomain 
*voltdm, bool off_mode)
val |= ramp  OMAP4430_RAMP_UP_COUNT_SHIFT;
 
voltdm-write(val, offset);
+
+   omap_pm_get_oscillator(tstart, tshut);
+
+   val = omap4_usec_to_val_scrm(tstart, OMAP4_SETUPTIME_SHIFT,
+   OMAP4_SETUPTIME_MASK);
+   val |= omap4_usec_to_val_scrm(tshut, OMAP4_DOWNTIME_SHIFT,
+   OMAP4_DOWNTIME_MASK);
+
+   __raw_writel(val, OMAP4_SCRM_CLKSETUPTIME);
 }
 
 /* OMAP4 specific voltage init functions */
-- 
1.7.4.1

--
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

[PATCHv7 07/21] ARM: OMAP: add support for oscillator setup