date:20121128

Hi everyone,
this patch series aims at cleaning up of dss_features.c by moving features to
respective submodule drivers.

The 1st patch
 * moved struct omap_dss_features members burst_size_unit and buffer_size_unit
   to dispc_features
The 2nd patch
 * added definition of struct register_field
 * created enum dispc_feat_reg_field
 * moved data from dss_reg_fields to dispc_reg_fields
The 3rd patch
 * added definition of struct param_range
 * created enum dispc_range_param
 * moved data from dss_param_range to dispc_param_range
The 4th patch
 * created struct feats and initialized dsi_feats
 * created enum dsi_feat_reg_field
 * moved data from dss_reg_fields to dsi_reg_fields
 * created dsi_init_features() to initialize dsi_feats
The 5th patch
 * created enum dsi_range_param
 * moved data from dss_param_range to dsi_param_range
The 6th patch
 * added members fld_dispc_clk_switch and dss_fck_max to struct dss_features
   and initialized corresponding dss_feats
 * removed definition of dss_reg_field
 * removed respective omap2_dss_reg_fields, omap3_dss_reg_fields,
   omap4_dss_reg_fields and omap5_dss_reg_fields
 * removed members reg_fields and num_reg_fields from struct omap_dss_features
 * removed enum dss_feat_reg_field
 * removed function dss_feat_get_reg_field()
The 7th patch
 * added FEAT_PARAM_DSS_FCK to enum dsi_param_range and initialized
   corresponding elements in dsi_param_range
 * removed struct dss_param_range
 * removed enum dss_range_param
 * removed functions dss_feat_get_param_min() and dss_feat_get_param_max()

All your comments and suggestions are welcome.

I have based my patches on git://gitorious.org/linux-omap-dss2/linux.git master

Reference Tree:
git://gitorious.org/linux-omap-dss2/chandrabhanus-linux.git dss_cleanup

Regards,
Chandrabhanu

Chandrabhanu Mahapatra (7):
  OMAPDSS: DISPC: Move burst_size and buffer_size to dispc_features
  OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features
  OMAPDSS: DISPC: Move DISPC specific dss_params to dispc_features
  OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats
  OMAPDSS: DSI: Move DSI specific dss_params to dsi_feats
  OMAPDSS: DSS: Add members fld_dispc_clk_switch and dss_fck_max
  OMAPDSS: DSI: Add FEAT_PARAM_DSS_FCK

 drivers/video/omap2/dss/dispc.c|  188 ++--
 drivers/video/omap2/dss/dsi.c  |  198 ++---
 drivers/video/omap2/dss/dss.c  |   22 +++-
 drivers/video/omap2/dss/dss.h  |8 ++
 drivers/video/omap2/dss/dss_features.c |  212 
 drivers/video/omap2/dss/dss_features.h |   36 --
 6 files changed, 358 insertions(+), 306 deletions(-)

-- 
1.7.10

--
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 1/7] OMAPDSS: DISPC: Move burst_size and buffer_size to dispc_features

The burst_size and buffer_size being local data to DISPC are moved to
dispc_features and so removed from struct omap_dss_features. The functions
referring to burst and buffer size are also removed from dss_features.c as they
are now accessed locally in dispc.c.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dispc.c|   21 +
 drivers/video/omap2/dss/dss_features.c |   29 -
 drivers/video/omap2/dss/dss_features.h |3 ---
 3 files changed, 17 insertions(+), 36 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 3d0ff5b..9f259ba 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -104,6 +104,9 @@ struct dispc_features {
 
/* swap GFX  WB fifos */
bool gfx_fifo_workaround:1;
+
+   u32 buffer_size_unit;
+   u32 burst_size_unit;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -1056,7 +1059,7 @@ static void dispc_configure_burst_sizes(void)
 
 static u32 dispc_ovl_get_burst_size(enum omap_plane plane)
 {
-   unsigned unit = dss_feat_get_burst_size_unit();
+   unsigned unit = dispc.feat-burst_size_unit;
/* burst multiplier is always x8 (see dispc_configure_burst_sizes()) */
return unit * 8;
 }
@@ -1145,7 +1148,7 @@ static void dispc_init_fifos(void)
u8 start, end;
u32 unit;
 
-   unit = dss_feat_get_buffer_size_unit();
+   unit = dispc.feat-buffer_size_unit;
 
dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
 
@@ -1203,7 +1206,7 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, 
u32 low, u32 high)
u8 hi_start, hi_end, lo_start, lo_end;
u32 unit;
 
-   unit = dss_feat_get_buffer_size_unit();
+   unit = dispc.feat-buffer_size_unit;
 
WARN_ON(low % unit != 0);
WARN_ON(high % unit != 0);
@@ -1247,7 +1250,7 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane 
plane,
 * buffer_units, and the fifo thresholds must be buffer_unit aligned.
 */
 
-   unsigned buf_unit = dss_feat_get_buffer_size_unit();
+   unsigned buf_unit = dispc.feat-buffer_size_unit;
unsigned ovl_fifo_size, total_fifo_size, burst_size;
int i;
 
@@ -4095,6 +4098,8 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.calc_scaling   =   dispc_ovl_calc_scaling_24xx,
.calc_core_clk  =   calc_core_clk_24xx,
.num_fifos  =   3,
+   .buffer_size_unit   =   1,
+   .burst_size_unit=   8,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -4111,6 +4116,8 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
+   .buffer_size_unit   =   1,
+   .burst_size_unit=   8,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -4127,6 +4134,8 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
+   .buffer_size_unit   =   1,
+   .burst_size_unit=   8,
 };
 
 static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -4144,6 +4153,8 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
+   .buffer_size_unit   =   16,
+   .burst_size_unit=   16,
 };
 
 static const struct dispc_features omap54xx_dispc_feats __initconst = {
@@ -4161,6 +4172,8 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
+   .buffer_size_unit   =   16,
+   .burst_size_unit=   16,
 };
 
 static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 1d125c6..092e21b 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -54,9 +54,6 @@ struct omap_dss_features {
const struct dss_param_range *dss_params;
 
const enum omap_dss_rotation_type supported_rotation_types;
-
-   const u32 buffer_size_unit;
-   const u32 burst_size_unit;
 };
 
 /* This struct is assigned to one of the below during initialization */
@@ -632,8 +629,6 @@ static const struct

[PATCH 2/7] OMAPDSS: DISPC: Move DISPC specific dss_reg_fields to dispc_features

The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby enabling local access.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dispc.c|   87 
 drivers/video/omap2/dss/dss.h  |4 ++
 drivers/video/omap2/dss/dss_features.c |   28 --
 drivers/video/omap2/dss/dss_features.h |7 ---
 4 files changed, 80 insertions(+), 46 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9f259ba..21fc522 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -80,6 +80,16 @@ struct dispc_irq_stats {
unsigned irqs[32];
 };
 
+enum dispc_feat_reg_field {
+   FEAT_REG_FIRHINC,
+   FEAT_REG_FIRVINC,
+   FEAT_REG_FIFOLOWTHRESHOLD,
+   FEAT_REG_FIFOHIGHTHRESHOLD,
+   FEAT_REG_FIFOSIZE,
+   FEAT_REG_HORIZONTALACCU,
+   FEAT_REG_VERTICALACCU,
+};
+
 struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -107,6 +117,8 @@ struct dispc_features {
 
u32 buffer_size_unit;
u32 burst_size_unit;
+
+   struct register_field *reg_fields;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -1150,7 +1162,8 @@ static void dispc_init_fifos(void)
 
unit = dispc.feat-buffer_size_unit;
 
-   dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
+   start = dispc.feat-reg_fields[FEAT_REG_FIFOSIZE].start;
+   end = dispc.feat-reg_fields[FEAT_REG_FIFOSIZE].end;
 
for (fifo = 0; fifo  dispc.feat-num_fifos; ++fifo) {
size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
@@ -1214,8 +1227,10 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, 
u32 low, u32 high)
low /= unit;
high /= unit;
 
-   dss_feat_get_reg_field(FEAT_REG_FIFOHIGHTHRESHOLD, hi_start, hi_end);
-   dss_feat_get_reg_field(FEAT_REG_FIFOLOWTHRESHOLD, lo_start, lo_end);
+   hi_start = dispc.feat-reg_fields[FEAT_REG_FIFOHIGHTHRESHOLD].start;
+   hi_end = dispc.feat-reg_fields[FEAT_REG_FIFOHIGHTHRESHOLD].end;
+   lo_start = dispc.feat-reg_fields[FEAT_REG_FIFOLOWTHRESHOLD].start;
+   lo_end = dispc.feat-reg_fields[FEAT_REG_FIFOLOWTHRESHOLD].end;
 
DSSDBG(fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n,
plane,
@@ -1297,10 +1312,11 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
u8 hinc_start, hinc_end, vinc_start, vinc_end;
 
-   dss_feat_get_reg_field(FEAT_REG_FIRHINC,
-   hinc_start, hinc_end);
-   dss_feat_get_reg_field(FEAT_REG_FIRVINC,
-   vinc_start, vinc_end);
+   hinc_start = dispc.feat-reg_fields[FEAT_REG_FIRHINC].start;
+   hinc_end = dispc.feat-reg_fields[FEAT_REG_FIRHINC].end;
+   vinc_start = dispc.feat-reg_fields[FEAT_REG_FIRVINC].start;
+   vinc_end = dispc.feat-reg_fields[FEAT_REG_FIRVINC].end;
+
val = FLD_VAL(vinc, vinc_start, vinc_end) |
FLD_VAL(hinc, hinc_start, hinc_end);
 
@@ -1316,8 +1332,10 @@ static void dispc_ovl_set_vid_accu0(enum omap_plane 
plane, int haccu, int vaccu)
u32 val;
u8 hor_start, hor_end, vert_start, vert_end;
 
-   dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, hor_start, hor_end);
-   dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, vert_start, vert_end);
+   hor_start = dispc.feat-reg_fields[FEAT_REG_HORIZONTALACCU].start;
+   hor_end = dispc.feat-reg_fields[FEAT_REG_HORIZONTALACCU].end;
+   vert_start = dispc.feat-reg_fields[FEAT_REG_VERTICALACCU].start;
+   vert_end = dispc.feat-reg_fields[FEAT_REG_VERTICALACCU].end;
 
val = FLD_VAL(vaccu, vert_start, vert_end) |
FLD_VAL(haccu, hor_start, hor_end);
@@ -1330,8 +1348,10 @@ static void dispc_ovl_set_vid_accu1(enum omap_plane 
plane, int haccu, int vaccu)
u32 val;
u8 hor_start, hor_end, vert_start, vert_end;
 
-   dss_feat_get_reg_field(FEAT_REG_HORIZONTALACCU, hor_start, hor_end);
-   dss_feat_get_reg_field(FEAT_REG_VERTICALACCU, vert_start, vert_end);
+   hor_start = dispc.feat-reg_fields[FEAT_REG_HORIZONTALACCU].start;
+   hor_end = dispc.feat-reg_fields[FEAT_REG_HORIZONTALACCU].end;
+   vert_start = dispc.feat-reg_fields[FEAT_REG_VERTICALACCU].start;
+   vert_end = dispc.feat-reg_fields[FEAT_REG_VERTICALACCU].end;
 
val = FLD_VAL(vaccu, vert_start, vert_end) |
FLD_VAL(haccu, hor_start, hor_end);
@@ -4084,6 +4104,46 @@ static void _omap_dispc_initial_config(void)
dispc_ovl_enable_zorder_planes();
 }
 
+static struct register_field omap2_dispc_reg_fields[] = {
+   [FEAT_REG_FIRHINC]

[PATCH 3/7] OMAPDSS: DISPC: Move DISPC specific dss_params to dispc_features

The DISPC specific dss_param_range are moved from struct omap_dss_features to
corresponding DSS version specific dispc_param_range struct, initialized in
dispc_features thereby enabling local access. The mgr_width_max and
mgr_height_max, members of dispc_features, are also moved to dispc_param_range.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dispc.c|   80 +++-
 drivers/video/omap2/dss/dss.h  |4 ++
 drivers/video/omap2/dss/dss_features.c |   16 ---
 drivers/video/omap2/dss/dss_features.h |3 --
 4 files changed, 63 insertions(+), 40 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 21fc522..0b7388d 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,14 @@ enum dispc_feat_reg_field {
FEAT_REG_VERTICALACCU,
 };
 
+enum dispc_range_param {
+   FEAT_PARAM_PCD,
+   FEAT_PARAM_DOWNSCALE,
+   FEAT_PARAM_LINEWIDTH,
+   FEAT_PARAM_MGR_WIDTH,
+   FEAT_PARAM_MGR_HEIGHT,
+};
+
 struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -99,8 +107,6 @@ struct dispc_features {
u16 hp_max;
u8 mgr_width_start;
u8 mgr_height_start;
-   u16 mgr_width_max;
-   u16 mgr_height_max;
int (*calc_scaling) (enum omap_plane plane,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -119,6 +125,7 @@ struct dispc_features {
u32 burst_size_unit;
 
struct register_field *reg_fields;
+   struct param_range *params;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -2185,7 +2192,7 @@ static int dispc_ovl_calc_scaling_24xx(enum omap_plane 
plane,
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
const int maxsinglelinewidth =
-   dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+   dispc.feat-params[FEAT_PARAM_LINEWIDTH].max;
 
*five_taps = false;
 
@@ -2226,7 +2233,7 @@ static int dispc_ovl_calc_scaling_34xx(enum omap_plane 
plane,
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
const int maxsinglelinewidth =
-   dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+   dispc.feat-params[FEAT_PARAM_LINEWIDTH].max;
 
do {
in_height = DIV_ROUND_UP(height, *decim_y);
@@ -2292,8 +2299,8 @@ static int dispc_ovl_calc_scaling_44xx(enum omap_plane 
plane,
int decim_x_min = *decim_x;
u16 in_height = DIV_ROUND_UP(height, *decim_y);
const int maxsinglelinewidth =
-   dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
-   const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
+   dispc.feat-params[FEAT_PARAM_LINEWIDTH].max;
+   const int maxdownscale = dispc.feat-params[FEAT_PARAM_DOWNSCALE].max;
 
if (mem_to_mem) {
in_width_max = out_width * maxdownscale;
@@ -2333,7 +2340,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
int *x_predecim, int *y_predecim, u16 pos_x,
enum omap_dss_rotation_type rotation_type, bool mem_to_mem)
 {
-   const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
+   const int maxdownscale = dispc.feat-params[FEAT_PARAM_DOWNSCALE].max;
const int max_decim_limit = 16;
unsigned long core_clk = 0;
int decim_x, decim_y, ret;
@@ -3029,8 +3036,8 @@ void dispc_mgr_set_lcd_config(enum omap_channel channel,
 
 static bool _dispc_mgr_size_ok(u16 width, u16 height)
 {
-   return width = dispc.feat-mgr_width_max 
-   height = dispc.feat-mgr_height_max;
+   return width = dispc.feat-params[FEAT_PARAM_MGR_WIDTH].max 
+   height = dispc.feat-params[FEAT_PARAM_MGR_HEIGHT].max;
 }
 
 static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
@@ -3592,8 +3599,8 @@ void dispc_find_clk_divs(unsigned long req_pck, unsigned 
long fck,
u16 best_ld, cur_ld;
u16 best_pd, cur_pd;
 
-   pcd_min = dss_feat_get_param_min(FEAT_PARAM_DSS_PCD);
-   pcd_max = dss_feat_get_param_max(FEAT_PARAM_DSS_PCD);
+   pcd_min = dispc.feat-params[FEAT_PARAM_PCD].min;
+   pcd_max = dispc.feat-params[FEAT_PARAM_PCD].max;
 
best_pck = 0;
best_ld = 0;
@@ -4144,6 +4151,42 @@ static struct register_field omap5_dispc_reg_fields[] = {
[FEAT_REG_VERTICALACCU] = { 26, 16 },
 };
 
+static struct param_range omap2_dispc_param_range[] = {
+   [FEAT_PARAM_PCD]= { 2,  255 },
+   [FEAT_PARAM_DOWNSCALE]  = { 1,2 },
+   /*
+* Assuming the line width buffer to be 768 pixels as OMAP2 DISPC
+* scaler cannot scale a image with width more than 768.
+

[PATCH 4/7] OMAPDSS: DSI: Move DSI specific reg_fields to dsi_feats

The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in dsi_init_features().

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dsi.c  |  119 ++--
 drivers/video/omap2/dss/dss_features.c |   16 -
 drivers/video/omap2/dss/dss_features.h |4 --
 3 files changed, 113 insertions(+), 26 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf32dc7..2d387cb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -344,6 +344,19 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
 };
 
+enum dsi_feat_reg_field {
+   FEAT_REG_DSIPLL_REGN,
+   FEAT_REG_DSIPLL_REGM,
+   FEAT_REG_DSIPLL_REGM_DISPC,
+   FEAT_REG_DSIPLL_REGM_DSI,
+};
+
+struct feats {
+   const struct register_field *reg_fields;
+};
+
+static const struct feats *dsi_feat;
+
 #ifdef DEBUG
 static bool dsi_perf;
 module_param(dsi_perf, bool, 0644);
@@ -1645,12 +1658,15 @@ int dsi_pll_set_clock_div(struct platform_device 
*dsidev,

dss_feat_get_clk_source_name(OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI),
cinfo-dsi_pll_hsdiv_dsi_clk);
 
-   dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGN, regn_start, regn_end);
-   dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM, regm_start, regm_end);
-   dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM_DISPC, regm_dispc_start,
-   regm_dispc_end);
-   dss_feat_get_reg_field(FEAT_REG_DSIPLL_REGM_DSI, regm_dsi_start,
-   regm_dsi_end);
+   regn_start = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGN].start;
+   regn_end = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGN].end;
+   regm_start = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM].start;
+   regm_end = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM].end;
+   regm_dispc_start =
+   dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM_DISPC].start;
+   regm_dispc_end = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM_DISPC].end;
+   regm_dsi_start = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM_DSI].start;
+   regm_dsi_end = dsi_feat-reg_fields[FEAT_REG_DSIPLL_REGM_DSI].end;
 
/* DSI_PLL_AUTOMODE = manual */
REG_FLD_MOD(dsidev, DSI_PLL_CONTROL, 0, 0, 0);
@@ -5198,6 +5214,93 @@ static void __exit dsi_uninit_output(struct 
platform_device *dsidev)
dss_unregister_output(out);
 }
 
+static struct register_field omap2_dsi_reg_fields[] = {
+   [FEAT_REG_DSIPLL_REGN]  = { 0, 0 },
+   [FEAT_REG_DSIPLL_REGM]  = { 0, 0 },
+   [FEAT_REG_DSIPLL_REGM_DISPC]= { 0, 0 },
+   [FEAT_REG_DSIPLL_REGM_DSI]  = { 0, 0 },
+};
+
+static struct register_field omap3_dsi_reg_fields[] = {
+   [FEAT_REG_DSIPLL_REGN]  = {  7,  1 },
+   [FEAT_REG_DSIPLL_REGM]  = { 18,  8 },
+   [FEAT_REG_DSIPLL_REGM_DISPC]= { 22, 19 },
+   [FEAT_REG_DSIPLL_REGM_DSI]  = { 26, 23 },
+};
+
+static struct register_field omap4_dsi_reg_fields[] = {
+   [FEAT_REG_DSIPLL_REGN]  = {  8,  1 },
+   [FEAT_REG_DSIPLL_REGM]  = { 20,  9 },
+   [FEAT_REG_DSIPLL_REGM_DISPC]= { 25, 21 },
+   [FEAT_REG_DSIPLL_REGM_DSI]  = { 30, 26 },
+};
+
+static struct register_field omap5_dsi_reg_fields[] = {
+   [FEAT_REG_DSIPLL_REGN]  = {  8,  1 },
+   [FEAT_REG_DSIPLL_REGM]  = { 20,  9 },
+   [FEAT_REG_DSIPLL_REGM_DISPC]= { 25, 21 },
+   [FEAT_REG_DSIPLL_REGM_DSI]  = { 30, 26 },
+};
+
+static const struct feats omap24xx_dsi_feats __initconst = {
+   .reg_fields =   omap2_dsi_reg_fields,
+};
+
+static const struct feats omap34xx_dsi_feats __initconst = {
+   .reg_fields =   omap3_dsi_reg_fields,
+};
+
+static const struct feats omap44xx_dsi_feats __initconst = {
+   .reg_fields =   omap4_dsi_reg_fields,
+};
+
+static const struct feats omap54xx_dsi_feats __initconst = {
+   .reg_fields =   omap5_dsi_reg_fields,
+};
+
+static int __init dsi_init_features(struct platform_device *dsidev)
+{
+   const struct feats *src;
+   struct feats *dst;
+
+   dst = devm_kzalloc(dsidev-dev, sizeof(*dst), GFP_KERNEL);
+   if (!dst) {
+   dev_err(dsidev-dev, Failed to allocate DISPC Features\n);
+   return -ENOMEM;
+   }
+
+   switch (omapdss_get_version()) {
+   case OMAPDSS_VER_OMAP24xx:
+   src = omap24xx_dsi_feats;
+   break;
+
+   case OMAPDSS_VER_OMAP34xx_ES1:
+   case OMAPDSS_VER_OMAP34xx_ES3:
+   case OMAPDSS_VER_OMAP3630:
+   case OMAPDSS_VER_AM35xx:
+   src = omap34xx_dsi_feats;
+

[PATCH 5/7] OMAPDSS: DSI: Move DSI specific dss_params to dsi_feats

The DSI specific dss_param_range are moved from struct omap_dss_features to
corresponding struct dsi_param_range, which is initialized in struct dsi_feats
thereby enabling local access.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dsi.c  |   70 
 drivers/video/omap2/dss/dss_features.c |   27 
 drivers/video/omap2/dss/dss_features.h |7 
 3 files changed, 62 insertions(+), 42 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 2d387cb..f1f617c 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -351,8 +351,19 @@ enum dsi_feat_reg_field {
FEAT_REG_DSIPLL_REGM_DSI,
 };
 
+enum dsi_range_param {
+   FEAT_PARAM_DSIPLL_REGN,
+   FEAT_PARAM_DSIPLL_REGM,
+   FEAT_PARAM_DSIPLL_REGM_DISPC,
+   FEAT_PARAM_DSIPLL_REGM_DSI,
+   FEAT_PARAM_DSIPLL_FINT,
+   FEAT_PARAM_DSIPLL_LPDIV,
+   FEAT_PARAM_DSI_FCK,
+};
+
 struct feats {
const struct register_field *reg_fields;
+   const struct param_range *params;
 };
 
 static const struct feats *dsi_feat;
@@ -1518,7 +1529,7 @@ static void dsi_pll_calc_dsi_fck(struct platform_device 
*dsidev,
 {
unsigned long max_dsi_fck;
 
-   max_dsi_fck = dss_feat_get_param_max(FEAT_PARAM_DSI_FCK);
+   max_dsi_fck = dsi_feat-params[FEAT_PARAM_DSI_FCK].max;
 
cinfo-regm_dsi = DIV_ROUND_UP(cinfo-clkin4ddr, max_dsi_fck);
cinfo-dsi_pll_hsdiv_dsi_clk = cinfo-clkin4ddr / cinfo-regm_dsi;
@@ -5082,14 +5093,14 @@ static void dsi_calc_clock_param_ranges(struct 
platform_device *dsidev)
 {
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 
-   dsi-regn_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGN);
-   dsi-regm_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM);
+   dsi-regn_max = dsi_feat-params[FEAT_PARAM_DSIPLL_REGN].max;
+   dsi-regm_max = dsi_feat-params[FEAT_PARAM_DSIPLL_REGM].max;
dsi-regm_dispc_max =
-   dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM_DISPC);
-   dsi-regm_dsi_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_REGM_DSI);
-   dsi-fint_min = dss_feat_get_param_min(FEAT_PARAM_DSIPLL_FINT);
-   dsi-fint_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_FINT);
-   dsi-lpdiv_max = dss_feat_get_param_max(FEAT_PARAM_DSIPLL_LPDIV);
+   dsi_feat-params[FEAT_PARAM_DSIPLL_REGM_DISPC].max;
+   dsi-regm_dsi_max = dsi_feat-params[FEAT_PARAM_DSIPLL_REGM_DSI].max;
+   dsi-fint_min = dsi_feat-params[FEAT_PARAM_DSIPLL_FINT].min;
+   dsi-fint_max = dsi_feat-params[FEAT_PARAM_DSIPLL_FINT].max;
+   dsi-lpdiv_max = dsi_feat-params[FEAT_PARAM_DSIPLL_LPDIV].max;
 }
 
 static int dsi_get_clocks(struct platform_device *dsidev)
@@ -5242,20 +5253,63 @@ static struct register_field omap5_dsi_reg_fields[] = {
[FEAT_REG_DSIPLL_REGM_DSI]  = { 30, 26 },
 };
 
+static struct param_range omap2_dsi_param_range[] = {
+   [FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
+   [FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
+   [FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, 0 },
+   [FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, 0 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 0, 0 },
+   [FEAT_PARAM_DSIPLL_LPDIV]   = { 0, 0 },
+};
+
+static struct param_range omap3_dsi_param_range[] = {
+   [FEAT_PARAM_DSIPLL_REGN]= { 0, (1  7) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM]= { 0, (1  11) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  4) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1  4) - 1 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 75, 210 },
+   [FEAT_PARAM_DSIPLL_LPDIV]   = { 1, (1  13) - 1},
+   [FEAT_PARAM_DSI_FCK]= { 0, 17300 },
+};
+
+static struct param_range omap4_dsi_param_range[] = {
+   [FEAT_PARAM_DSIPLL_REGN]= { 0, (1  8) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM]= { 0, (1  12) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  5) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1  5) - 1 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+   [FEAT_PARAM_DSIPLL_LPDIV]   = { 0, (1  13) - 1 },
+   [FEAT_PARAM_DSI_FCK]= { 0, 17000 },
+};
+
+static struct param_range omap5_dsi_param_range[] = {
+   [FEAT_PARAM_DSIPLL_REGN]= { 0, (1  8) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM]= { 0, (1  12) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  5) - 1 },
+   [FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1  5) - 1 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+   [FEAT_PARAM_DSIPLL_LPDIV]   = { 0, (1  13) - 1 },
+   [FEAT_PARAM_DSI_FCK]=

[PATCH 6/7] OMAPDSS: DSS: Add members fld_dispc_clk_switch and dss_fck_max

The members fld_dispc_clk_switch and dss_fck_max are added to struct
dss_features and are initialized in corresponding dss_feats structure as per DSS
version. The reg_fields and num_reg_fields entries are removed from struct
omap_dss_features as they are no longer referenced.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dss.c  |   22 
 drivers/video/omap2/dss/dss_features.c |   57 
 drivers/video/omap2/dss/dss_features.h |6 
 3 files changed, 16 insertions(+), 69 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 6ca69d5..4d74fbe 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -69,6 +69,8 @@ struct dss_features {
u8 dss_fck_multiplier;
const char *clk_name;
int (*dpi_select_source)(enum omap_channel channel);
+   struct register_field fld_dispc_clk_switch;
+   int dss_fck_max;
 };
 
 static struct {
@@ -308,7 +310,6 @@ static void dss_select_dispc_clk_source(enum 
omap_dss_clk_source clk_src)
 {
struct platform_device *dsidev;
int b;
-   u8 start, end;
 
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
@@ -329,9 +330,8 @@ static void dss_select_dispc_clk_source(enum 
omap_dss_clk_source clk_src)
return;
}
 
-   dss_feat_get_reg_field(FEAT_REG_DISPC_CLK_SWITCH, start, end);
-
-   REG_FLD_MOD(DSS_CONTROL, b, start, end);/* DISPC_CLK_SWITCH */
+   REG_FLD_MOD(DSS_CONTROL, b, dss.feat-fld_dispc_clk_switch.start,
+   dss.feat-fld_dispc_clk_switch.end);  /* DISPC_CLK_SWITCH */
 
dss.dispc_clk_source = clk_src;
 }
@@ -497,7 +497,7 @@ static int dss_setup_default_clock(void)
if (dss.dpll4_m4_ck == NULL)
return 0;
 
-   max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+   max_dss_fck = dss.feat-dss_fck_max;
 
prate = dss_get_dpll4_rate();
 
@@ -533,7 +533,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct 
dss_clock_info *dss_cinfo,
 
prate = dss_get_dpll4_rate();
 
-   max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+   max_dss_fck = dss.feat-dss_fck_max;
 
fck = clk_get_rate(dss.dss_clk);
if (req_pck == dss.cache_req_pck  prate == dss.cache_prate 
@@ -822,6 +822,8 @@ static const struct dss_features omap24xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   2,
.clk_name   =   NULL,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .fld_dispc_clk_switch   =   { 0, 0 },
+   .dss_fck_max=   17300,
 };
 
 static const struct dss_features omap34xx_dss_feats __initconst = {
@@ -829,6 +831,8 @@ static const struct dss_features omap34xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   2,
.clk_name   =   dpll4_m4_ck,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .fld_dispc_clk_switch   =   { 0, 0 },
+   .dss_fck_max=   17300,
 };
 
 static const struct dss_features omap3630_dss_feats __initconst = {
@@ -836,6 +840,8 @@ static const struct dss_features omap3630_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.clk_name   =   dpll4_m4_ck,
.dpi_select_source  =   dss_dpi_select_source_omap2_omap3,
+   .fld_dispc_clk_switch   =   { 0, 0 },
+   .dss_fck_max=   17300,
 };
 
 static const struct dss_features omap44xx_dss_feats __initconst = {
@@ -843,6 +849,8 @@ static const struct dss_features omap44xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.clk_name   =   dpll_per_m5x2_ck,
.dpi_select_source  =   dss_dpi_select_source_omap4,
+   .fld_dispc_clk_switch   =   { 9, 8 },
+   .dss_fck_max=   18600,
 };
 
 static const struct dss_features omap54xx_dss_feats __initconst = {
@@ -850,6 +858,8 @@ static const struct dss_features omap54xx_dss_feats 
__initconst = {
.dss_fck_multiplier =   1,
.clk_name   =   dpll_per_h12x2_ck,
.dpi_select_source  =   dss_dpi_select_source_omap5,
+   .fld_dispc_clk_switch   =   { 9, 7 },
+   .dss_fck_max=   2,
 };
 
 static int __init dss_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 75dddb2..06c04f3 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -27,19 +27,11 @@
 #include dss.h
 #include dss_features.h
 
-/* Defines a generic omap register field */
-struct dss_reg_field {
-   u8 start, end;
-};
-
 struct dss_param_range {
int min, max;
 };
 
 struct

[PATCH 7/7] OMAPDSS: DSI: Add FEAT_PARAM_DSS_FCK

The FEAT_PARAM_DSS_FCK is added and initialized in corresponding DSS Version
specific struct dsi_param_range. As, the struct dss_param_range is no longer
used all its references are thereby removed from omap_dss_features.

Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
 drivers/video/omap2/dss/dsi.c  |9 ++--
 drivers/video/omap2/dss/dss_features.c |   39 
 drivers/video/omap2/dss/dss_features.h |6 -
 3 files changed, 7 insertions(+), 47 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index f1f617c..3e0e9d7 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -352,6 +352,7 @@ enum dsi_feat_reg_field {
 };
 
 enum dsi_range_param {
+   FEAT_PARAM_DSS_FCK,
FEAT_PARAM_DSIPLL_REGN,
FEAT_PARAM_DSIPLL_REGM,
FEAT_PARAM_DSIPLL_REGM_DISPC,
@@ -1353,7 +1354,7 @@ int dsi_pll_calc_clock_div_pck(struct platform_device 
*dsidev,
 
dss_sys_clk = clk_get_rate(dsi-sys_clk);
 
-   max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+   max_dss_fck = dsi_feat-params[FEAT_PARAM_DSS_FCK].max;
 
if (req_pck == dsi-cache_req_pck 
dsi-cache_cinfo.clkin == dss_sys_clk) {
@@ -1547,7 +1548,7 @@ static int dsi_pll_calc_dispc_fck(struct platform_device 
*dsidev,
struct dispc_clock_info best_dispc;
bool match;
 
-   max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+   max_dss_fck = dsi_feat-params[FEAT_PARAM_DSS_FCK].max;
 
min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
 
@@ -5254,6 +5255,7 @@ static struct register_field omap5_dsi_reg_fields[] = {
 };
 
 static struct param_range omap2_dsi_param_range[] = {
+   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, 0 },
@@ -5263,6 +5265,7 @@ static struct param_range omap2_dsi_param_range[] = {
 };
 
 static struct param_range omap3_dsi_param_range[] = {
+   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1  7) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1  11) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  4) - 1 },
@@ -5273,6 +5276,7 @@ static struct param_range omap3_dsi_param_range[] = {
 };
 
 static struct param_range omap4_dsi_param_range[] = {
+   [FEAT_PARAM_DSS_FCK]= { 0, 18600 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1  8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1  12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  5) - 1 },
@@ -5283,6 +5287,7 @@ static struct param_range omap4_dsi_param_range[] = {
 };
 
 static struct param_range omap5_dsi_param_range[] = {
+   [FEAT_PARAM_DSS_FCK]= { 0, 2 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1  8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1  12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  5) - 1 },
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 06c04f3..e7fca28 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -27,10 +27,6 @@
 #include dss.h
 #include dss_features.h
 
-struct dss_param_range {
-   int min, max;
-};
-
 struct omap_dss_features {
const enum dss_feat_id *features;
const int num_features;
@@ -43,7 +39,6 @@ struct omap_dss_features {
const enum omap_color_mode *supported_color_modes;
const enum omap_overlay_caps *overlay_caps;
const char * const *clksrc_names;
-   const struct dss_param_range *dss_params;
 
const enum omap_dss_rotation_type supported_rotation_types;
 };
@@ -343,22 +338,6 @@ static const char * const omap5_dss_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI]   = DPLL_DSI1_C_CLK2,
 };
 
-static const struct dss_param_range omap2_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
-};
-
-static const struct dss_param_range omap3_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
-};
-
-static const struct dss_param_range omap4_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 18600 },
-};
-
-static const struct dss_param_range omap5_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 2 },
-};
-
 static const enum dss_feat_id omap2_dss_feat_list[] = {
FEAT_LCDENABLEPOL,
FEAT_LCDENABLESIGNAL,
@@ -513,7 +492,6 @@ static const struct omap_dss_features omap2_dss_features = {
.supported_color_modes = omap2_dss_supported_color_modes,

Re: [rtc-linux] [PATCH v3 1/5] rtc: OMAP: Add system pm_power_off to rtc driver

2012-11-28 Thread Russell King - ARM Linux

On Tue, Nov 27, 2012 at 03:42:39PM -0800, Andrew Morton wrote:
  +   /* Do not allow to execute any other task */
  +   spin_lock_irqsave(lock, flags);
  +   while (1);
 
 I suspect this doesn't do what you want it to do.
 
 Firstly, please provide adequate code comments here so that code
 readers do not also need to be mind readers.
 
 If you want to stop this CPU dead in its tracks (why?) then
 
   local_irq_disable();
   while (1)
   ;   /* Note correct code layout */
 
 will do it.  But it means that the NMI watchdog (if present) will come
 along and whack the machine in the head a few seconds later.  And this
 does nothing to stop other CPUs.
 
 But not being a mind reader, I'm really at a loss to suggest what
 should be done here.  

It's hooking into the pm_power_off hook, which is called from kernel/sys.c
via arch code.  We will have already stopped all other CPUs at this point.

Why there's that while (1) there I don't know; when pm_power_off is not
hooked, we don't do anything like that - and what will happen in that
case is we'll return all the way back to sys_reboot(), which will call
do_exit(0) on us.

I don't see a problem with that, and I don't see why we need to spin
(without any power saving too) waiting for some event.  If we've called
sys_reboot with LINUX_REBOOT_CMD_POWER_OFF, we'd better have already
killed most of userspace off by that time anyway.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On 11/27/2012 09:22 PM, Andy Green wrote:
 On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
 On Wed, 28 Nov 2012, Andy Green wrote:

 Greg's advice was simply not to rely on pathnames in sysfs because they
 aren't fixed in stone.  That leaves plenty of other ways to approach
 this problem.

 It's sage advice, but there is zero code provided in my patches that
 relies on pathnames in sysfs.

 In your 1/5 patch, _device_path_generate() concatenates device name
 strings, starting from a device root and separating elements with '/'
 characters.  Isn't that the same as a sysfs pathname?
 
 It's nothing to do with sysfs... yes some unrelated bits of sysfs also
 walk the device path.  If we want to talk about how fragile the device
 path is as an id scheme over time we need to talk about likelihood of
 individual device names changing, not sysfs.  Anyway --
 
 Basically, what you want is for something related to device A (the
 regulator or the GPIO) to happen whenever device B (the ehci-omap.0
 platform device) is bound to a driver.  The most straightforward way to
 arrange this is for A's driver to have a callback that is invoked
 whenever B is bound or unbound.  The most straightforward way to
 arrange _that_ is to allow each platform_device to have a list of
 callbacks.

 Sorry I didn't really understand this proposal yet.  You want A, the
 regulator, driver to grow a callback function that gets called when the
 targeted platform_device (B, ehci-omap.0) probe happens.  Could you
 expand what the callback prototype or new members in the struct might
 look like?  It's your tuple thing or we pass it an opaque pointer that
 is the struct regulator * or suchlike?

 Well, it won't be exactly the same as the tuple thing because no
 strings will be involved, but it would be similar.  The callback would
 receive an opaque pointer (presumably to the regulator) and a device
 pointer (the B device).
 
 OK.  So I try to sketch it out iteractively to try to get in sync:
 
 device.h:
 
 enum asset_event {
 AE_PROBED,
 AE_REMOVED
 };
 
 struct device_asset {
 char *name; /* name of regulator, clock, etc */
 void *asset; /* regulator, clock, etc */
 int (*handler)(struct device *dev_owner, enum asset_event
 asset_event, struct device_asset *asset);
 };
 
 struct device {
 ...
 struct device_asset *assets;
 ...
 };
 
 
 drivers/base/dd.c | really_probe():
 
 ...
 struct device_asset *asset;
 ...
 asset = dev-assets;
 while (asset  asset-name) {
 if (asset-handler(dev, AE_PROBED, asset)) {
 /* clean up and bail */
 }
 asset++;
 }
 
 /* do probe */
 ...
 
 
 drivers/base/dd.c | __device_release_driver:  (is this really the best
 place to oppose probe()?)
 
 ...
 struct device_asset *asset;
 ...
 
 /* call device -remove() */
 ...
 asset = dev-assets;
 while (asset  asset-name) {
 asset-handler(dev, AE_REMOVED, asset);
 asset++;
 }
 ...
 
 
 board file:
 
 static struct regulator myreg = {
 .name = mydevice-regulator,
 };
 
 static struct device_asset mydevice_assets[] = {
 {
 .name = mydevice-regulator,
 .handler = regulator_default_asset_handler,
 },
 { }
 };
 
 static struct platform_device mydevice = {
 ...
 .dev = {
 .assets = mydevice_assets,
 },
 ...
 };
 

From Pandaboard's point of view, is mydevice supposed to be referring to
ehci-omap, LAN95xx or something else?

Strictly speaking, the regulator doesn't belongs neither to ehci-omap
nor LAN95xx. It belongs to a power domain on the board. And user should
have control to switch it OFF when required without hampering operation
of ehci-omap, so that the other USB ports are still usable.

--
regards,
-roger

--
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] OMAPDSS: Use only omapdss_dss platform device to get context lost count

2012-11-28 Thread Archit Taneja

When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.

All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the dss_core hwmod since
it's corresponding platform device is the parent platform device(omapdss_dss).
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.

The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance(omapdss_dispc). The DISPC platform
device is one of the child devices, and it's corresponding hwmod(dss_dispc)
doesn't report the context lost count correctly.

Modify dss_get_ctx_loss_count() such that it always takes the omapdss_dss
platform device as it's input, move the function to dss.c so that it has access
to that platform device.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/core.c  |   15 ---
 drivers/video/omap2/dss/dispc.c |4 ++--
 drivers/video/omap2/dss/dss.c   |   15 +++
 drivers/video/omap2/dss/dss.h   |3 ++-
 4 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index d94ef9e..ceb912b 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -93,21 +93,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
 }
 
-int dss_get_ctx_loss_count(struct device *dev)
-{
-   struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
-   int cnt;
-
-   if (!board_data-get_context_loss_count)
-   return -ENOENT;
-
-   cnt = board_data-get_context_loss_count(dev);
-
-   WARN_ONCE(cnt  0, get_context_loss_count failed: %d\n, cnt);
-
-   return cnt;
-}
-
 int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
 {
struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a5ab354..67d4497 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -374,7 +374,7 @@ static void dispc_save_context(void)
if (dss_has_feature(FEAT_CORE_CLK_DIV))
SR(DIVISOR);
 
-   dispc.ctx_loss_cnt = dss_get_ctx_loss_count(dispc.pdev-dev);
+   dispc.ctx_loss_cnt = dss_get_ctx_loss_count();
dispc.ctx_valid = true;
 
DSSDBG(context saved, ctx_loss_count %d\n, dispc.ctx_loss_cnt);
@@ -389,7 +389,7 @@ static void dispc_restore_context(void)
if (!dispc.ctx_valid)
return;
 
-   ctx = dss_get_ctx_loss_count(dispc.pdev-dev);
+   ctx = dss_get_ctx_loss_count();
 
if (ctx = 0  ctx == dispc.ctx_loss_cnt)
return;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 602102c..d2cbee2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -151,6 +151,21 @@ static void dss_restore_context(void)
 #undef SR
 #undef RR
 
+int dss_get_ctx_loss_count(void)
+{
+   struct omap_dss_board_info *board_data = dss.pdev-dev.platform_data;
+   int cnt;
+
+   if (!board_data-get_context_loss_count)
+   return -ENOENT;
+
+   cnt = board_data-get_context_loss_count(dss.pdev-dev);
+
+   WARN_ONCE(cnt  0, get_context_loss_count failed: %d\n, cnt);
+
+   return cnt;
+}
+
 void dss_sdi_init(int datapairs)
 {
u32 l;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6728892..5577660 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -190,7 +190,6 @@ const char *dss_get_default_display_name(void);
 struct bus_type *dss_get_bus(void);
 struct regulator *dss_get_vdds_dsi(void);
 struct regulator *dss_get_vdds_sdi(void);
-int dss_get_ctx_loss_count(struct device *dev);
 int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask);
 void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask);
 int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
@@ -309,6 +308,8 @@ void dss_dump_clocks(struct seq_file *s);
 void dss_debug_dump_clocks(struct seq_file *s);
 #endif
 
+int dss_get_ctx_loss_count(void);
+
 void dss_sdi_init(int datapairs);
 int dss_sdi_enable(void);
 void dss_sdi_disable(void);
-- 
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: [RFC PATCH 1/5] drivers : introduce device_path api


On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:

On 11/27/2012 09:22 PM, Andy Green wrote:

On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:

On Wed, 28 Nov 2012, Andy Green wrote:


Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone.  That leaves plenty of other ways to approach
this problem.


It's sage advice, but there is zero code provided in my patches that
relies on pathnames in sysfs.


In your 1/5 patch, _device_path_generate() concatenates device name
strings, starting from a device root and separating elements with '/'
characters.  Isn't that the same as a sysfs pathname?


It's nothing to do with sysfs... yes some unrelated bits of sysfs also
walk the device path.  If we want to talk about how fragile the device
path is as an id scheme over time we need to talk about likelihood of
individual device names changing, not sysfs.  Anyway --


Basically, what you want is for something related to device A (the
regulator or the GPIO) to happen whenever device B (the ehci-omap.0
platform device) is bound to a driver.  The most straightforward way to
arrange this is for A's driver to have a callback that is invoked
whenever B is bound or unbound.  The most straightforward way to
arrange _that_ is to allow each platform_device to have a list of
callbacks.


Sorry I didn't really understand this proposal yet.  You want A, the
regulator, driver to grow a callback function that gets called when the
targeted platform_device (B, ehci-omap.0) probe happens.  Could you
expand what the callback prototype or new members in the struct might
look like?  It's your tuple thing or we pass it an opaque pointer that
is the struct regulator * or suchlike?


Well, it won't be exactly the same as the tuple thing because no
strings will be involved, but it would be similar.  The callback would
receive an opaque pointer (presumably to the regulator) and a device
pointer (the B device).


OK.  So I try to sketch it out iteractively to try to get in sync:

device.h:

 enum asset_event {
 AE_PROBED,
 AE_REMOVED
 };

 struct device_asset {
 char *name; /* name of regulator, clock, etc */
 void *asset; /* regulator, clock, etc */
 int (*handler)(struct device *dev_owner, enum asset_event
asset_event, struct device_asset *asset);
 };

 struct device {
 ...
 struct device_asset *assets;
 ...
 };


drivers/base/dd.c | really_probe():

...
 struct device_asset *asset;
...
 asset = dev-assets;
 while (asset  asset-name) {
 if (asset-handler(dev, AE_PROBED, asset)) {
 /* clean up and bail */
 }
 asset++;
 }

 /* do probe */
...


drivers/base/dd.c | __device_release_driver:  (is this really the best
place to oppose probe()?)

...
 struct device_asset *asset;
...

 /* call device -remove() */
...
 asset = dev-assets;
 while (asset  asset-name) {
 asset-handler(dev, AE_REMOVED, asset);
 asset++;
 }
...


board file:

 static struct regulator myreg = {
 .name = mydevice-regulator,
 };

 static struct device_asset mydevice_assets[] = {
 {
 .name = mydevice-regulator,
 .handler = regulator_default_asset_handler,
 },
 { }
 };

 static struct platform_device mydevice = {
 ...
 .dev = {
 .assets = mydevice_assets,
 },
 ...
 };



 From Pandaboard's point of view, is mydevice supposed to be referring to
ehci-omap, LAN95xx or something else?

Strictly speaking, the regulator doesn't belongs neither to ehci-omap
nor LAN95xx. It belongs to a power domain on the board. And user should
have control to switch it OFF when required without hampering operation
of ehci-omap, so that the other USB ports are still usable.


I'd prefer to deal with that after a try#1 with regulator, I didn't see 
any code about power domain in there right now.  There's a lot to get 
consensus on already with this series.


Notice that these assets are generic, I will provide clk and regulator 
handlers with try#1, and working examples for Panda case with both, but 
presumably power domain can fold into it as well.


Since I am on usb-next and there's nothing to be seen about power 
domains, what is the situation with that support?


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
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: Use only omapdss_dss platform device to get context lost count

2012-11-28 Thread Archit Taneja


On Wednesday 28 November 2012 05:01 PM, Archit Taneja wrote:

When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.

All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the dss_core hwmod since
it's corresponding platform device is the parent platform device(omapdss_dss).
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.

The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance(omapdss_dispc). The DISPC platform
device is one of the child devices, and it's corresponding hwmod(dss_dispc)
doesn't report the context lost count correctly.

Modify dss_get_ctx_loss_count() such that it always takes the omapdss_dss
platform device as it's input, move the function to dss.c so that it has access
to that platform device.


I tested this on 4430sdp, panda and beagle. I forgot to mention that in 
the commit message. On beagle, I don't see the context lost count 
increase, but DVI works fine, it could be some problem with DSS PM on omap3.


Archit



Signed-off-by: Archit Taneja arc...@ti.com
---
  drivers/video/omap2/dss/core.c  |   15 ---
  drivers/video/omap2/dss/dispc.c |4 ++--
  drivers/video/omap2/dss/dss.c   |   15 +++
  drivers/video/omap2/dss/dss.h   |3 ++-
  4 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index d94ef9e..ceb912b 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -93,21 +93,6 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
  }

-int dss_get_ctx_loss_count(struct device *dev)
-{
-   struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
-   int cnt;
-
-   if (!board_data-get_context_loss_count)
-   return -ENOENT;
-
-   cnt = board_data-get_context_loss_count(dev);
-
-   WARN_ONCE(cnt  0, get_context_loss_count failed: %d\n, cnt);
-
-   return cnt;
-}
-
  int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask)
  {
struct omap_dss_board_info *board_data = core.pdev-dev.platform_data;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a5ab354..67d4497 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -374,7 +374,7 @@ static void dispc_save_context(void)
if (dss_has_feature(FEAT_CORE_CLK_DIV))
SR(DIVISOR);

-   dispc.ctx_loss_cnt = dss_get_ctx_loss_count(dispc.pdev-dev);
+   dispc.ctx_loss_cnt = dss_get_ctx_loss_count();
dispc.ctx_valid = true;

DSSDBG(context saved, ctx_loss_count %d\n, dispc.ctx_loss_cnt);
@@ -389,7 +389,7 @@ static void dispc_restore_context(void)
if (!dispc.ctx_valid)
return;

-   ctx = dss_get_ctx_loss_count(dispc.pdev-dev);
+   ctx = dss_get_ctx_loss_count();

if (ctx = 0  ctx == dispc.ctx_loss_cnt)
return;
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 602102c..d2cbee2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -151,6 +151,21 @@ static void dss_restore_context(void)
  #undef SR
  #undef RR

+int dss_get_ctx_loss_count(void)
+{
+   struct omap_dss_board_info *board_data = dss.pdev-dev.platform_data;
+   int cnt;
+
+   if (!board_data-get_context_loss_count)
+   return -ENOENT;
+
+   cnt = board_data-get_context_loss_count(dss.pdev-dev);
+
+   WARN_ONCE(cnt  0, get_context_loss_count failed: %d\n, cnt);
+
+   return cnt;
+}
+
  void dss_sdi_init(int datapairs)
  {
u32 l;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6728892..5577660 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -190,7 +190,6 @@ const char *dss_get_default_display_name(void);
  struct bus_type *dss_get_bus(void);
  struct regulator *dss_get_vdds_dsi(void);
  struct regulator *dss_get_vdds_sdi(void);
-int dss_get_ctx_loss_count(struct device *dev);
  int dss_dsi_enable_pads(int dsi_id, unsigned lane_mask);
  void dss_dsi_disable_pads(int dsi_id, unsigned lane_mask);
  int dss_set_min_bus_tput(struct device *dev, unsigned long tput);
@@ -309,6 +308,8 @@ void dss_dump_clocks(struct seq_file *s);
  void dss_debug_dump_clocks(struct seq_file *s);
  #endif

+int dss_get_ctx_loss_count(void);
+
  void dss_sdi_init(int datapairs);
  int

Re: [RFC PATCH 1/5] drivers : introduce device_path api

On 11/28/2012 01:47 PM, Andy Green wrote:
 On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
 On 11/27/2012 09:22 PM, Andy Green wrote:
 On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
 On Wed, 28 Nov 2012, Andy Green wrote:

 Greg's advice was simply not to rely on pathnames in sysfs because
 they
 aren't fixed in stone.  That leaves plenty of other ways to approach
 this problem.

 It's sage advice, but there is zero code provided in my patches that
 relies on pathnames in sysfs.

 In your 1/5 patch, _device_path_generate() concatenates device name
 strings, starting from a device root and separating elements with '/'
 characters.  Isn't that the same as a sysfs pathname?

 It's nothing to do with sysfs... yes some unrelated bits of sysfs also
 walk the device path.  If we want to talk about how fragile the device
 path is as an id scheme over time we need to talk about likelihood of
 individual device names changing, not sysfs.  Anyway --

 Basically, what you want is for something related to device A (the
 regulator or the GPIO) to happen whenever device B (the ehci-omap.0
 platform device) is bound to a driver.  The most straightforward
 way to
 arrange this is for A's driver to have a callback that is invoked
 whenever B is bound or unbound.  The most straightforward way to
 arrange _that_ is to allow each platform_device to have a list of
 callbacks.

 Sorry I didn't really understand this proposal yet.  You want A, the
 regulator, driver to grow a callback function that gets called when
 the
 targeted platform_device (B, ehci-omap.0) probe happens.  Could you
 expand what the callback prototype or new members in the struct might
 look like?  It's your tuple thing or we pass it an opaque pointer that
 is the struct regulator * or suchlike?

 Well, it won't be exactly the same as the tuple thing because no
 strings will be involved, but it would be similar.  The callback would
 receive an opaque pointer (presumably to the regulator) and a device
 pointer (the B device).

 OK.  So I try to sketch it out iteractively to try to get in sync:

 device.h:

  enum asset_event {
  AE_PROBED,
  AE_REMOVED
  };

  struct device_asset {
  char *name; /* name of regulator, clock, etc */
  void *asset; /* regulator, clock, etc */
  int (*handler)(struct device *dev_owner, enum asset_event
 asset_event, struct device_asset *asset);
  };

  struct device {
  ...
  struct device_asset *assets;
  ...
  };


 drivers/base/dd.c | really_probe():

 ...
  struct device_asset *asset;
 ...
  asset = dev-assets;
  while (asset  asset-name) {
  if (asset-handler(dev, AE_PROBED, asset)) {
  /* clean up and bail */
  }
  asset++;
  }

  /* do probe */
 ...


 drivers/base/dd.c | __device_release_driver:  (is this really the best
 place to oppose probe()?)

 ...
  struct device_asset *asset;
 ...

  /* call device -remove() */
 ...
  asset = dev-assets;
  while (asset  asset-name) {
  asset-handler(dev, AE_REMOVED, asset);
  asset++;
  }
 ...


 board file:

  static struct regulator myreg = {
  .name = mydevice-regulator,
  };

  static struct device_asset mydevice_assets[] = {
  {
  .name = mydevice-regulator,
  .handler = regulator_default_asset_handler,
  },
  { }
  };

  static struct platform_device mydevice = {
  ...
  .dev = {
  .assets = mydevice_assets,
  },
  ...
  };


  From Pandaboard's point of view, is mydevice supposed to be referring to
 ehci-omap, LAN95xx or something else?

 Strictly speaking, the regulator doesn't belongs neither to ehci-omap
 nor LAN95xx. It belongs to a power domain on the board. And user should
 have control to switch it OFF when required without hampering operation
 of ehci-omap, so that the other USB ports are still usable.
 
 I'd prefer to deal with that after a try#1 with regulator, I didn't see
 any code about power domain in there right now.  There's a lot to get
 consensus on already with this series.

Sure. I meant power domain in the general sense and not referring to any
code or framework in the kernel. It could as well be implemented using
the existing regulator framework.

 
 Notice that these assets are generic, I will provide clk and regulator
 handlers with try#1, and working examples for Panda case with both, but
 presumably power domain can fold into it as well.
 
 Since I am on usb-next and there's nothing to be seen about power
 domains, what is the situation with that support?
 

Looking around there seems to be some power domain framework tied to
runtime PM in drivers/base/power/domain.c

The idea is that the power domain is powered on/off by the runtime PM
core when the device is runtime resumed/suspended. I think this is meant
for SoC

[try#1 PATCH 0/7] Introduce device_asset and use to control Panda HUB+ETH power and clock

The following series implements the device_asset addition to
struct device that has been discussed on the usb and omap lists
with Alan Stern and GKH.  Several of the ideas here are from Alan
Stern.

First we add the new struct to linux/device.h and cause it to be
used just before device probe with one device_asset-specific
callback to enable the assets and just after device removal
with another device_asset-specific callback to disable the
associated assets.

Typical assets are things like regulators and clocks which are
not known to the generic driver but which are bound to the
specific device instance by hardware design.

Second we provide stock, default device_asset callbacks if your
asset is a struct regulator.  You can just use those and the
regulator will have a get and enable until the device instance
is removed, when it will be disabled and put.

Third we provide the same for struct clk.  These stock callbacks
mean there won't be any code duplication caused in the common case.

Fourth we remove all the struct regulator code from ehci-omap.

Fifth we implement Panda HUB+ETH (smsc95xx chip) regulator control
using the device_asset scheme.  Since the right device, ehci-omap.0
is created under mfd, the device_asset array is passed in
platform_data to the right place where it's added to the
platform_device's device before registration.

Sixth we add the Panda's external ULPI PHY clock to the
device_asset array we established for the regulator case above.

The end result is we are able to remove the code about regulator
and don't need any for clock control in the generic drivers.
Instead we are able to associate the board-specific prerequisites
for the drivers to work on a board externally with the enable and
disable hidden in the plumbing.

The end result is power and clock to the HUB+PHY (smsc95xx chip)
remains off until ehci-hcd module is inserted, and both are
disabled again when the module is removed.

---

Andy Green (7):
  drivers: base: introduce device assets
  regulator: core: add default device asset handlers
  clk: add default device asset handlers
  usb: omap ehci: remove all regulator control from ehci omap
  omap4: panda: add smsc95xx regulator and reset dependent on root hub
  omap4 panda add smsc95xx clock dependent on root hub
  config omap2plus add ehci bits


 arch/arm/configs/omap2plus_defconfig   |   42 +---
 arch/arm/mach-omap2/board-omap4panda.c |  113 +++-
 arch/arm/mach-omap2/usb-host.c |2 -
 arch/arm/plat-omap/include/plat/usb.h  |9 +--
 drivers/base/dd.c  |   36 ++
 drivers/clk/clkdev.c   |   39 +++
 drivers/mfd/omap-usb-host.c|9 ++-
 drivers/regulator/core.c   |   34 ++
 drivers/usb/host/ehci-omap.c   |   37 --
 include/linux/clk.h|   33 +
 include/linux/device.h |   25 +++
 include/linux/regulator/machine.h  |   30 
 12 files changed, 303 insertions(+), 106 deletions(-)

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

[try#1 PATCH 1/7] drivers: base: introduce device assets

This patch adds support for a new struct device member assets
which may point to an array of struct assets.

The array is terminated by one with a NULL pre_probe callback.

These assets consist of named (in .name) or anonymous object
pointers (.data) operated on by specified callbacks.  A void *
is provided to give configuration data or pointer if needed.

Before device probe, any assets associated with the device have
their pre_probe() callback called, which will typically enable
them, and after device removal the post_remove() callback is
called which will typically disable them.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 drivers/base/dd.c  |   36 
 include/linux/device.h |   25 +
 2 files changed, 61 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..d37210a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -261,6 +261,7 @@ static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
 
 static int really_probe(struct device *dev, struct device_driver *drv)
 {
+   struct device_asset *asset;
int ret = 0;
 
atomic_inc(probe_count);
@@ -275,6 +276,23 @@ static int really_probe(struct device *dev, struct 
device_driver *drv)
goto probe_failed;
}
 
+   asset = dev-assets;
+   while (asset  asset-pre_probe) {
+   dev_info(dev, Enabling pre-probe asset %s\n, asset-name);
+   ret = asset-pre_probe(dev, asset);
+   if (ret) {
+   dev_err(dev, Error Enabling pre-probe asset %s\n,
+ asset-name);
+   if (asset != dev-assets)
+   do {
+   asset--;
+   asset-post_remove(dev, asset);
+   } while (asset != dev-assets);
+   goto probe_failed;
+   }
+   asset++;
+   }
+
if (dev-bus-probe) {
ret = dev-bus-probe(dev);
if (ret)
@@ -478,6 +496,7 @@ EXPORT_SYMBOL_GPL(driver_attach);
 static void __device_release_driver(struct device *dev)
 {
struct device_driver *drv;
+   struct device_asset *asset;
 
drv = dev-driver;
if (drv) {
@@ -496,6 +515,23 @@ static void __device_release_driver(struct device *dev)
dev-bus-remove(dev);
else if (drv-remove)
drv-remove(dev);
+
+   asset = dev-assets;
+   if (asset) {
+   /* remove in reverse order */
+   while (asset-pre_probe)
+   asset++;
+
+   if (asset != dev-assets)
+   do {
+   asset--;
+   dev_info(dev,
+  Disabling post-remove asset %s\n,
+ asset-name);
+   asset-post_remove(dev, asset);
+   } while (asset != dev-assets);
+   }
+
devres_release_all(dev);
dev-driver = NULL;
dev_set_drvdata(dev, NULL);
diff --git a/include/linux/device.h b/include/linux/device.h
index 86ef6ab..6eabe1d 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -577,6 +577,26 @@ struct device_dma_parameters {
 };
 
 /**
+ * struct device_asset - a prerequisite for this device's probing
+ * @name:  Name of the regulator, clock, etc.  Optional.
+ * @asset: Pointer to the regulator, clock, etc.  If no name is given,
+ * this can be set before device probe, otherwise the pre_probe
+ * handler will dereference the name and store a pointer here
+ * @data:  Optional configuration data the asset may need
+ * @pre_probe: Called before this device this is associated with gets
+ * probed.
+ * @post_remove: Called after this device instance gets removed.
+ */
+
+struct device_asset {
+   const char *name;
+   void *asset;
+   void *data;
+   int (*pre_probe)(struct device *device, struct device_asset *asset);
+   void (*post_remove)(struct device *device, struct device_asset *asset);
+};
+
+/**
  * struct device - The basic device structure
  * @parent:The device's parent device, the device to which it is 
attached.
  * In most cases, a parent device is some sort of bus or host
@@ -600,6 +620,9 @@ struct device_dma_parameters {
  * variants, which GPIO pins act in what additional roles, and so
  * on.  This shrinks the Board Support Packages (BSPs) and
  * minimizes board-specific #ifdefs in drivers.
+ * @assets:Pointer to a NULL-pre_probe terminated array of

[try#1 PATCH 2/7] regulator: core: add default device asset handlers

This adds default device_asset handlers for struct regulator.  If you
want an associated regulator asset of a device to be powered before
probe, and depowered after removal, these callbacks will take care of
everything including get and put.

By defining them here in regulator core, code duplication at the usages
is nipped in the bud.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 drivers/regulator/core.c  |   34 ++
 include/linux/regulator/machine.h |   30 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e872c8b..1834e41 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3495,6 +3495,40 @@ void regulator_unregister(struct regulator_dev *rdev)
 }
 EXPORT_SYMBOL_GPL(regulator_unregister);
 
+/*
+ * Default handlers for regulator asset preprobe and postremoval
+ */
+int regulator_asset_default_preprobe(struct device *device,
+   struct device_asset *asset)
+{
+   struct regulator **reg = (struct regulator **)asset-asset;
+   int n;
+
+   *reg = regulator_get(device, asset-name);
+   if (IS_ERR(*reg))
+   return PTR_ERR(*reg);
+   n = regulator_enable(*reg);
+   if (n  0)
+   regulator_put(*reg);
+
+   dev_info(device, Enabled regulator asset %s\n, asset-name);
+
+   return n;
+}
+EXPORT_SYMBOL_GPL(regulator_asset_default_preprobe);
+
+void regulator_asset_default_postremove(struct device *device,
+   struct device_asset *asset)
+{
+   struct regulator *reg = asset-asset;
+
+   dev_info(device, Disabling post-remove asset %s\n, asset-name);
+
+   regulator_disable(reg);
+   regulator_put(reg);
+}
+EXPORT_SYMBOL_GPL(regulator_asset_default_postremove);
+
 /**
  * regulator_suspend_prepare - prepare regulators for system wide suspend
  * @state: system suspend state
diff --git a/include/linux/regulator/machine.h 
b/include/linux/regulator/machine.h
index 36adbc8..151a330 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -191,9 +191,39 @@ int regulator_suspend_prepare(suspend_state_t state);
 int regulator_suspend_finish(void);
 
 #ifdef CONFIG_REGULATOR
+/**
+ * regulator_asset_default_preprobe: default probe handler for regulator assets
+ * @device:the device whose assets we are enabling just before probing it
+ * @asset: the named regulator asset we are going to get and enable
+ *
+ * You can give this as the handler for .pre_probe callback in device_asset to
+ * deal with pre-enabling/get of a device's named regulator assets
+ */
+int regulator_asset_default_preprobe(struct device *device,
+   struct device_asset *asset);
+/**
+ * regulator_asset_default_postremove: default remove handler for reg assets
+ * @device:the device whose assets we are disabling just after removing it
+ * @asset: the regulator asset we are going to disable and put
+ *
+ * You can give this as the handler for .post_remove callback in device_asset
+ * to deal with post-disabling/put of a device's regulator assets
+ */
+void regulator_asset_default_postremove(struct device *device,
+   struct device_asset *asset);
+
 void regulator_has_full_constraints(void);
 void regulator_use_dummy_regulator(void);
 #else
+static inline int regulator_asset_default_preprobe(struct device *device,
+   struct device_asset *asset)
+{
+   return 0;
+}
+static inline void regulator_asset_default_postremove(struct device *device,
+   struct device_asset *asset)
+{
+}
 static inline void regulator_has_full_constraints(void)
 {
 }

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

[try#1 PATCH 3/7] clk: add default device asset handlers

This adds default device_asset handlers for struct clk.  If you
want an associated clk asset of a device to be optionally set, and
enabled  before probe, and disabled after removal, these callbacks
will take care of everything including get and put.

By defining them here in regulator core, code duplication at the usages
is nipped in the bud.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 drivers/clk/clkdev.c |   39 +++
 include/linux/clk.h  |   33 -
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..01d3fcd 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -327,3 +327,42 @@ int clk_register_clkdevs(struct clk *clk, struct 
clk_lookup *cl, size_t num)
return 0;
 }
 EXPORT_SYMBOL(clk_register_clkdevs);
+
+/*
+ * Default handlers for clock asset preprobe and postremoval
+ */
+int clk_asset_default_preprobe(struct device *device,
+   struct device_asset *asset)
+{
+   struct clk **clk = (struct clk **)asset-asset;
+   int n;
+
+   *clk = clk_get(device, asset-name);
+   if (IS_ERR(*clk))
+   return PTR_ERR(*clk);
+   if (asset-data) {
+   n = clk_set_rate(*clk, (unsigned long)asset-data);
+   if (n  0)
+   goto bail;
+   }
+   n = clk_prepare_enable(*clk);
+   if (n  0)
+   goto bail;
+
+   return 0;
+bail:
+   clk_put(*clk);
+
+   return n;
+}
+EXPORT_SYMBOL_GPL(clk_asset_default_preprobe);
+
+void clk_asset_default_postremove(struct device *device,
+   struct device_asset *asset)
+{
+   struct clk **clk = (struct clk **)asset-asset;
+
+   clk_disable_unprepare(*clk);
+   clk_put(*clk);
+}
+EXPORT_SYMBOL_GPL(clk_asset_default_postremove);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index b3ac22d..3956675 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -17,6 +17,7 @@
 #include linux/notifier.h
 
 struct device;
+struct device_asset;
 
 struct clk;
 
@@ -276,6 +277,27 @@ struct clk *clk_get_parent(struct clk *clk);
  */
 struct clk *clk_get_sys(const char *dev_id, const char *con_id);
 
+/**
+ * clk_asset_default_preprobe: default probe handler for clock device assets
+ * @device:the device whose assets we are enabling just before probing it
+ * @asset: the clock asset we are going to get and enable
+ *
+ * You can give this as the handler for .pre_probe callback in device_asset to
+ * deal with pre-enabling/get of a device's clock assets
+ */
+int clk_asset_default_preprobe(struct device *device,
+   struct device_asset *asset);
+/**
+ * clk_asset_default_postremove: default remove handler for clock device assets
+ * @device:the device whose assets we are disabling just after removing it
+ * @asset: the clock asset we are going to disable and put
+ *
+ * You can give this as the handler for .post_remove callback in device_asset
+ * to deal with post-disabling/put of a device's clock assets
+ */
+void clk_asset_default_postremove(struct device *device,
+   struct device_asset *asset);
+
 #else /* !CONFIG_HAVE_CLK */
 
 static inline struct clk *clk_get(struct device *dev, const char *id)
@@ -323,7 +345,16 @@ static inline struct clk *clk_get_parent(struct clk *clk)
 {
return NULL;
 }
-
+static inline int clk_asset_default_preprobe(struct device *device,
+   struct device_asset *asset)
+{
+   return 0;
+}
+static inline void clk_asset_default_postremove(struct device *device,
+   struct device_asset *asset)
+{
+}
+s
 #endif
 
 /* clk_prepare_enable helps cases using clk_enable in non-atomic context. */

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

[try#1 PATCH 4/7] usb: omap ehci: remove all regulator control from ehci omap

This series migrates it to be assets of the logical ehci-omap.0
device object.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 arch/arm/mach-omap2/usb-host.c|1 -
 arch/arm/plat-omap/include/plat/usb.h |7 --
 drivers/usb/host/ehci-omap.c  |   37 -
 3 files changed, 45 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..98f3287 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -498,7 +498,6 @@ void __init usbhs_init(const struct usbhs_omap_board_data 
*pdata)
ohci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.port_mode[i] = pdata-port_mode[i];
ehci_data.reset_gpio_port[i] = pdata-reset_gpio_port[i];
-   ehci_data.regulator[i] = pdata-regulator[i];
}
ehci_data.phy_reset = pdata-phy_reset;
ohci_data.es2_compatibility = pdata-es2_compatibility;
diff --git a/arch/arm/plat-omap/include/plat/usb.h 
b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..70acdee 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -36,12 +36,6 @@ struct usbhs_omap_board_data {
unsignedes2_compatibility:1;
 
unsignedphy_reset:1;
-
-   /*
-* Regulators for USB PHYs.
-* Each PHY can have a separate regulator.
-*/
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
 };
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
@@ -49,7 +43,6 @@ struct usbhs_omap_board_data {
 struct ehci_hcd_omap_platform_data {
enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
int reset_gpio_port[OMAP3_HS_USB_PORTS];
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
unsignedphy_reset:1;
 };
 
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 44e7d0f..7ab7c54 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -40,7 +40,6 @@
 #include linux/slab.h
 #include linux/usb/ulpi.h
 #include plat/usb.h
-#include linux/regulator/consumer.h
 #include linux/pm_runtime.h
 #include linux/gpio.h
 #include linux/clk.h
@@ -149,19 +148,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
 }
 
-static void disable_put_regulator(
-   struct ehci_hcd_omap_platform_data *pdata)
-{
-   int i;
-
-   for (i = 0 ; i  OMAP3_HS_USB_PORTS ; i++) {
-   if (pdata-regulator[i]) {
-   regulator_disable(pdata-regulator[i]);
-   regulator_put(pdata-regulator[i]);
-   }
-   }
-}
-
 /* configure so an HC device and id are always provided */
 /* always called with process context; sleeping is OK */
 
@@ -175,14 +161,11 @@ static void disable_put_regulator(
 static int ehci_hcd_omap_probe(struct platform_device *pdev)
 {
struct device   *dev = pdev-dev;
-   struct ehci_hcd_omap_platform_data  *pdata = dev-platform_data;
struct resource *res;
struct usb_hcd  *hcd;
void __iomem*regs;
int ret = -ENODEV;
int irq;
-   int i;
-   charsupply[7];
 
if (usb_disabled())
return -ENODEV;
@@ -223,23 +206,6 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
hcd-rsrc_len = resource_size(res);
hcd-regs = regs;
 
-   /* get ehci regulator and enable */
-   for (i = 0 ; i  OMAP3_HS_USB_PORTS ; i++) {
-   if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
-   pdata-regulator[i] = NULL;
-   continue;
-   }
-   snprintf(supply, sizeof(supply), hsusb%d, i);
-   pdata-regulator[i] = regulator_get(dev, supply);
-   if (IS_ERR(pdata-regulator[i])) {
-   pdata-regulator[i] = NULL;
-   dev_dbg(dev,
-   failed to get ehci port%d regulator\n, i);
-   } else {
-   regulator_enable(pdata-regulator[i]);
-   }
-   }
-
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
@@ -261,11 +227,9 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
goto err_pm_runtime;
}
 
-
return 0;
 
 err_pm_runtime:
-   disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
 
@@ -290,7 +254,6 @@ static int ehci_hcd_omap_remove(struct platform_device 
*pdev)
struct ehci_hcd_omap_platform_data *pdata   = dev-platform_data;

[try#1 PATCH 5/7] omap4: panda: add smsc95xx regulator and reset dependent on root hub

This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.

The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb - mfd path.  Although the ehci-related
platform_device is created at boot time, it is not instantiated until the
ehci-hcd module is inserted if it is modular.

Since the regulator is an asset of the ehci-omap.0 device, it's turned on
during successful probe and off when the device is removed.

Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.

This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted.  When the module is removed, it's depowered
again.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 arch/arm/mach-omap2/board-omap4panda.c |  100 ++--
 arch/arm/mach-omap2/usb-host.c |1 
 arch/arm/plat-omap/include/plat/usb.h  |2 +
 drivers/mfd/omap-usb-host.c|9 ++-
 4 files changed, 89 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..52add03 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -144,6 +144,15 @@ static struct platform_device *panda_devices[] __initdata 
= {
btwilink_device,
 };
 
+static struct device_asset assets_ehci_omap0[] = {
+   {
+   .name = reg-panda-smsc95xx,
+   .pre_probe = regulator_asset_default_preprobe,
+   .post_remove = regulator_asset_default_postremove,
+   },
+   { }
+};
+
 static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
@@ -151,12 +160,8 @@ static const struct usbhs_omap_board_data usbhs_bdata 
__initconst = {
.phy_reset  = false,
.reset_gpio_port[0]  = -EINVAL,
.reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
-};
-
-static struct gpio panda_ehci_gpios[] __initdata = {
-   { GPIO_HUB_POWER,   GPIOF_OUT_INIT_LOW,  hub_power  },
-   { GPIO_HUB_NRESET,  GPIOF_OUT_INIT_LOW,  hub_nreset },
+   .reset_gpio_port[2]  = -EINVAL,
+   .assets = assets_ehci_omap0,
 };
 
 static void __init omap4_ehci_init(void)
@@ -173,23 +178,76 @@ static void __init omap4_ehci_init(void)
clk_set_rate(phy_ref_clk, 1920);
clk_prepare_enable(phy_ref_clk);
 
-   /* disable the power to the usb hub prior to init and reset phy+hub */
-   ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
-   if (ret) {
-   pr_err(Unable to initialize EHCI power/reset\n);
-   return;
-   }
+   usbhs_init(usbhs_bdata);
+}
 
-   gpio_export(GPIO_HUB_POWER, 0);
-   gpio_export(GPIO_HUB_NRESET, 0);
-   gpio_set_value(GPIO_HUB_NRESET, 1);
+/*
+ * hub_nreset also resets the ULPI PHY and is required after powering SMSC chip
+ * ULPI PHY is always powered... need to do reset once for both once
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
 
-   usbhs_init(usbhs_bdata);
+static struct regulator_init_data panda_hub = {
+   .constraints = {
+   .name = vhub,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+};
 
-   /* enable power to hub */
-   gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct fixed_voltage_config panda_vhub = {
+   .supply_name = vhub,
+   .microvolts = 330,
+   .gpio = GPIO_HUB_POWER,
+   .startup_delay = 7, /* 70msec */
+   .enable_high = 1,
+   .enabled_at_boot = 0,
+   .init_data = panda_hub,
+};
+
+static struct platform_device omap_vhub_device = {
+   .name   = reg-fixed-voltage,
+   .id = 2,
+   .dev = {
+   .platform_data = panda_vhub,
+   },
+};
+
+static struct regulator_init_data panda_ulpireset = {
+   /*
+* idea is that when operating ulpireset, regulator api will make
+* sure that the hub+eth chip is powered, since it's the parent
+*/
+   .supply_regulator = vhub, /* we are a child of vhub */
+   .constraints = {
+   /*
+* this magic string associates us with ehci-omap.0 root hub
+* when the root hub logical device is up, we will power
+* and reset [ ULPI PHY + [ HUB + ETH ] ]
+*/
+   .name = reg-panda-smsc95xx,
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+};
+
+static struct fixed_voltage_config panda_vulpireset = {
+   .supply_name =

[try#1 PATCH 6/7] omap4 panda add smsc95xx clock dependent on root hub

This patch makes the ULPI PHY clock control also be a device_asset
of the ehci-omap.0 device, along with the [HUB + ETH] smsc95xx chip
power regulator.

Without clock control, the PHY clock is running all the time from
boot whether USB is in use or not, and during suspend distorting
power measurements there.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 arch/arm/mach-omap2/board-omap4panda.c |   25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 52add03..97489c7 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -150,6 +150,12 @@ static struct device_asset assets_ehci_omap0[] = {
.pre_probe = regulator_asset_default_preprobe,
.post_remove = regulator_asset_default_postremove,
},
+   {
+   .name = auxclk3_ck,
+   .data = (void *)1920,
+   .pre_probe = clk_asset_default_preprobe,
+   .post_remove = clk_asset_default_postremove,
+   },
{ }
 };
 
@@ -164,23 +170,6 @@ static const struct usbhs_omap_board_data usbhs_bdata 
__initconst = {
.assets = assets_ehci_omap0,
 };
 
-static void __init omap4_ehci_init(void)
-{
-   int ret;
-   struct clk *phy_ref_clk;
-
-   /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
-   phy_ref_clk = clk_get(NULL, auxclk3_ck);
-   if (IS_ERR(phy_ref_clk)) {
-   pr_err(Cannot request auxclk3\n);
-   return;
-   }
-   clk_set_rate(phy_ref_clk, 1920);
-   clk_prepare_enable(phy_ref_clk);
-
-   usbhs_init(usbhs_bdata);
-}
-
 /*
  * hub_nreset also resets the ULPI PHY and is required after powering SMSC chip
  * ULPI PHY is always powered... need to do reset once for both once
@@ -567,7 +556,7 @@ static void __init omap4_panda_init(void)
omap_serial_init();
omap_sdrc_init(NULL, NULL);
omap4_twl6030_hsmmc_init(mmc);
-   omap4_ehci_init();
+   usbhs_init(usbhs_bdata);
usb_musb_init(musb_board_data);
omap4_panda_display_init();
 }

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

[try#1 PATCH 7/7] config omap2plus add ehci bits

omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 arch/arm/configs/omap2plus_defconfig |   42 ++
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 6230304..2f858a3 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -1,14 +1,14 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,16 +20,15 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
+CONFIG_SOC_OMAP5=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
-CONFIG_LEDS=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
@@ -87,22 +86,21 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_NET_SMSC95XX=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_LIBERTAS=m
+CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_SDIO=m
+CONFIG_LIBERTAS_DEBUG=y
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -132,14 +130,13 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_WATCHDOG=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
-CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_REGULATOR_TWL4030=y
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -154,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -174,13 +170,15 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_EHCI_HCD_PLATFORM=m
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
-CONFIG_USB_LIBUSUAL=y
 CONFIG_USB_TEST=y
+CONFIG_OMAP_USB2=m
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
@@ -214,23 +212,18 @@ CONFIG_JFFS2_RUBIN=y
 CONFIG_UBIFS_FS=y
 CONFIG_CRAMFS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
@@ -239,4 +232,3 @@ CONFIG_CRC_T10DIF=y
 CONFIG_CRC_ITU_T=y
 CONFIG_CRC7=y
 CONFIG_LIBCRC32C=y
-CONFIG_SOC_OMAP5=y

--
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: OMAP* Latest build failures

2012-11-28 Thread Eduardo Valentin


Tony, Russell,

On 20-11-2012 13:57, Tony Lindgren wrote:

* Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:

On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:

OMAP* allnoconfig fails:

arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput'
arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup':
twl-common.c:(.init.text+0x8f8): undefined reference to `omap_pm_if_early_init'
arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port':
twl-common.c:(.init.text+0x1284): undefined reference to 
`omap_pm_get_dev_context_loss_count'
arch/arm/mach-omap2/built-in.o: In function `omap_timer_init':
twl-common.c:(.init.text+0x1544): undefined reference to 
`omap_pm_get_dev_context_loss_count'
arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init':
twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init'
arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
twl-common.c:(.init.text+0x2168): undefined reference to 
`omap_pm_get_dev_context_loss_count'
arch/arm/mach-omap2/built-in.o: In function `omap_display_init':
twl-common.c:(.init.text+0x25cc): undefined reference to 
`omap_pm_get_dev_context_loss_count'


These are now gone, but we have a new warning:

arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined but 
not used


Jon, care to fix this one?


And the randconfig found:

drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_readl':
drivers/staging/omap-thermal/omap-bandgap.c:46:2: error: implicit declaration 
of function 'readl'
drivers/staging/omap-thermal/omap-bandgap.c: In function 'omap_bandgap_writel':
drivers/staging/omap-thermal/omap-bandgap.c:51:2: error: implicit declaration 
of function 'writel'

Which, as its in staging, maybe its not important but it's another source
of unnecessary failure.


Well, it is important, thanks for checking this code. I appreciate if 
you keep your report.




Radhesh  Eduardo, can you fix this?



This has been already fixed:
https://patchwork.kernel.org/patch/1734621/

And is already queued by Greg (staging-next):
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=commit;h=2aeeb8acfc19f8a9f283081bbf77919b61b92042


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 v4 0/3] pwm: Drivers for twl4030/6030 PWMs and LEDs

2012-11-28 Thread Thierry Reding

On Tue, Nov 27, 2012 at 11:09:56AM +0100, Peter Ujfalusi wrote:
 Hello,
 
 Changes since v3:
 - pwm-twl-led driver's comment fix patch squashed to the original patch
 - Documentation for the DT bindings of the PWM drivers
 Comments from Thierry Reding addressed:
 - pwm-twl6030 has been removed in the last patch
 - macro for twl_pwm_chip/twl_pwmled_chip lookup
 - locking for read-modify-write sequences
 - separate pwm_ops strictures for twl4030 and twl6030 class
 - _devexit_P() removed
 - Do not select HAVE_PWM in Kconfig file since it is going away AFAIK:
   https://patchwork.kernel.org/patch/1544851/
 - Remaining (smaller) comments from Thierry also has been addressed.
 
 Changes since v2:
 - New PWM cycle calculation for twl-pwm driver and twl4030's pwm-twl-led with
   comment to document the expected behaviour.
 
 Changes cince v1:
 - The turn on/off sequence has been corrected for twl4030 PWMs as suggested by
   Grazvydas Ignotas
 - Comment section added to the new drivers to describe what they are 
 controlling
 
 The series has been tested (with additional, pending patches):
 Zoom2 for twl4030 PWM0 (keypad light), PWM1 (LCD backlight)
 BeagleBoard for twl4030 LEDB (PWMB - pmu_stat led)
 OMAP4 Blaze (SDP4430) for twl6030 PWM1 (keypad light), PWM2 (LCD backlight) 
 and
 LED (charging indication led).
 
 Intro mail from v1:
 
 The currently available pwm-twl6030.c driver only supports TWL6030's Charging
 indication LED.
 Remove this driver and add two new ones which implements support for all PWM
 driven outputs:
 pwm-twl driver supports twl4030 (PWM 0/1) and twl6030 (PWM 1/2) instances
 pwm-twl-led driver supports twl4030 (PWM driven LED A/B ports) and twl6030's
 Charging indication LED (PWM driven).
 
 Regards,
 Peter
 ---
 Peter Ujfalusi (3):
   pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
   pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of
 PMICs
   pwm: Remove pwm-twl6030 driver
 
  .../devicetree/bindings/pwm/ti,twl-pwm.txt |  17 +
  .../devicetree/bindings/pwm/ti,twl-pwmled.txt  |  17 +
  drivers/pwm/Kconfig|  17 +-
  drivers/pwm/Makefile   |   3 +-
  drivers/pwm/pwm-twl-led.c  | 342 
  drivers/pwm/pwm-twl.c  | 357 
 +
  drivers/pwm/pwm-twl6030.c  | 184 ---
  7 files changed, 748 insertions(+), 189 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
  create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
  create mode 100644 drivers/pwm/pwm-twl-led.c
  create mode 100644 drivers/pwm/pwm-twl.c
  delete mode 100644 drivers/pwm/pwm-twl6030.c

Applied with minor fixups, thanks.

Thierry


pgp1IaMpHyBNe.pgp
Description: PGP signature

Re: [PATCH v5 00/12] Support for AM33xx PWM Subsystem

2012-11-28 Thread Thierry Reding

On Tue, Nov 27, 2012 at 02:18:05PM +0530, Philip, Avinash wrote:
In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to
PWM subsystem. All these submodules shares the resources (clock) has
a clock gating register in PWM Subsystem. This patch series creates a
parent PWM Subsystem driver to handle access synchronization of shared
resources clock gating from PWM Subsystem configuration space.
Also Device tree nodes populated to support parent child relation
between PWMSS, ECAP EHRPWM submodules.
In addition EHRPWM module requires explicit clock gating from control
module is handled by patch #6 7.

As suggested by Thierry for handling clock gating for PWM submodules
should handle with a global function. This requires config space
handling done independent from driver and is done at parent driver.

So the parent-child relation adopted to handle
1. pm runtime synchronization
2. PWM subsystem common config space clock gating for PWM submodules.

Patches supports
- Driver support for parent child relation handled patch #1
- HWMOD data correction in EPWMSS at patch #2
- Parent child in HWMOD relation handled at patch #3
- Optional EHRPWM tb clock in patch #6
- Support for TBCLK clock gating at patch #7.
- Device tree binding support handled in patch #4,8
- Pinctrl support in patch #5 9.
- DT node populated in patch #10 ,11 12.

This patch series based on omap_dt/for_3.8/dts_part2 and tested
on am335x-evm am335x-evmsk.

This patch series will come under 3 subsystem basically. But sent
it in single patch series to have a clearer picture of why the
OMAP subsystem changes required.

Patches come under PWM (1,4,5,7,8,9)
Patches come under OMAP (2,3,6)
Patches come under DT (10,11,12).

It depends on [1]
1.
https://gitorious.org/linux-pwm/linux-pwm/commit/83af24027b3df1af5c5a9aa9adcdcfeb3429d3be
pwm: Device tree support for PWM polarity

Changes since v3:
- Rebased on top of omap_dt/for_3.8/dts_part2
- Add pwm backlight for am335xevm_sk
- Moved tipwmss.h to pwm-tipwmss.h

Philip, Avinash (12):
PWMSS: Add PWM Subsystem driver for parent-child relationship
ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM
subsystem
pwm: tiecap: Add device-tree binding
pwm: pwm-tiecap: pinctrl support
ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
pwm: pwm-tiehrpwm: Adding TBCLK gating support.
pwm: tiehrpwm: Add device-tree binding
pwm: pwm-tiehrpwm: pinctrl support
ARM: dts: AM33XX: Add PWMSS device tree nodes
ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

Patches 1, 4, 5, 7, 8 and 9 applied, with a minor fixup to the subject
line of patch 1. Thanks.

Thierry

pgpQeygLxXjOO.pgp
Description: PGP signature

[PATCH v5 1/4] mtd: omap-nand: pass device_node in platform data

Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.

For non-DT boards, this change has no effect.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+   struct mtd_part_parser_data ppdata = {};
 
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1556,7 +1557,8 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
goto out_release_mem_region;
}
 
-   mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+   ppdata.of_node = pdata-of_node;
+   mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
  pdata-nr_parts);
 
platform_set_drvdata(pdev, info-mtd);
-- 
1.7.11.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

[PATCH v5 2/4] ARM: OMAP: gpmc-nand: drop __init annotation

gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..f9f23a2 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -89,7 +89,7 @@ static int omap2_nand_gpmc_retime(
return 0;
 }
 
-static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
/* support only OMAP3 class */
if (!cpu_is_omap34xx()) {
@@ -110,8 +110,8 @@ static bool __init gpmc_hwecc_bch_capable(enum omap_ecc 
ecc_opt)
return 1;
 }
 
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
- struct gpmc_timings *gpmc_t)
+int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
+  struct gpmc_timings *gpmc_t)
 {
int err = 0;
struct device *dev = gpmc_nand_device.dev;
-- 
1.7.11.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

[PATCH v5 3/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/gpmc-nand.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index f9f23a2..c8a72ba 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
 static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
/* support only OMAP3 class */
-   if (!cpu_is_omap34xx()) {
+   if (!cpu_is_omap34xx()  !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
 
/*
-* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
-* Other chips may be added if confirmed to work.
+* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
+* and AM33xx derivates. Other chips may be added if confirmed to work.
 */
if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW) 
-   (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+   (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)) 
+   (!soc_is_am33xx())) {
pr_err(BCH 4-bit mode is not supported on this CPU\n);
return 0;
}
-- 
1.7.11.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

[PATCH v5 0/4] OMAP GPMC DT bindings

This is a series of patches to support GPMC peripherals on OMAP boards.

Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)

The only supported peripheral for now is NAND, but other types would be
easy to add.

Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed
and Rob Herring:

 - add reg and ti,hwmod properties to Documentation
 - use generic of_mtd functions and the property names defined by them,
   namely nand-bus-width and nand-ecc-mode
 - reduce the default register space size in the Documentation to 8K,
   as found in the hwmod code
 - switch to a DT layout based on ranges and address translation.
   Although this property is not currently looked at as long as the
   handling code still uses the runtime calculation methods, we now
   have these values in the bindings, eventually allowing us to
   switch the implementation with less pain.

Version 3 includes fixes pointed out by Jon Hunter:

 - better documentation of the 'ranges' property to describe the
   fact that it's representing the CS lines
 - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments
 - drop interrupt-parent from example bindings
 - add of_node_put() at the end of the child iteration

Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more
details from Jon Hunter and Avinash, Philip:

 - Add num-cs and num-waitpins properties, which will eventually
   be used to get rid of GPMC_CS_NUM
 - Better description of generic nand DT properties
 - Dropped patch 3/4 as an equivalent fix was already merged
 - Added ti,nand-ecc-use-elm property

Version 5 with regards to Avinash, Philip and Peter Korsgaard:

 - Re-add accidentially forgotten
   Documentation/devicetree/bindings/bus/ti-gpmc.txt
 - Rename software ecc mode to sw
 - Initialize gpmc_nand_data-is_elm_used to 'true' rather than 1
 - Drop ti,nand-ecc-use-elm binding in favor of a new ecc mode
   named bch8-am335xrbl-compatible
 - Add two more patches for section mismatch fixups

Daniel Mack (4):
  mtd: omap-nand: pass device_node in platform data
  ARM: OMAP: gpmc-nand: drop __init annotation
  ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
  ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
 arch/arm/mach-omap2/gpmc-nand.c|  15 +-
 arch/arm/mach-omap2/gpmc.c | 181 -
 drivers/mtd/nand/omap2.c   |   4 +-
 5 files changed, 348 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

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

[PATCH v5 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.

Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.

Successfully tested on an AM33xx board.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
 arch/arm/mach-omap2/gpmc.c | 181 -
 3 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 000..ba3d6a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,76 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to ti,gpmc
+ - reg:A resource specifier for the register space
+   (see the example below)
+ - ti,hwmods:  Should be set to ti,gpmc until the DT transition is
+   completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:Must be set to 1 to allow CS address passing
+ - num-cs: The maximum number of chip-select lines that controller
+   can support.
+ - num-waitpins:   The maximum number of wait pins that controller can
+   support.
+ - ranges: Must be set up to reflect the memory layout with four
+   integer values for each chip-select line in use:
+
+  cs-number 0 physical address of mapping size
+
+   Note that this property is not currently parsed.
+   Calculated values derived from the contents of the
+   per-CS register GPMC_CONFIG7 (as set up by the
+   bootloader) are used. That will change in the future,
+   so be sure to fill the correct values here.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk:  Minimum clock period for synchronous mode, in 
picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:Assertion time
+ - gpmc,adv-rd-off:Read deassertion time
+ - gpmc,adv-wr-off:Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off:Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off:Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle:  Total read cycle time
+ - gpmc,wr-cycle:  Total write cycle time
+
+The following are only on OMAP3430:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+   gpmc: gpmc@5000 {
+   compatible = ti,gpmc;
+   ti,hwmods = gpmc;
+   reg = 0x5000 0x2000;
+   interrupts = 100;
+
+   num-cs = 8;
+   #address-cells = 2;
+   #size-cells = 1;
+   ranges = 0 0 0x0800 0x1000; /* CS0 @addr 0x800, 
size 0x1000 */
+
+   /* child nodes go here */
+   };
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..635f550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,81 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of nand.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional

[PATCH v2 00/22] OMAP USB Host cleanup

Hi,

This patchset addresses the following

- Avoid addressing clocks one by one by name and use a for loop + bunch
  of cleanups.
- Get number of channels/ports dynamically either from revision register
  or from platform data. Avoids getting clocks that are not present.
- Add OMAP5 and HSIC mode (Not tested)

changes in v2:
- Clocks are allocated dynamically based on number of ports available
on the platform
- Reduced console spam if non critical clocks are not found on the platform.
- Get rid of cpu_is_.. macros from USB host driver.

cheers,
-roger

--

Roger Quadros (22):
  mfd: omap-usb-tll: Avoid creating copy of platform data
  mfd: omap-usb-tll: Fix channel count detection
  mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path
  mfd: omap-usb-tll: Clean up clock handling
  mfd: omap-usb-tll: introduce and use mode_needs_tll()
  mfd: omap-usb-tll: Check for missing platform data in probe
  mfd: omap-usb-tll: Fix error message
  mfd: omap-usb-tll: serialize access to TLL device
  mfd: omap-usb-tll: Add OMAP5 revision and HSIC support
  mfd: omap_usb_host: Avoid creating copy of platform_data
  mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap()
  mfd: omap-usb-host: know about number of ports from revision register
  mfd: omap-usb-host: override number of ports from platform data
  mfd: omap-usb-host: cleanup clock management code
  ARM: OMAP2+: clock data: Merge utmi_px_gfclk into
usb_host_hs_utmi_px_clk
  mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
  mfd: omap-usb-host: Get rid of unnecessary spinlock
  mfd: omap-usb-host: get rid of cpu_is_omap..() macros
  mfd: omap-usb-host: clean up omap_usbhs_init()
  USB: ehci-omap: Don't free gpios that we didn't request
  ARM: OMAP2+: clock data: get rid of unused USB host clock aliases
  mfd: omap-usb-host: Don't spam console on clk_set_parent failure

 arch/arm/mach-omap2/clock3xxx_data.c  |   13 -
 arch/arm/mach-omap2/clock44xx_data.c  |   30 +--
 arch/arm/mach-omap2/usb-host.c|5 +
 arch/arm/plat-omap/include/plat/usb.h |5 +
 drivers/mfd/omap-usb-host.c   |  467 +++--
 drivers/mfd/omap-usb-tll.c|  244 ++
 drivers/usb/host/ehci-omap.c  |8 -
 7 files changed, 421 insertions(+), 351 deletions(-)

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

[PATCH v2 01/22] mfd: omap-usb-tll: Avoid creating copy of platform data

Just a pointer to the platform data should suffice.

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/omap-usb-tll.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 4b7757b..d1750a4 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,7 +98,7 @@
 struct usbtll_omap {
struct clk  *usbtll_p1_fck;
struct clk  *usbtll_p2_fck;
-   struct usbtll_omap_platform_dataplatdata;
+   struct usbtll_omap_platform_data*pdata;
/* secure the register updates */
spinlock_t  lock;
 };
@@ -223,8 +223,7 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
 
spin_lock_init(tll-lock);
 
-   for (i = 0; i  OMAP3_HS_USB_PORTS; i++)
-   tll-platdata.port_mode[i] = pdata-port_mode[i];
+   tll-pdata = pdata;
 
tll-usbtll_p1_fck = clk_get(dev, usb_tll_hs_usb_ch0_clk);
if (IS_ERR(tll-usbtll_p1_fck)) {
@@ -362,7 +361,7 @@ static int __devexit usbtll_omap_remove(struct 
platform_device *pdev)
 static int usbtll_runtime_resume(struct device *dev)
 {
struct usbtll_omap  *tll = dev_get_drvdata(dev);
-   struct usbtll_omap_platform_data*pdata = tll-platdata;
+   struct usbtll_omap_platform_data*pdata = tll-pdata;
unsigned long   flags;
 
dev_dbg(dev, usbtll_runtime_resume\n);
@@ -388,7 +387,7 @@ static int usbtll_runtime_resume(struct device *dev)
 static int usbtll_runtime_suspend(struct device *dev)
 {
struct usbtll_omap  *tll = dev_get_drvdata(dev);
-   struct usbtll_omap_platform_data*pdata = tll-platdata;
+   struct usbtll_omap_platform_data*pdata = tll-pdata;
unsigned long   flags;
 
dev_dbg(dev, usbtll_runtime_suspend\n);
-- 
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

[PATCH v2 02/22] mfd: omap-usb-tll: Fix channel count detection

Fix channel count detecion for REV2. Also, don't give up
if we don't recognize the IP Revision. We assume the default
number of channels (i.e. 3) for unrecognized IPs.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index d1750a4..c083001 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,6 +98,7 @@
 struct usbtll_omap {
struct clk  *usbtll_p1_fck;
struct clk  *usbtll_p2_fck;
+   int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
/* secure the register updates */
spinlock_t  lock;
@@ -210,7 +211,7 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
unsignedreg;
unsigned long   flags;
int ret = 0;
-   int i, ver, count;
+   int i, ver;
 
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
 
@@ -262,16 +263,18 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
-   case OMAP_USBTLL_REV2:
-   count = OMAP_TLL_CHANNEL_COUNT;
+   tll-nch = OMAP_TLL_CHANNEL_COUNT;
break;
+   case OMAP_USBTLL_REV2:
case OMAP_USBTLL_REV3:
-   count = OMAP_REV2_TLL_CHANNEL_COUNT;
+   tll-nch = OMAP_REV2_TLL_CHANNEL_COUNT;
break;
default:
-   dev_err(dev, TLL version failed\n);
-   ret = -ENODEV;
-   goto err_ioremap;
+   tll-nch = OMAP_TLL_CHANNEL_COUNT;
+   dev_dbg(dev,
+USB TLL Rev : 0x%x not recognized, assuming %d channels\n,
+   ver, tll-nch);
+   break;
}
 
if (is_ehci_tll_mode(pdata-port_mode[0]) ||
@@ -291,7 +294,7 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
 
/* Enable channels now */
-   for (i = 0; i  count; i++) {
+   for (i = 0; i  tll-nch; i++) {
reg = usbtll_read(base, OMAP_TLL_CHANNEL_CONF(i));
 
if (is_ohci_port(pdata-port_mode[i])) {
@@ -319,7 +322,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
}
}
 
-err_ioremap:
spin_unlock_irqrestore(tll-lock, flags);
iounmap(base);
pm_runtime_put_sync(dev);
-- 
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

[PATCH v2 03/22] mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path

Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   37 +++--
 1 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index c083001..ff5e16f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -215,11 +215,10 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
 
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
 
-   tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
+   tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL);
if (!tll) {
dev_err(dev, Memory allocation failed\n);
-   ret = -ENOMEM;
-   goto end;
+   return -ENOMEM;
}
 
spin_lock_init(tll-lock);
@@ -230,28 +229,21 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
if (IS_ERR(tll-usbtll_p1_fck)) {
ret = PTR_ERR(tll-usbtll_p1_fck);
dev_err(dev, usbtll_p1_fck failed error:%d\n, ret);
-   goto err_tll;
+   return ret;
}
 
tll-usbtll_p2_fck = clk_get(dev, usb_tll_hs_usb_ch1_clk);
if (IS_ERR(tll-usbtll_p2_fck)) {
ret = PTR_ERR(tll-usbtll_p2_fck);
dev_err(dev, usbtll_p2_fck failed error:%d\n, ret);
-   goto err_usbtll_p1_fck;
+   goto err_p2_fck;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res) {
-   dev_err(dev, usb tll get resource failed\n);
-   ret = -ENODEV;
-   goto err_usbtll_p2_fck;
-   }
-
-   base = ioremap(res-start, resource_size(res));
+   base = devm_request_and_ioremap(dev, res);
if (!base) {
-   dev_err(dev, TLL ioremap failed\n);
-   ret = -ENOMEM;
-   goto err_usbtll_p2_fck;
+   ret = -EADDRNOTAVAIL;
+   goto err_res;
}
 
platform_set_drvdata(pdev, tll);
@@ -323,23 +315,17 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
}
 
spin_unlock_irqrestore(tll-lock, flags);
-   iounmap(base);
pm_runtime_put_sync(dev);
tll_pdev = pdev;
-   if (!ret)
-   goto end;
-   pm_runtime_disable(dev);
 
-err_usbtll_p2_fck:
+   return 0;
+
+err_res:
clk_put(tll-usbtll_p2_fck);
 
-err_usbtll_p1_fck:
+err_p2_fck:
clk_put(tll-usbtll_p1_fck);
 
-err_tll:
-   kfree(tll);
-
-end:
return ret;
 }
 
@@ -356,7 +342,6 @@ static int __devexit usbtll_omap_remove(struct 
platform_device *pdev)
clk_put(tll-usbtll_p2_fck);
clk_put(tll-usbtll_p1_fck);
pm_runtime_disable(pdev-dev);
-   kfree(tll);
return 0;
 }
 
-- 
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

[PATCH v2 05/22] mfd: omap-usb-tll: introduce and use mode_needs_tll()

This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index ab5c2e7..99a3087 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -95,6 +95,10 @@
 
 #define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
 
+/* only PHY and UNUSED modes don't need TLL */
+#define omap_usb_mode_needs_tll(x) ((x != OMAP_USBHS_PORT_MODE_UNUSED) \
+(x != OMAP_EHCI_PORT_MODE_PHY))
+
 struct usbtll_omap {
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
@@ -211,6 +215,7 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
unsigned long   flags;
int ret = 0;
int i, ver;
+   bool needs_tll;
 
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
 
@@ -278,12 +283,11 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
tll-ch_clk[i] = fck;
}
 
-   if (is_ehci_tll_mode(pdata-port_mode[0]) ||
-   is_ehci_tll_mode(pdata-port_mode[1]) ||
-   is_ehci_tll_mode(pdata-port_mode[2]) ||
-   is_ohci_port(pdata-port_mode[0]) ||
-   is_ohci_port(pdata-port_mode[1]) ||
-   is_ohci_port(pdata-port_mode[2])) {
+   needs_tll = false;
+   for (i = 0; i  tll-nch; i++)
+   needs_tll |= omap_usb_mode_needs_tll(pdata-port_mode[i]);
+
+   if (needs_tll) {
 
/* Program Common TLL register */
reg = usbtll_read(base, OMAP_TLL_SHARED_CONF);
@@ -371,7 +375,7 @@ static int usbtll_runtime_resume(struct device *dev)
spin_lock_irqsave(tll-lock, flags);
 
for (i = 0; i  tll-nch; i++) {
-   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
int r;
 
if (!tll-ch_clk[i])
@@ -407,7 +411,7 @@ static int usbtll_runtime_suspend(struct device *dev)
spin_lock_irqsave(tll-lock, flags);
 
for (i = 0; i  tll-nch; i++) {
-   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
if (tll-ch_clk[i])
clk_disable(tll-ch_clk[i]);
}
-- 
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

[PATCH v2 06/22] mfd: omap-usb-tll: Check for missing platform data in probe

No need to check for missing platform data in runtime_suspend/resume
as it makes more sense to do it in the probe function.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   15 +--
 1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 99a3087..a6a44de 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -225,6 +225,11 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
return -ENOMEM;
}
 
+   if (!pdata) {
+   dev_err(dev, Platform data missing\n);
+   return -ENODEV;
+   }
+
spin_lock_init(tll-lock);
 
tll-pdata = pdata;
@@ -367,11 +372,6 @@ static int usbtll_runtime_resume(struct device *dev)
 
dev_dbg(dev, usbtll_runtime_resume\n);
 
-   if (!pdata) {
-   dev_dbg(dev, missing platform_data\n);
-   return  -ENODEV;
-   }
-
spin_lock_irqsave(tll-lock, flags);
 
for (i = 0; i  tll-nch; i++) {
@@ -403,11 +403,6 @@ static int usbtll_runtime_suspend(struct device *dev)
 
dev_dbg(dev, usbtll_runtime_suspend\n);
 
-   if (!pdata) {
-   dev_dbg(dev, missing platform_data\n);
-   return  -ENODEV;
-   }
-
spin_lock_irqsave(tll-lock, flags);
 
for (i = 0; i  tll-nch; i++) {
-- 
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

[PATCH v2 07/22] mfd: omap-usb-tll: Fix error message

omap_enable/disable_tll() can fail if TLL device is not
initialized. It could be due to multiple reasons and not only
due to missing platform data.

Also make local variables static and use 'struct device *'
instead of 'struct platform_device *' for global reference.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index a6a44de..f9c51cd 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -109,8 +109,8 @@ struct usbtll_omap {
 
 /*-*/
 
-const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
-struct platform_device *tll_pdev;
+static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
+static struct device   *tll_dev;
 
 /*-*/
 
@@ -334,7 +334,8 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
 
spin_unlock_irqrestore(tll-lock, flags);
pm_runtime_put_sync(dev);
-   tll_pdev = pdev;
+   /* only after this can omap_tll_enable/disable work */
+   tll_dev = dev;
 
return 0;
 
@@ -356,6 +357,8 @@ static int __devexit usbtll_omap_remove(struct 
platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
 
+   tll_dev = NULL;
+
for (i = 0; i  tll-nch; i++)
clk_put(tll-ch_clk[i]);
 
@@ -435,21 +438,21 @@ static struct platform_driver usbtll_omap_driver = {
 
 int omap_tll_enable(void)
 {
-   if (!tll_pdev) {
-   pr_err(missing omap usbhs tll platform_data\n);
+   if (!tll_dev) {
+   pr_err(%s: OMAP USB TLL not initialized\n, __func__);
return  -ENODEV;
}
-   return pm_runtime_get_sync(tll_pdev-dev);
+   return pm_runtime_get_sync(tll_dev);
 }
 EXPORT_SYMBOL_GPL(omap_tll_enable);
 
 int omap_tll_disable(void)
 {
-   if (!tll_pdev) {
-   pr_err(missing omap usbhs tll platform_data\n);
+   if (!tll_dev) {
+   pr_err(%s: OMAP USB TLL not initialized\n, __func__);
return  -ENODEV;
}
-   return pm_runtime_put_sync(tll_pdev-dev);
+   return pm_runtime_put_sync(tll_dev);
 }
 EXPORT_SYMBOL_GPL(omap_tll_disable);
 
-- 
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

[PATCH v2 04/22] mfd: omap-usb-tll: Clean up clock handling

Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with up to 3 channels.

Dynamically allocate and get channel clocks depending on the
number of clocks avaiable on the platform.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   93 +++-
 1 files changed, 57 insertions(+), 36 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index ff5e16f..ab5c2e7 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -96,10 +96,9 @@
 #define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
 
 struct usbtll_omap {
-   struct clk  *usbtll_p1_fck;
-   struct clk  *usbtll_p2_fck;
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
+   struct clk  **ch_clk;
/* secure the register updates */
spinlock_t  lock;
 };
@@ -225,26 +224,10 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
 
tll-pdata = pdata;
 
-   tll-usbtll_p1_fck = clk_get(dev, usb_tll_hs_usb_ch0_clk);
-   if (IS_ERR(tll-usbtll_p1_fck)) {
-   ret = PTR_ERR(tll-usbtll_p1_fck);
-   dev_err(dev, usbtll_p1_fck failed error:%d\n, ret);
-   return ret;
-   }
-
-   tll-usbtll_p2_fck = clk_get(dev, usb_tll_hs_usb_ch1_clk);
-   if (IS_ERR(tll-usbtll_p2_fck)) {
-   ret = PTR_ERR(tll-usbtll_p2_fck);
-   dev_err(dev, usbtll_p2_fck failed error:%d\n, ret);
-   goto err_p2_fck;
-   }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_request_and_ioremap(dev, res);
-   if (!base) {
-   ret = -EADDRNOTAVAIL;
-   goto err_res;
-   }
+   if (!base)
+   return -EADDRNOTAVAIL;
 
platform_set_drvdata(pdev, tll);
pm_runtime_enable(dev);
@@ -269,6 +252,32 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
break;
}
 
+   spin_unlock_irqrestore(tll-lock, flags);
+
+   tll-ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll-nch]),
+   GFP_KERNEL);
+   if (!tll-ch_clk) {
+   ret = -ENOMEM;
+   dev_err(dev, Couldn't allocate memory for channel clocks\n);
+   goto err_clk_alloc;
+   }
+
+   spin_lock_irqsave(tll-lock, flags);
+
+   for (i = 0; i  tll-nch; i++) {
+   char clkname[] = usb_tll_hs_usb_chx_clk;
+   struct clk *fck;
+
+   snprintf(clkname, sizeof(clkname),
+   usb_tll_hs_usb_ch%d_clk, i);
+   fck = clk_get(dev, clkname);
+
+   if (IS_ERR(fck))
+   dev_dbg(dev, can't get clock : %s\n, clkname);
+   else
+   tll-ch_clk[i] = fck;
+   }
+
if (is_ehci_tll_mode(pdata-port_mode[0]) ||
is_ehci_tll_mode(pdata-port_mode[1]) ||
is_ehci_tll_mode(pdata-port_mode[2]) ||
@@ -320,11 +329,9 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
 
return 0;
 
-err_res:
-   clk_put(tll-usbtll_p2_fck);
-
-err_p2_fck:
-   clk_put(tll-usbtll_p1_fck);
+err_clk_alloc:
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
 
return ret;
 }
@@ -338,9 +345,11 @@ err_p2_fck:
 static int __devexit usbtll_omap_remove(struct platform_device *pdev)
 {
struct usbtll_omap *tll = platform_get_drvdata(pdev);
+   int i;
+
+   for (i = 0; i  tll-nch; i++)
+   clk_put(tll-ch_clk[i]);
 
-   clk_put(tll-usbtll_p2_fck);
-   clk_put(tll-usbtll_p1_fck);
pm_runtime_disable(pdev-dev);
return 0;
 }
@@ -350,6 +359,7 @@ static int usbtll_runtime_resume(struct device *dev)
struct usbtll_omap  *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll-pdata;
unsigned long   flags;
+   int i;
 
dev_dbg(dev, usbtll_runtime_resume\n);
 
@@ -360,11 +370,20 @@ static int usbtll_runtime_resume(struct device *dev)
 
spin_lock_irqsave(tll-lock, flags);
 
-   if (is_ehci_tll_mode(pdata-port_mode[0]))
-   clk_enable(tll-usbtll_p1_fck);
+   for (i = 0; i  tll-nch; i++) {
+   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   int r;
 
-   if (is_ehci_tll_mode(pdata-port_mode[1]))
-   clk_enable(tll-usbtll_p2_fck);
+   if (!tll-ch_clk[i])
+   continue;
+
+   r = clk_enable(tll-ch_clk[i]);
+   if (r) {
+

[PATCH v2 09/22] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support

The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index f901def..8b6050f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -54,10 +54,13 @@
 
 #defineOMAP_TLL_CHANNEL_CONF(num)  (0x040 + 0x004 
* num)
 #define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT   24
+#define OMAP_TLL_CHANNEL_CONF_DRVVBUS  (1  16)
+#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1  15)
 #defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1  11)
 #defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1  10)
 #defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE  (1  9)
 #defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE   (1  8)
+#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI(2  1)
 #define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1  1)
 #defineOMAP_TLL_CHANNEL_CONF_CHANEN(1  0)
 
@@ -92,6 +95,7 @@
 #define OMAP_USBTLL_REV1   0x0015  /* OMAP3 */
 #define OMAP_USBTLL_REV2   0x0018  /* OMAP 3630 */
 #define OMAP_USBTLL_REV3   0x0004  /* OMAP4 */
+#define OMAP_USBTLL_REV4   0x0006  /* OMAP5 */
 
 #define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
 
@@ -242,6 +246,7 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
+   case OMAP_USBTLL_REV4:
tll-nch = OMAP_TLL_CHANNEL_COUNT;
break;
case OMAP_USBTLL_REV2:
@@ -310,6 +315,15 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
reg = ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
| OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE);
+   } else if (pdata-port_mode[i] ==
+   OMAP_EHCI_PORT_MODE_HSIC) {
+   /*
+* HSIC Mode requires UTMI port configurations
+*/
+   reg |= OMAP_TLL_CHANNEL_CONF_DRVVBUS
+| OMAP_TLL_CHANNEL_CONF_CHRGVBUS
+| OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI
+| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF;
} else {
continue;
}
-- 
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

[PATCH v2 11/22] mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap()

Use devm_ variants of kzalloc and ioremap. Also clean up error path.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |   36 +---
 1 files changed, 9 insertions(+), 27 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index ffd2013..afa0ff6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -465,17 +465,20 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 
if (!pdata) {
dev_err(dev, Missing platform data\n);
-   ret = -ENOMEM;
-   goto end_probe;
+   return -ENODEV;
}
 
-   omap = kzalloc(sizeof(*omap), GFP_KERNEL);
+   omap = devm_kzalloc(dev, sizeof(*omap), GFP_KERNEL);
if (!omap) {
dev_err(dev, Memory allocation failed\n);
-   ret = -ENOMEM;
-   goto end_probe;
+   return -ENOMEM;
}
 
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, uhh);
+   omap-uhh_base = devm_request_and_ioremap(dev, res);
+   if (!omap-uhh_base)
+   return -EADDRNOTAVAIL;
+
spin_lock_init(omap-lock);
 
omap-pdata = pdata;
@@ -573,20 +576,6 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
failed error:%d\n, ret);
}
 
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, uhh);
-   if (!res) {
-   dev_err(dev, UHH EHCI get resource failed\n);
-   ret = -ENODEV;
-   goto err_init_60m_fclk;
-   }
-
-   omap-uhh_base = ioremap(res-start, resource_size(res));
-   if (!omap-uhh_base) {
-   dev_err(dev, UHH ioremap failed\n);
-   ret = -ENOMEM;
-   goto err_init_60m_fclk;
-   }
-
platform_set_drvdata(pdev, omap);
 
omap_usbhs_init(dev);
@@ -596,13 +585,10 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
goto err_alloc;
}
 
-   goto end_probe;
+   return 0;
 
 err_alloc:
omap_usbhs_deinit(pdev-dev);
-   iounmap(omap-uhh_base);
-
-err_init_60m_fclk:
clk_put(omap-init_60m_fclk);
 
 err_usbhost_p2_fck:
@@ -626,9 +612,7 @@ err_utmi_p1_fck:
 err_end:
clk_put(omap-ehci_logic_fck);
pm_runtime_disable(dev);
-   kfree(omap);
 
-end_probe:
return ret;
 }
 
@@ -643,7 +627,6 @@ static int __devexit usbhs_omap_remove(struct 
platform_device *pdev)
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
 
omap_usbhs_deinit(pdev-dev);
-   iounmap(omap-uhh_base);
clk_put(omap-init_60m_fclk);
clk_put(omap-usbhost_p2_fck);
clk_put(omap-usbhost_p1_fck);
@@ -653,7 +636,6 @@ static int __devexit usbhs_omap_remove(struct 
platform_device *pdev)
clk_put(omap-utmi_p1_fck);
clk_put(omap-ehci_logic_fck);
pm_runtime_disable(pdev-dev);
-   kfree(omap);
 
return 0;
 }
-- 
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

[PATCH v2 13/22] mfd: omap-usb-host: override number of ports from platform data

Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/usb-host.c|1 +
 arch/arm/plat-omap/include/plat/usb.h |2 +
 drivers/mfd/omap-usb-host.c   |   34 
 3 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..eb85528 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data 
*pdata)
ohci_data.es2_compatibility = pdata-es2_compatibility;
usbhs_data.ehci_data = ehci_data;
usbhs_data.ohci_data = ohci_data;
+   usbhs_data.nports = pdata-nports;
 
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
diff --git a/arch/arm/plat-omap/include/plat/usb.h 
b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..6b618a1 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -27,6 +27,7 @@ enum usbhs_omap_port_mode {
 };
 
 struct usbhs_omap_board_data {
+   int nports;
enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 
/* have to be valid if phy_reset is true and portx is in phy mode */
@@ -59,6 +60,7 @@ struct ohci_hcd_omap_platform_data {
 };
 
 struct usbhs_omap_platform_data {
+   int nports;
enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 
struct ehci_hcd_omap_platform_data  *ehci_data;
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 87b574b..fda235a 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -495,19 +495,27 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 */
pm_runtime_put_sync(dev);
 
-   switch (omap-usbhs_rev) {
-   case OMAP_USBHS_REV1:
-   omap-nports = 3;
-   break;
-   case OMAP_USBHS_REV2:
-   omap-nports = 2;
-   break;
-   default:
-   omap-nports = OMAP3_HS_USB_PORTS;
-   dev_dbg(dev,
- USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
-  omap-usbhs_rev, omap-nports);
-   break;
+   /*
+* If platform data contains nports then use that
+* else make out number of ports from USBHS revision
+*/
+   if (pdata-nports) {
+   omap-nports = pdata-nports;
+   } else {
+   switch (omap-usbhs_rev) {
+   case OMAP_USBHS_REV1:
+   omap-nports = 3;
+   break;
+   case OMAP_USBHS_REV2:
+   omap-nports = 2;
+   break;
+   default:
+   omap-nports = OMAP3_HS_USB_PORTS;
+   dev_dbg(dev,
+   USB HOST Rev:0x%d not recognized, assuming %d ports\n,
+   omap-usbhs_rev, omap-nports);
+   break;
+   }
}
 
for (i = 0; i  omap-nports; i++)
-- 
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

[PATCH v2 14/22] mfd: omap-usb-host: cleanup clock management code

All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.

Dynamically allocate and get clocks based on number of ports
available on the platform

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |  159 ++-
 1 files changed, 80 insertions(+), 79 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index fda235a..b596e10 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -90,13 +90,10 @@
 
 struct usbhs_hcd_omap {
int nports;
+   struct clk  **utmi_clk;
 
struct clk  *xclk60mhsp1_ck;
struct clk  *xclk60mhsp2_ck;
-   struct clk  *utmi_p1_fck;
-   struct clk  *usbhost_p1_fck;
-   struct clk  *utmi_p2_fck;
-   struct clk  *usbhost_p2_fck;
struct clk  *init_60m_fclk;
struct clk  *ehci_logic_fck;
 
@@ -280,6 +277,7 @@ static int usbhs_runtime_resume(struct device *dev)
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
unsigned long   flags;
struct usbhs_omap_platform_data *pdata = omap-pdata;
+   int i, r;
 
dev_dbg(dev, usbhs_runtime_resume\n);
 
@@ -289,13 +287,18 @@ static int usbhs_runtime_resume(struct device *dev)
if (omap-ehci_logic_fck  !IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
 
-   if (is_ehci_tll_mode(pdata-port_mode[0]))
-   clk_enable(omap-usbhost_p1_fck);
-   if (is_ehci_tll_mode(pdata-port_mode[1]))
-   clk_enable(omap-usbhost_p2_fck);
-
-   clk_enable(omap-utmi_p1_fck);
-   clk_enable(omap-utmi_p2_fck);
+   for (i = 0; i  omap-nports; i++) {
+   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   if (omap-utmi_clk[i]) {
+   r = clk_enable(omap-utmi_clk[i]);
+   if (r) {
+   dev_err(dev,
+Can't enable port %d clk : %d\n,
+i, r);
+   }
+   }
+   }
+   }
 
spin_unlock_irqrestore(omap-lock, flags);
 
@@ -307,18 +310,18 @@ static int usbhs_runtime_suspend(struct device *dev)
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
unsigned long   flags;
struct usbhs_omap_platform_data *pdata = omap-pdata;
+   int i;
 
dev_dbg(dev, usbhs_runtime_suspend\n);
 
spin_lock_irqsave(omap-lock, flags);
 
-   if (is_ehci_tll_mode(pdata-port_mode[0]))
-   clk_disable(omap-usbhost_p1_fck);
-   if (is_ehci_tll_mode(pdata-port_mode[1]))
-   clk_disable(omap-usbhost_p2_fck);
-
-   clk_disable(omap-utmi_p2_fck);
-   clk_disable(omap-utmi_p1_fck);
+   for (i = 0; i  omap-nports; i++) {
+   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   if (omap-utmi_clk[i])
+   clk_disable(omap-utmi_clk[i]);
+   }
+   }
 
if (omap-ehci_logic_fck  !IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
@@ -462,6 +465,7 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
struct resource *res;
int ret = 0;
int i;
+   boolneed_logic_fck;
 
if (!pdata) {
dev_err(dev, Missing platform data\n);
@@ -518,76 +522,79 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
}
}
 
-   for (i = 0; i  omap-nports; i++)
+   i = sizeof(struct clk *) * omap-nports;
+   omap-utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+   if (!omap-utmi_clk) {
+   dev_err(dev, Memory allocation failed\n);
+   ret = -ENOMEM;
+   goto err_mem;
+   }
+
+   need_logic_fck = false;
+   for (i = 0; i  omap-nports; i++) {
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
-   is_ehci_hsic_mode(i)) {
-   omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
-   if (IS_ERR(omap-ehci_logic_fck)) {
-   ret = PTR_ERR(omap-ehci_logic_fck);
-   dev_warn(dev, ehci_logic_fck failed:%d\n,
-ret);
-   }
-   break;
-   }
+   is_ehci_hsic_mode(i))
+

[PATCH v2 16/22] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode

Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |   77 +++---
 1 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index b596e10..3b402b7 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -91,6 +91,8 @@
 struct usbhs_hcd_omap {
int nports;
struct clk  **utmi_clk;
+   struct clk  **hsic60m_clk;
+   struct clk  **hsic480m_clk;
 
struct clk  *xclk60mhsp1_ck;
struct clk  *xclk60mhsp2_ck;
@@ -288,7 +290,28 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-ehci_logic_fck);
 
for (i = 0; i  omap-nports; i++) {
-   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   switch (pdata-port_mode[i]) {
+   case OMAP_EHCI_PORT_MODE_HSIC:
+   if (omap-hsic60m_clk[i]) {
+   r = clk_enable(omap-hsic60m_clk[i]);
+   if (r) {
+   dev_err(dev,
+Can't enable port %d hsic60m 
clk:%d\n,
+i, r);
+   }
+   }
+
+   if (omap-hsic480m_clk[i]) {
+   r = clk_enable(omap-hsic480m_clk[i]);
+   if (r) {
+   dev_err(dev,
+Can't enable port %d hsic480m 
clk:%d\n,
+i, r);
+   }
+   }
+   /* Fall through as HSIC mode needs utmi_clk */
+
+   case OMAP_EHCI_PORT_MODE_TLL:
if (omap-utmi_clk[i]) {
r = clk_enable(omap-utmi_clk[i]);
if (r) {
@@ -297,6 +320,9 @@ static int usbhs_runtime_resume(struct device *dev)
 i, r);
}
}
+   break;
+   default:
+   break;
}
}
 
@@ -317,9 +343,21 @@ static int usbhs_runtime_suspend(struct device *dev)
spin_lock_irqsave(omap-lock, flags);
 
for (i = 0; i  omap-nports; i++) {
-   if (is_ehci_tll_mode(pdata-port_mode[i])) {
+   switch (pdata-port_mode[i]) {
+   case OMAP_EHCI_PORT_MODE_HSIC:
+   if (omap-hsic60m_clk[i])
+   clk_disable(omap-hsic60m_clk[i]);
+
+   if (omap-hsic480m_clk[i])
+   clk_disable(omap-hsic480m_clk[i]);
+   /* Fall through as utmi_clks were used in HSIC mode */
+
+   case OMAP_EHCI_PORT_MODE_TLL:
if (omap-utmi_clk[i])
clk_disable(omap-utmi_clk[i]);
+   break;
+   default:
+   break;
}
}
 
@@ -524,7 +562,10 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 
i = sizeof(struct clk *) * omap-nports;
omap-utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
-   if (!omap-utmi_clk) {
+   omap-hsic480m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+   omap-hsic60m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+
+   if (!omap-utmi_clk || !omap-hsic480m_clk || !omap-hsic60m_clk) {
dev_err(dev, Memory allocation failed\n);
ret = -ENOMEM;
goto err_mem;
@@ -568,7 +609,7 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 
for (i = 0; i  omap-nports; i++) {
struct clk *pclk;
-   char clkname[] = usb_host_hs_utmi_px_clk;
+   char clkname[] = usb_host_hs_hsic480m_px_clk;
 
/* clock names are indexed from 1*/
snprintf(clkname, sizeof(clkname),
@@ -584,6 +625,24 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
clkname, PTR_ERR(pclk));
else
omap-utmi_clk[i] = pclk;
+
+   snprintf(clkname, sizeof(clkname),
+   usb_host_hs_hsic480m_p%d_clk, i + 1);
+   pclk = clk_get(dev, clkname);
+   if (IS_ERR(pclk))
+   dev_dbg(dev, Failed to get clock : %s : %ld\n,
+   clkname, PTR_ERR(pclk));
+   else
+   omap-hsic480m_clk[i] = pclk;
+
+

[PATCH v2 15/22] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk

There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.

CC: Benoit Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/clock3xxx_data.c |2 --
 arch/arm/mach-omap2/clock44xx_data.c |   30 --
 2 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 1f42c9d..0d2ee04 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3400,8 +3400,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   usbhost_ick,  usbhost_ick,   CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(usbhs_omap,   usbhost_ick,  usbhost_ick,   CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
-   CLK(NULL,   utmi_p1_gfclk,dummy_ck,  CK_3XXX),
-   CLK(NULL,   utmi_p2_gfclk,dummy_ck,  CK_3XXX),
CLK(NULL,   xclk60mhsp1_ck,   dummy_ck,  CK_3XXX),
CLK(NULL,   xclk60mhsp2_ck,   dummy_ck,  CK_3XXX),
CLK(NULL,   usb_host_hs_utmi_p1_clk,  dummy_ck,  
CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 6efc30c..fc3e490 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2462,25 +2462,19 @@ static const struct clksel utmi_p1_gfclk_sel[] = {
{ .parent = NULL },
 };
 
-static struct clk utmi_p1_gfclk = {
-   .name   = utmi_p1_gfclk,
+/* Merged utmi_p1_gfclk into usb_host_hs_utmi_p1_clk */
+static struct clk usb_host_hs_utmi_p1_clk = {
+   .name   = usb_host_hs_utmi_p1_clk,
.parent = init_60m_fclk,
.clksel = utmi_p1_gfclk_sel,
.init   = omap2_init_clksel_parent,
.clksel_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
.clksel_mask= OMAP4430_CLKSEL_UTMI_P1_MASK,
-   .ops= clkops_null,
-   .recalc = omap2_clksel_recalc,
-};
-
-static struct clk usb_host_hs_utmi_p1_clk = {
-   .name   = usb_host_hs_utmi_p1_clk,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
.enable_bit = OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT,
.clkdm_name = l3_init_clkdm,
-   .parent = utmi_p1_gfclk,
-   .recalc = followparent_recalc,
+   .recalc = omap2_clksel_recalc,
 };
 
 static const struct clksel utmi_p2_gfclk_sel[] = {
@@ -2489,25 +2483,19 @@ static const struct clksel utmi_p2_gfclk_sel[] = {
{ .parent = NULL },
 };
 
-static struct clk utmi_p2_gfclk = {
-   .name   = utmi_p2_gfclk,
+/* Merged utmi_p2_gfclk into usb_host_hs_utmi_p2_clk */
+static struct clk usb_host_hs_utmi_p2_clk = {
+   .name   = usb_host_hs_utmi_p2_clk,
.parent = init_60m_fclk,
.clksel = utmi_p2_gfclk_sel,
.init   = omap2_init_clksel_parent,
.clksel_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
.clksel_mask= OMAP4430_CLKSEL_UTMI_P2_MASK,
-   .ops= clkops_null,
-   .recalc = omap2_clksel_recalc,
-};
-
-static struct clk usb_host_hs_utmi_p2_clk = {
-   .name   = usb_host_hs_utmi_p2_clk,
.ops= clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
.enable_bit = OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT,
.clkdm_name = l3_init_clkdm,
-   .parent = utmi_p2_gfclk,
-   .recalc = followparent_recalc,
+   .recalc = omap2_clksel_recalc,
 };
 
 static struct clk usb_host_hs_utmi_p3_clk = {
@@ -3246,9 +3234,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   uart4_fck,uart4_fck, 
CK_443X),
CLK(usbhs_omap,   fs_fck,   usb_host_fs_fck,   
CK_443X),
CLK(NULL,   usb_host_fs_fck,  usb_host_fs_fck,   
CK_443X),
-   CLK(NULL,   utmi_p1_gfclk,utmi_p1_gfclk, 
CK_443X),
CLK(NULL,   usb_host_hs_utmi_p1_clk,  
usb_host_hs_utmi_p1_clk,   CK_443X),
-   CLK(NULL,   utmi_p2_gfclk,utmi_p2_gfclk, 
CK_443X),
CLK(NULL,   usb_host_hs_utmi_p2_clk,  
usb_host_hs_utmi_p2_clk,   CK_443X),
CLK(NULL,   usb_host_hs_utmi_p3_clk,  
usb_host_hs_utmi_p3_clk,   CK_443X),
CLK(NULL,   usb_host_hs_hsic480m_p1_clk,  
usb_host_hs_hsic480m_p1_clk,   CK_443X),
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of

[PATCH v2 18/22] mfd: omap-usb-host: get rid of cpu_is_omap..() macros

Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.

The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.

Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/usb-host.c|4 
 arch/arm/plat-omap/include/plat/usb.h |3 +++
 drivers/mfd/omap-usb-host.c   |3 +--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index eb85528..455b135 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -509,6 +509,10 @@ void __init usbhs_init(const struct usbhs_omap_board_data 
*pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
setup_ohci_io_mux(pdata-port_mode);
+
+   if (omap_rev() = OMAP3430_REV_ES2_1)
+   usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata-port_mode);
setup_4430ohci_io_mux(pdata-port_mode);
diff --git a/arch/arm/plat-omap/include/plat/usb.h 
b/arch/arm/plat-omap/include/plat/usb.h
index 6b618a1..3f2336a 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -65,6 +65,9 @@ struct usbhs_omap_platform_data {
 
struct ehci_hcd_omap_platform_data  *ehci_data;
struct ohci_hcd_omap_platform_data  *ohci_data;
+
+   /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
+   unsignedsingle_ulpi_bypass:1;
 };
 
 struct usbtll_omap_platform_data {
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 62e1f21..aaf272d 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -24,7 +24,6 @@
 #include linux/clk.h
 #include linux/dma-mapping.h
 #include linux/gpio.h
-#include plat/cpu.h
 #include plat/usb.h
 #include linux/pm_runtime.h
 
@@ -400,7 +399,7 @@ static void omap_usbhs_init(struct device *dev)
reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
 
/* Bypass the TLL module for PHY mode operation */
-   if (cpu_is_omap3430()  (omap_rev() = OMAP3430_REV_ES2_1)) {
+   if (pdata-single_ulpi_bypass) {
dev_dbg(dev, OMAP3 ES version = ES2.1\n);
if (is_ehci_phy_mode(pdata-port_mode[0]) ||
is_ehci_phy_mode(pdata-port_mode[1]) ||
-- 
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

[PATCH v2 17/22] mfd: omap-usb-host: Get rid of unnecessary spinlock

The driver does not have an interrupt handler and
we don't really need a spinlock, so get rid of it.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 3b402b7..62e1f21 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -23,7 +23,6 @@
 #include linux/delay.h
 #include linux/clk.h
 #include linux/dma-mapping.h
-#include linux/spinlock.h
 #include linux/gpio.h
 #include plat/cpu.h
 #include plat/usb.h
@@ -104,7 +103,6 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
 
u32 usbhs_rev;
-   spinlock_t  lock;
 };
 /*-*/
 
@@ -277,14 +275,12 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
 static int usbhs_runtime_resume(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   unsigned long   flags;
struct usbhs_omap_platform_data *pdata = omap-pdata;
int i, r;
 
dev_dbg(dev, usbhs_runtime_resume\n);
 
omap_tll_enable();
-   spin_lock_irqsave(omap-lock, flags);
 
if (omap-ehci_logic_fck  !IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
@@ -326,22 +322,17 @@ static int usbhs_runtime_resume(struct device *dev)
}
}
 
-   spin_unlock_irqrestore(omap-lock, flags);
-
return 0;
 }
 
 static int usbhs_runtime_suspend(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   unsigned long   flags;
struct usbhs_omap_platform_data *pdata = omap-pdata;
int i;
 
dev_dbg(dev, usbhs_runtime_suspend\n);
 
-   spin_lock_irqsave(omap-lock, flags);
-
for (i = 0; i  omap-nports; i++) {
switch (pdata-port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
@@ -364,7 +355,6 @@ static int usbhs_runtime_suspend(struct device *dev)
if (omap-ehci_logic_fck  !IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
 
-   spin_unlock_irqrestore(omap-lock, flags);
omap_tll_disable();
 
return 0;
@@ -374,7 +364,6 @@ static void omap_usbhs_init(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap-pdata;
-   unsigned long   flags;
unsignedreg;
 
dev_dbg(dev, starting TI HSUSB Controller\n);
@@ -393,7 +382,6 @@ static void omap_usbhs_init(struct device *dev)
}
 
pm_runtime_get_sync(dev);
-   spin_lock_irqsave(omap-lock, flags);
 
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -456,8 +444,6 @@ static void omap_usbhs_init(struct device *dev)
usbhs_write(omap-uhh_base, OMAP_UHH_HOSTCONFIG, reg);
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
 
-   spin_unlock_irqrestore(omap-lock, flags);
-
pm_runtime_put_sync(dev);
if (pdata-ehci_data-phy_reset) {
/* Hold the PHY in RESET for enough time till
@@ -521,8 +507,6 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
if (!omap-uhh_base)
return -EADDRNOTAVAIL;
 
-   spin_lock_init(omap-lock);
-
omap-pdata = pdata;
 
pm_runtime_enable(dev);
-- 
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

[PATCH v2 19/22] mfd: omap-usb-host: clean up omap_usbhs_init()

We split initializing revision 1 and revision 2 into different
functions. Initialization is now done dynamically so that only
the number of ports available on the system are initialized.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |  122 +-
 1 files changed, 73 insertions(+), 49 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index aaf272d..6ede319 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -359,6 +359,75 @@ static int usbhs_runtime_suspend(struct device *dev)
return 0;
 }
 
+static unsigned omap_usbhs_rev1_hostconfig(struct usbhs_hcd_omap *omap,
+   unsigned reg)
+{
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
+   int i;
+
+   for (i = 0; i  omap-nports; i++) {
+   switch (pdata-port_mode[i]) {
+   case OMAP_USBHS_PORT_MODE_UNUSED:
+   reg = ~(OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS  i);
+   break;
+   case OMAP_EHCI_PORT_MODE_PHY:
+   if (pdata-single_ulpi_bypass)
+   break;
+
+   if (i == 0)
+   reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+   else
+   reg = ~(OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+(i-1));
+   break;
+   default:
+   if (pdata-single_ulpi_bypass)
+   break;
+
+   if (i == 0)
+   reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+   else
+   reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+(i-1);
+   break;
+   }
+   }
+
+   if (pdata-single_ulpi_bypass) {
+   /* bypass ULPI only if none of the ports use PHY mode */
+   reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+
+   for (i = 0; i  omap-nports; i++) {
+   if (is_ehci_phy_mode(pdata-port_mode[i])) {
+   reg = OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+   break;
+   }
+   }
+   }
+
+   return reg;
+}
+
+static unsigned omap_usbhs_rev2_hostconfig(struct usbhs_hcd_omap *omap,
+   unsigned reg)
+{
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
+   int i;
+
+   for (i = 0; i  omap-nports; i++) {
+   /* Clear port mode fields for PHY mode */
+   reg = ~(OMAP4_P1_MODE_CLEAR  2 * i);
+
+   if (is_ehci_tll_mode(pdata-port_mode[i]) ||
+   (is_ohci_port(pdata-port_mode[i])))
+   reg |= OMAP4_P1_MODE_TLL  2 * i;
+   else if (is_ehci_hsic_mode(pdata-port_mode[i]))
+   reg |= OMAP4_P1_MODE_HSIC  2 * i;
+   }
+
+   return reg;
+}
+
 static void omap_usbhs_init(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
@@ -390,55 +459,10 @@ static void omap_usbhs_init(struct device *dev)
reg |= OMAP4_UHH_HOSTCONFIG_APP_START_CLK;
reg = ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN;
 
-   if (is_omap_usbhs_rev1(omap)) {
-   if (pdata-port_mode[0] == OMAP_USBHS_PORT_MODE_UNUSED)
-   reg = ~OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS;
-   if (pdata-port_mode[1] == OMAP_USBHS_PORT_MODE_UNUSED)
-   reg = ~OMAP_UHH_HOSTCONFIG_P2_CONNECT_STATUS;
-   if (pdata-port_mode[2] == OMAP_USBHS_PORT_MODE_UNUSED)
-   reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
-
-   /* Bypass the TLL module for PHY mode operation */
-   if (pdata-single_ulpi_bypass) {
-   dev_dbg(dev, OMAP3 ES version = ES2.1\n);
-   if (is_ehci_phy_mode(pdata-port_mode[0]) ||
-   is_ehci_phy_mode(pdata-port_mode[1]) ||
-   is_ehci_phy_mode(pdata-port_mode[2]))
-   reg = ~OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
-   else
-   reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
-   } else {
-   dev_dbg(dev, OMAP3 ES version  ES2.1\n);
-   if (is_ehci_phy_mode(pdata-port_mode[0]))
-   reg = ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
-   else
-   reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
-   if (is_ehci_phy_mode(pdata-port_mode[1]))
-   reg =

[PATCH v2 21/22] ARM: OMAP2+: clock data: get rid of unused USB host clock aliases

We don't need multiple aliases for the OMAP USB host clocks so remove them.
Also use NULL dev_id for 'usb_tll_hs_usb_ch0_clk' and 'usb_tll_hs_usb_ch1_clk'

Signed-off-by: Roger Quadros rog...@ti.com
CC: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/clock3xxx_data.c |   11 ---
 1 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 0d2ee04..fc8afc8 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3297,8 +3297,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   cpefuse_fck,  cpefuse_fck,   CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   ts_fck,   ts_fck,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   usbtll_fck,   usbtll_fck,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
-   CLK(usbhs_omap,   usbtll_fck,   usbtll_fck,CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
-   CLK(usbhs_tll,usbtll_fck,   usbtll_fck,CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
CLK(NULL,   core_96m_fck, core_96m_fck,  CK_3XXX),
CLK(NULL,   mmchs3_fck,   mmchs3_fck,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   mmchs2_fck,   mmchs2_fck,CK_3XXX),
@@ -3335,8 +,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   pka_ick,  pka_ick,   CK_34XX | CK_36XX),
CLK(NULL,   core_l4_ick,  core_l4_ick,   CK_3XXX),
CLK(NULL,   usbtll_ick,   usbtll_ick,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
-   CLK(usbhs_omap,   usbtll_ick,   usbtll_ick,CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
-   CLK(usbhs_tll,usbtll_ick,   usbtll_ick,CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick,  mmchs3_ick,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   mmchs3_ick,   mmchs3_ick,CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   icr_ick,  icr_ick,   CK_34XX | CK_36XX),
@@ -3399,15 +3395,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   usbhost_120m_fck, usbhost_120m_fck, CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   usbhost_48m_fck, usbhost_48m_fck, CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   usbhost_ick,  usbhost_ick,   CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
-   CLK(usbhs_omap,   usbhost_ick,  usbhost_ick,   CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
CLK(NULL,   xclk60mhsp1_ck,   dummy_ck,  CK_3XXX),
CLK(NULL,   xclk60mhsp2_ck,   dummy_ck,  CK_3XXX),
-   CLK(NULL,   usb_host_hs_utmi_p1_clk,  dummy_ck,  
CK_3XXX),
-   CLK(NULL,   usb_host_hs_utmi_p2_clk,  dummy_ck,  
CK_3XXX),
-   CLK(usbhs_omap,   usb_tll_hs_usb_ch0_clk,   dummy_ck,  
CK_3XXX),
-   CLK(usbhs_omap,   usb_tll_hs_usb_ch1_clk,   dummy_ck,  
CK_3XXX),
-   CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk,   dummy_ck,  
CK_3XXX),
-   CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk,   dummy_ck,  
CK_3XXX),
CLK(NULL,   init_60m_fclk,dummy_ck,  CK_3XXX),
CLK(NULL,   usim_fck, usim_fck,  CK_3430ES2PLUS | 
CK_36XX),
CLK(NULL,   gpt1_fck, gpt1_fck,  CK_3XXX),
-- 
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

[PATCH v2 22/22] mfd: omap-usb-host: Don't spam console on clk_set_parent failure

clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6ede319..493e010 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -653,17 +653,17 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
}
 
if (is_ehci_phy_mode(pdata-port_mode[0])) {
-   /* for OMAP3 , the clk set paretn fails */
+   /* for OMAP3 , the clk set parent fails */
ret = clk_set_parent(omap-utmi_clk[0],
omap-xclk60mhsp1_ck);
if (ret != 0)
-   dev_err(dev, xclk60mhsp1_ck set parent
+   dev_dbg(dev, xclk60mhsp1_ck set parent
failed error:%d\n, ret);
} else if (is_ehci_tll_mode(pdata-port_mode[0])) {
ret = clk_set_parent(omap-utmi_clk[0],
omap-init_60m_fclk);
if (ret != 0)
-   dev_err(dev, init_60m_fclk set parent
+   dev_dbg(dev, init_60m_fclk set parent
failed error:%d\n, ret);
}
 
@@ -671,13 +671,13 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-   dev_err(dev, xclk60mhsp2_ck set parent
+   dev_dbg(dev, xclk60mhsp2_ck set parent
failed error:%d\n, ret);
} else if (is_ehci_tll_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-init_60m_fclk);
if (ret != 0)
-   dev_err(dev, init_60m_fclk set parent
+   dev_dbg(dev, init_60m_fclk set parent
failed error:%d\n, ret);
}
 
-- 
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

[PATCH v2 20/22] USB: ehci-omap: Don't free gpios that we didn't request

This driver does not request any gpios so don't free them.
Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
with ehci-omap in use.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/host/ehci-omap.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index d7fe287..7ab0002 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -290,7 +290,6 @@ static int ehci_hcd_omap_remove(struct platform_device 
*pdev)
 {
struct device *dev  = pdev-dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
-   struct ehci_hcd_omap_platform_data *pdata   = dev-platform_data;
 
usb_remove_hcd(hcd);
disable_put_regulator(dev-platform_data);
@@ -300,13 +299,6 @@ static int ehci_hcd_omap_remove(struct platform_device 
*pdev)
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
 
-   if (pdata-phy_reset) {
-   if (gpio_is_valid(pdata-reset_gpio_port[0]))
-   gpio_free(pdata-reset_gpio_port[0]);
-
-   if (gpio_is_valid(pdata-reset_gpio_port[1]))
-   gpio_free(pdata-reset_gpio_port[1]);
-   }
return 0;
 }
 
-- 
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

[PATCH v2 12/22] mfd: omap-usb-host: know about number of ports from revision register

The revision register should tell us how many ports are present.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |   32 +++-
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index afa0ff6..87b574b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -89,6 +89,8 @@
 
 
 struct usbhs_hcd_omap {
+   int nports;
+
struct clk  *xclk60mhsp1_ck;
struct clk  *xclk60mhsp2_ck;
struct clk  *utmi_p1_fck;
@@ -351,8 +353,6 @@ static void omap_usbhs_init(struct device *dev)
 
pm_runtime_get_sync(dev);
spin_lock_irqsave(omap-lock, flags);
-   omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
-   dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
 
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -485,8 +485,32 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 
pm_runtime_enable(dev);
 
+   platform_set_drvdata(pdev, omap);
+   pm_runtime_get_sync(dev);
 
-   for (i = 0; i  OMAP3_HS_USB_PORTS; i++)
+   omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
+
+   /* we need to call runtime suspend before we update omap-nports
+* to prevent unbalanced clk_disable()
+*/
+   pm_runtime_put_sync(dev);
+
+   switch (omap-usbhs_rev) {
+   case OMAP_USBHS_REV1:
+   omap-nports = 3;
+   break;
+   case OMAP_USBHS_REV2:
+   omap-nports = 2;
+   break;
+   default:
+   omap-nports = OMAP3_HS_USB_PORTS;
+   dev_dbg(dev,
+ USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
+  omap-usbhs_rev, omap-nports);
+   break;
+   }
+
+   for (i = 0; i  omap-nports; i++)
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
is_ehci_hsic_mode(i)) {
omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
@@ -576,8 +600,6 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
failed error:%d\n, ret);
}
 
-   platform_set_drvdata(pdev, omap);
-
omap_usbhs_init(dev);
ret = omap_usbhs_alloc_children(pdev);
if (ret) {
-- 
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

[PATCH v2 10/22] mfd: omap_usb_host: Avoid creating copy of platform_data

We can just hold the pointer to the platform data instead
of creating a copy of it.

Also get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/omap-usb-host.c |   30 --
 1 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..ffd2013 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,7 +100,7 @@ struct usbhs_hcd_omap {
 
void __iomem*uhh_base;
 
-   struct usbhs_omap_platform_data platdata;
+   struct usbhs_omap_platform_data *pdata;
 
u32 usbhs_rev;
spinlock_t  lock;
@@ -192,8 +192,8 @@ static int omap_usbhs_alloc_children(struct platform_device 
*pdev)
int ret;
 
omap = platform_get_drvdata(pdev);
-   ehci_data = omap-platdata.ehci_data;
-   ohci_data = omap-platdata.ohci_data;
+   ehci_data = omap-pdata-ehci_data;
+   ohci_data = omap-pdata-ohci_data;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, ehci);
if (!res) {
@@ -276,16 +276,11 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
 static int usbhs_runtime_resume(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   struct usbhs_omap_platform_data *pdata = omap-platdata;
unsigned long   flags;
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
 
dev_dbg(dev, usbhs_runtime_resume\n);
 
-   if (!pdata) {
-   dev_dbg(dev, missing platform_data\n);
-   return  -ENODEV;
-   }
-
omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
 
@@ -308,16 +303,11 @@ static int usbhs_runtime_resume(struct device *dev)
 static int usbhs_runtime_suspend(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   struct usbhs_omap_platform_data *pdata = omap-platdata;
unsigned long   flags;
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
 
dev_dbg(dev, usbhs_runtime_suspend\n);
 
-   if (!pdata) {
-   dev_dbg(dev, missing platform_data\n);
-   return  -ENODEV;
-   }
-
spin_lock_irqsave(omap-lock, flags);
 
if (is_ehci_tll_mode(pdata-port_mode[0]))
@@ -340,7 +330,7 @@ static int usbhs_runtime_suspend(struct device *dev)
 static void omap_usbhs_init(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   struct usbhs_omap_platform_data *pdata = omap-platdata;
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
unsigned long   flags;
unsignedreg;
 
@@ -447,7 +437,7 @@ static void omap_usbhs_init(struct device *dev)
 static void omap_usbhs_deinit(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   struct usbhs_omap_platform_data *pdata = omap-platdata;
+   struct usbhs_omap_platform_data *pdata = omap-pdata;
 
if (pdata-ehci_data-phy_reset) {
if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
@@ -488,11 +478,7 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
 
spin_lock_init(omap-lock);
 
-   for (i = 0; i  OMAP3_HS_USB_PORTS; i++)
-   omap-platdata.port_mode[i] = pdata-port_mode[i];
-
-   omap-platdata.ehci_data = pdata-ehci_data;
-   omap-platdata.ohci_data = pdata-ohci_data;
+   omap-pdata = pdata;
 
pm_runtime_enable(dev);
 
-- 
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

[PATCH v2 08/22] mfd: omap-usb-tll: serialize access to TLL device

Get rid of the unnecessary spin_lock_irqsave/restore() as there is
no interrupt handler for this driver. Instead we serialize access
to tll_dev using a global spinlock.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-tll.c |   53 ++-
 1 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index f9c51cd..f901def 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -103,14 +103,13 @@ struct usbtll_omap {
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
struct clk  **ch_clk;
-   /* secure the register updates */
-   spinlock_t  lock;
 };
 
 /*-*/
 
 static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
 static struct device   *tll_dev;
+static DEFINE_SPINLOCK(tll_lock);  /* serialize access to tll_dev */
 
 /*-*/
 
@@ -212,7 +211,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
struct resource *res;
struct usbtll_omap  *tll;
unsignedreg;
-   unsigned long   flags;
int ret = 0;
int i, ver;
bool needs_tll;
@@ -230,8 +228,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
return -ENODEV;
}
 
-   spin_lock_init(tll-lock);
-
tll-pdata = pdata;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -243,8 +239,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
-   spin_lock_irqsave(tll-lock, flags);
-
ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
@@ -262,8 +256,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
break;
}
 
-   spin_unlock_irqrestore(tll-lock, flags);
-
tll-ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll-nch]),
GFP_KERNEL);
if (!tll-ch_clk) {
@@ -272,8 +264,6 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
goto err_clk_alloc;
}
 
-   spin_lock_irqsave(tll-lock, flags);
-
for (i = 0; i  tll-nch; i++) {
char clkname[] = usb_tll_hs_usb_chx_clk;
struct clk *fck;
@@ -332,10 +322,11 @@ static int __devinit usbtll_omap_probe(struct 
platform_device *pdev)
}
}
 
-   spin_unlock_irqrestore(tll-lock, flags);
pm_runtime_put_sync(dev);
/* only after this can omap_tll_enable/disable work */
+   spin_lock(tll_lock);
tll_dev = dev;
+   spin_unlock(tll_lock);
 
return 0;
 
@@ -357,7 +348,9 @@ static int __devexit usbtll_omap_remove(struct 
platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
 
+   spin_lock(tll_lock);
tll_dev = NULL;
+   spin_unlock(tll_lock);
 
for (i = 0; i  tll-nch; i++)
clk_put(tll-ch_clk[i]);
@@ -370,13 +363,10 @@ static int usbtll_runtime_resume(struct device *dev)
 {
struct usbtll_omap  *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll-pdata;
-   unsigned long   flags;
int i;
 
dev_dbg(dev, usbtll_runtime_resume\n);
 
-   spin_lock_irqsave(tll-lock, flags);
-
for (i = 0; i  tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
int r;
@@ -392,8 +382,6 @@ static int usbtll_runtime_resume(struct device *dev)
}
}
 
-   spin_unlock_irqrestore(tll-lock, flags);
-
return 0;
 }
 
@@ -401,13 +389,10 @@ static int usbtll_runtime_suspend(struct device *dev)
 {
struct usbtll_omap  *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll-pdata;
-   unsigned long   flags;
int i;
 
dev_dbg(dev, usbtll_runtime_suspend\n);
 
-   spin_lock_irqsave(tll-lock, flags);
-
for (i = 0; i  tll-nch; i++) {
if (omap_usb_mode_needs_tll(pdata-port_mode[i])) {
if (tll-ch_clk[i])
@@ -415,8 +400,6 @@ static int usbtll_runtime_suspend(struct device *dev)
}
}
 
-   spin_unlock_irqrestore(tll-lock, flags);
-
return 0;
 }
 
@@ -438,21

Re: [try#1 PATCH 5/7] omap4: panda: add smsc95xx regulator and reset dependent on root hub

On 11/28/2012 02:59 PM, Andy Green wrote:
 This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
 EHCI logical root hub existing.
 
 The regulators are made a device_asset of the EHCI logical root hub by
 passing them through the hsusb - mfd path.  Although the ehci-related
 platform_device is created at boot time, it is not instantiated until the
 ehci-hcd module is inserted if it is modular.
 
 Since the regulator is an asset of the ehci-omap.0 device, it's turned on
 during successful probe and off when the device is removed.
 
 Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
 all the time, which is around the same as the idle power of the SoC and
 rest of the board.
 
 This allows us to start off with it depowered, and only power it if the
 ehci-hcd module is inserted.  When the module is removed, it's depowered
 again.
 
 Signed-off-by: Andy Green andy.gr...@linaro.org
 ---
  arch/arm/mach-omap2/board-omap4panda.c |  100 
 ++--
  arch/arm/mach-omap2/usb-host.c |1 
  arch/arm/plat-omap/include/plat/usb.h  |2 +
  drivers/mfd/omap-usb-host.c|9 ++-
  4 files changed, 89 insertions(+), 23 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index bfcd397..52add03 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -144,6 +144,15 @@ static struct platform_device *panda_devices[] 
 __initdata = {
   btwilink_device,
  };
  
 +static struct device_asset assets_ehci_omap0[] = {
 + {
 + .name = reg-panda-smsc95xx,
 + .pre_probe = regulator_asset_default_preprobe,
 + .post_remove = regulator_asset_default_postremove,
 + },
 + { }
 +};
 +
  static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
   .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
   .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
 @@ -151,12 +160,8 @@ static const struct usbhs_omap_board_data usbhs_bdata 
 __initconst = {
   .phy_reset  = false,
   .reset_gpio_port[0]  = -EINVAL,
   .reset_gpio_port[1]  = -EINVAL,
 - .reset_gpio_port[2]  = -EINVAL
 -};
 -
 -static struct gpio panda_ehci_gpios[] __initdata = {
 - { GPIO_HUB_POWER,   GPIOF_OUT_INIT_LOW,  hub_power  },
 - { GPIO_HUB_NRESET,  GPIOF_OUT_INIT_LOW,  hub_nreset },
 + .reset_gpio_port[2]  = -EINVAL,
 + .assets = assets_ehci_omap0,
  };
  
  static void __init omap4_ehci_init(void)
 @@ -173,23 +178,76 @@ static void __init omap4_ehci_init(void)
   clk_set_rate(phy_ref_clk, 1920);
   clk_prepare_enable(phy_ref_clk);
  
 - /* disable the power to the usb hub prior to init and reset phy+hub */
 - ret = gpio_request_array(panda_ehci_gpios,
 -  ARRAY_SIZE(panda_ehci_gpios));
 - if (ret) {
 - pr_err(Unable to initialize EHCI power/reset\n);
 - return;
 - }
 + usbhs_init(usbhs_bdata);
 +}
  
 - gpio_export(GPIO_HUB_POWER, 0);
 - gpio_export(GPIO_HUB_NRESET, 0);
 - gpio_set_value(GPIO_HUB_NRESET, 1);
 +/*
 + * hub_nreset also resets the ULPI PHY and is required after powering SMSC 
 chip
 + *   ULPI PHY is always powered... need to do reset once for both once
 + * hub_power enables a 3.3V regulator for (hub + eth) chip
 + *   however there's no point having ULPI PHY in use alone
 + *   since it's only connected to the (hub + eth) chip
 + */
  
 - usbhs_init(usbhs_bdata);
 +static struct regulator_init_data panda_hub = {
 + .constraints = {
 + .name = vhub,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + },
 +};
  
 - /* enable power to hub */
 - gpio_set_value(GPIO_HUB_POWER, 1);
 -}
 +static struct fixed_voltage_config panda_vhub = {
 + .supply_name = vhub,
 + .microvolts = 330,
 + .gpio = GPIO_HUB_POWER,
 + .startup_delay = 7, /* 70msec */
 + .enable_high = 1,
 + .enabled_at_boot = 0,
 + .init_data = panda_hub,
 +};
 +
 +static struct platform_device omap_vhub_device = {
 + .name   = reg-fixed-voltage,
 + .id = 2,
 + .dev = {
 + .platform_data = panda_vhub,
 + },
 +};
 +
 +static struct regulator_init_data panda_ulpireset = {
 + /*
 +  * idea is that when operating ulpireset, regulator api will make
 +  * sure that the hub+eth chip is powered, since it's the parent
 +  */
 + .supply_regulator = vhub, /* we are a child of vhub */
 + .constraints = {
 + /*
 +  * this magic string associates us with ehci-omap.0 root hub
 +  * when the root hub logical device is up, we will power
 +  * and reset [ ULPI PHY + [ HUB + ETH ] ]
 +  */
 + .name = reg-panda-smsc95xx,
 + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
 + },
 +};
 +
 +static struct

Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses

2012-11-28 Thread Laurent Pinchart

Hi Tomi,

On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote:
 Hi,
 
 This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's
 version instead. The other patch removes an unneeded plat/dma.h include.
 
 These are based on current omapdss master branch, which has the omapdss
 version code. The omapdss version code is queued for v3.8. I'm not sure
 which is the best way to handle these patches due to the dependency to
 omapdss. The easiest option is to merge these for 3.9.
 
 There's still the OMAP DMA use in omap_vout_vrfb.c, which is the last OMAP
 dependency in the omap_vout driver. I'm not going to touch that, as it
 doesn't look as trivial as this cpu_is_* removal, and I don't have much
 knowledge of the omap_vout driver.
 
 Compiled, but not tested.

Tested on a Beagleboard-xM.

Tested-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

The patches depend on unmerged OMAP DSS patches. Would you like to push this 
series through linuxtv or through your DSS tree ? The later might be easier, 
depending on when the required DSS patches will hit mainline.

 Tomi Valkeinen (2):
   [media] omap_vout: use omapdss's version instead of cpu_is_*
   [media] omap_vout: remove extra include
 
  drivers/media/platform/omap/omap_vout.c|4 +--
  drivers/media/platform/omap/omap_voutlib.c |   38 ++---
  drivers/media/platform/omap/omap_voutlib.h |3 +++
  3 files changed, 32 insertions(+), 13 deletions(-)

-- 
Regards,

Laurent Pinchart

--
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: OMAP* Latest build failures

2012-11-28 Thread Russell King - ARM Linux

On Wed, Nov 28, 2012 at 10:04:33AM -0400, Eduardo Valentin wrote:
 Tony, Russell,

 On 20-11-2012 13:57, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
 On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
 And the randconfig found:

 drivers/staging/omap-thermal/omap-bandgap.c: In function 
 'omap_bandgap_readl':
 drivers/staging/omap-thermal/omap-bandgap.c:46:2: error: implicit 
 declaration of function 'readl'
 drivers/staging/omap-thermal/omap-bandgap.c: In function 
 'omap_bandgap_writel':
 drivers/staging/omap-thermal/omap-bandgap.c:51:2: error: implicit 
 declaration of function 'writel'

 Which, as its in staging, maybe its not important but it's another source
 of unnecessary failure.

 Well, it is important, thanks for checking this code. I appreciate if  
 you keep your report.


 Radhesh  Eduardo, can you fix this?


 This has been already fixed:
 https://patchwork.kernel.org/patch/1734621/

 And is already queued by Greg (staging-next):
 http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=commit;h=2aeeb8acfc19f8a9f283081bbf77919b61b92042

Good.  Now, there's also this too:

drivers/staging/omap-thermal/omap-thermal-common.c: In function 
'omap_thermal_expose_sensor':
drivers/staging/omap-thermal/omap-thermal-common.c:259:28: error: storage size 
of 'pdata' isn't known
drivers/staging/omap-thermal/omap-thermal-common.c:261:2: error: 'data' 
undeclared (first use in this function)
drivers/staging/omap-thermal/omap-thermal-common.c:264:3: error: implicit 
declaration of function 'omap_thermal_build_pdata'
drivers/staging/omap-thermal/omap-thermal-common.c: In function 
'omap_thermal_build_cpufreq_clip':
drivers/staging/omap-thermal/omap-thermal-common.c:330:41: error: dereferencing 
pointer to incomplete type
drivers/staging/omap-thermal/omap-thermal-common.c:343:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:343:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:343:6: error: dereferencing 
pointer to incomplete type
drivers/staging/omap-thermal/omap-thermal-common.c:344:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:344:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:344:6: error: dereferencing 
pointer to incomplete type
drivers/staging/omap-thermal/omap-thermal-common.c:345:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:345:3: error: invalid use of 
undefined type 'struct freq_clip_table'
drivers/staging/omap-thermal/omap-thermal-common.c:345:6: error: dereferencing 
pointer to incomplete type
drivers/staging/omap-thermal/omap-thermal-common.c:375:2: error: too many 
arguments to function 'cpufreq_cooling_register'

Is it also fixed in Gregkh's staging-next branch?
--
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: OMAP* Latest build failures

2012-11-28 Thread Russell King - ARM Linux

On Tue, Nov 20, 2012 at 05:00:19PM -0600, Jon Hunter wrote:
 
 On 11/20/2012 11:57 AM, Tony Lindgren wrote:
  * Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
  On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
  OMAP* allnoconfig fails:
 
  arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
  twl-common.c:(.text+0x1e08): undefined reference to 
  `omap_pm_set_min_bus_tput'
  arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup':
  twl-common.c:(.init.text+0x8f8): undefined reference to 
  `omap_pm_if_early_init'
  arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port':
  twl-common.c:(.init.text+0x1284): undefined reference to 
  `omap_pm_get_dev_context_loss_count'
  arch/arm/mach-omap2/built-in.o: In function `omap_timer_init':
  twl-common.c:(.init.text+0x1544): undefined reference to 
  `omap_pm_get_dev_context_loss_count'
  arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init':
  twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init'
  arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
  twl-common.c:(.init.text+0x2168): undefined reference to 
  `omap_pm_get_dev_context_loss_count'
  arch/arm/mach-omap2/built-in.o: In function `omap_display_init':
  twl-common.c:(.init.text+0x25cc): undefined reference to 
  `omap_pm_get_dev_context_loss_count'
 
  These are now gone, but we have a new warning:
 
  arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined 
  but not used
  
  Jon, care to fix this one?
 
 Fix already available here [1]. I actually included this in my latest
 pull request with some other timer clean-ups [2]. Let me know if you are
 ok with this being part of this pull request or if you want to handle
 this separately.
 
 Cheers
 Jon
 
 [1] http://marc.info/?l=linux-omapm=135300866115036w=2
 [2] http://marc.info/?l=linux-omapm=135308624321232w=2

Well, it's now two weeks on, and the warning is still there... what's going
on?  Why aren't fixes propagating upstream?
--
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/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c


On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
 On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
 In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
 counter), the function realtime_counter_init() was added. However, if
 the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
 the following compiler warning is observed.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
defined but not used [-Wunused-function]

 Commit fa6d79d also introduced the kernel configuration option
 CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
 a stub function for realtime_counter_init() is defined.

 The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
 really needed because ...

 1. For non-OMAP5 devices, there is no realtime counter and so
 realtime_counter_init() function is not used.
 2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always selected
 and cannot be disabled, so the stub function for
 realtime_counter_init()
 is never used.

 Fix this warning by removing the kernel configuration option
 CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
 the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

 Cc: Santosh Shilimkar santosh.shilim...@ti.com

 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
 The #ifdef was avoided because the real-time counter can be used on
 other future SOCs. And the those SOCs just select
 SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
 work without real-time counter configuration enabled using 32K counter.
 But since we are any way have that SOC_HAS_REALTIME_COUNTER always
 set for SOC which wants to use it, we can actually remove the stub
 and hence avoid the warning. Let me know if below patch is ok
 with you ? attached the same for mailer issues

 From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
 From: Santosh Shilimkar santosh.shilim...@ti.com
 Date: Wed, 28 Nov 2012 11:28:57 +0530
 Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
 counter), the function realtime_counter_init() was added. However, if
 the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
 the following compiler warning is observed.
 
 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
 defined but not used [-Wunused-function]
 
 It is because of the stub init function which was added for the cases
 where realtime_counter_init() is called with
 !CONFIG_SOC_HAS_REALTIME_COUNTER.
 This is actually not necessary since the SOC which need this feature
 will explicitly select the configuration.
 
 So just drop the unused stub to avoid the build warning.
 
 Patch is made after seeing Jon's patch which was wrapping the
 real-time counter code under needed SOC #ifdef
 
 Cc: Jon Hunter jon-hun...@ti.com
 
 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/timer.c |3 ---
  1 file changed, 3 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 69e4663..79d8e6b 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)
 
  iounmap(base);
  }
 -#else
 -static inline void __init realtime_counter_init(void)
 -{}
  #endif
 
  #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,\

Hi Santosh,

Thanks for the feedback. Unfortunately, the above is not enough. If I
disable SOC_OMAP5 and leave SOC_HAS_REALTIME_COUNTER enabled, then I
still see the warning message. So I could see that people could still
hit this with randconfig.

Understand the desire to make this a selectable configuration, but given
to date only OMAP5 uses it, it was simpler and cleaner just to remove
the option. However, we could keep the option and just do something like ...

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..500f2f6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC

 config SOC_HAS_REALTIME_COUNTER
bool Real time free running counter
+   depends on SOC_OMAP5
+   default y

 config ARCH_OMAP2
bool TI OMAP2
@@ -79,7 +81,6 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_SMP
-   select SOC_HAS_REALTIME_COUNTER
select COMMON_CLK

I have tested this and this resolves the warning.

Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to

Re: [PATCH 1/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c


On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:


On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
really needed because ...

1. For non-OMAP5 devices, there is no realtime counter and so
 realtime_counter_init() function is not used.
2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always selected
 and cannot be disabled, so the stub function for
realtime_counter_init()
 is never used.

Fix this warning by removing the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

Cc: Santosh Shilimkar santosh.shilim...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---

The #ifdef was avoided because the real-time counter can be used on
other future SOCs. And the those SOCs just select
SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
work without real-time counter configuration enabled using 32K counter.
But since we are any way have that SOC_HAS_REALTIME_COUNTER always
set for SOC which wants to use it, we can actually remove the stub
and hence avoid the warning. Let me know if below patch is ok
with you ? attached the same for mailer issues

 From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 28 Nov 2012 11:28:57 +0530
Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
 defined but not used [-Wunused-function]

It is because of the stub init function which was added for the cases
where realtime_counter_init() is called with
!CONFIG_SOC_HAS_REALTIME_COUNTER.
This is actually not necessary since the SOC which need this feature
will explicitly select the configuration.

So just drop the unused stub to avoid the build warning.

Patch is made after seeing Jon's patch which was wrapping the
real-time counter code under needed SOC #ifdef

Cc: Jon Hunter jon-hun...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
  arch/arm/mach-omap2/timer.c |3 ---
  1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69e4663..79d8e6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)

  iounmap(base);
  }
-#else
-static inline void __init realtime_counter_init(void)
-{}
  #endif

  #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,\


Hi Santosh,

Thanks for the feedback. Unfortunately, the above is not enough. If I
disable SOC_OMAP5 and leave SOC_HAS_REALTIME_COUNTER enabled, then I
still see the warning message. So I could see that people could still
hit this with randconfig.


I did mention that but since OMAP5 selects the feature, I was thinking
it is fine.


Understand the desire to make this a selectable configuration, but given
to date only OMAP5 uses it, it was simpler and cleaner just to remove
the option. However, we could keep the option and just do something like ...

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..500f2f6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC

  config SOC_HAS_REALTIME_COUNTER
 bool Real time free running counter
+   depends on SOC_OMAP5
+   default y

  config ARCH_OMAP2
 bool TI OMAP2
@@ -79,7 +81,6 @@ config SOC_OMAP5
 select ARM_GIC
 select CPU_V7
 select HAVE_SMP
-   select SOC_HAS_REALTIME_COUNTER
 select COMMON_CLK

I have tested this and this resolves the warning.


Go ahead and fold above change on top of

Re: [PATCH 1/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c


On 11/28/2012 09:55 AM, Santosh Shilimkar wrote:
 On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:

 On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:
 On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
 In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
 counter), the function realtime_counter_init() was added. However, if
 the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
 the following compiler warning is observed.

 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:489:20: warning:
 ‘realtime_counter_init’
 defined but not used [-Wunused-function]

 Commit fa6d79d also introduced the kernel configuration option
 CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then
 the
 a stub function for realtime_counter_init() is defined.

 The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
 really needed because ...

 1. For non-OMAP5 devices, there is no realtime counter and so
  realtime_counter_init() function is not used.
 2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always
 selected
  and cannot be disabled, so the stub function for
 realtime_counter_init()
  is never used.

 Fix this warning by removing the kernel configuration option
 CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
 the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

 Cc: Santosh Shilimkar santosh.shilim...@ti.com

 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
 The #ifdef was avoided because the real-time counter can be used on
 other future SOCs. And the those SOCs just select
 SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
 work without real-time counter configuration enabled using 32K counter.
 But since we are any way have that SOC_HAS_REALTIME_COUNTER always
 set for SOC which wants to use it, we can actually remove the stub
 and hence avoid the warning. Let me know if below patch is ok
 with you ? attached the same for mailer issues

  From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
 From: Santosh Shilimkar santosh.shilim...@ti.com
 Date: Wed, 28 Nov 2012 11:28:57 +0530
 Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in
 timer.c
 MIME-Version: 1.0
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
 counter), the function realtime_counter_init() was added. However, if
 the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
 the following compiler warning is observed.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning:
 ‘realtime_counter_init’
  defined but not used [-Wunused-function]

 It is because of the stub init function which was added for the cases
 where realtime_counter_init() is called with
 !CONFIG_SOC_HAS_REALTIME_COUNTER.
 This is actually not necessary since the SOC which need this feature
 will explicitly select the configuration.

 So just drop the unused stub to avoid the build warning.

 Patch is made after seeing Jon's patch which was wrapping the
 real-time counter code under needed SOC #ifdef

 Cc: Jon Hunter jon-hun...@ti.com

 Reported-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
   arch/arm/mach-omap2/timer.c |3 ---
   1 file changed, 3 deletions(-)

 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index 69e4663..79d8e6b 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)

   iounmap(base);
   }
 -#else
 -static inline void __init realtime_counter_init(void)
 -{}
   #endif

   #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,\

 Hi Santosh,

 Thanks for the feedback. Unfortunately, the above is not enough. If I
 disable SOC_OMAP5 and leave SOC_HAS_REALTIME_COUNTER enabled, then I
 still see the warning message. So I could see that people could still
 hit this with randconfig.

 I did mention that but since OMAP5 selects the feature, I was thinking
 it is fine.
 
 Understand the desire to make this a selectable configuration, but given
 to date only OMAP5 uses it, it was simpler and cleaner just to remove
 the option. However, we could keep the option and just do something
 like ...

 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 813c267..500f2f6 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC

   config SOC_HAS_REALTIME_COUNTER
  bool Real time free running counter
 +   depends on SOC_OMAP5
 +   default y

   config ARCH_OMAP2
  bool TI OMAP2
 @@ -79,7 +81,6 @@ config SOC_OMAP5
  select ARM_GIC
  select CPU_V7
  select HAVE_SMP
 -

Re: [PATCH 1/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c


On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:


On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
really needed because ...

1. For non-OMAP5 devices, there is no realtime counter and so
 realtime_counter_init() function is not used.
2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always selected
 and cannot be disabled, so the stub function for
realtime_counter_init()
 is never used.

Fix this warning by removing the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

Cc: Santosh Shilimkar santosh.shilim...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---

The #ifdef was avoided because the real-time counter can be used on
other future SOCs. And the those SOCs just select
SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
work without real-time counter configuration enabled using 32K counter.
But since we are any way have that SOC_HAS_REALTIME_COUNTER always
set for SOC which wants to use it, we can actually remove the stub
and hence avoid the warning. Let me know if below patch is ok
with you ? attached the same for mailer issues

 From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 28 Nov 2012 11:28:57 +0530
Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
 defined but not used [-Wunused-function]

It is because of the stub init function which was added for the cases
where realtime_counter_init() is called with
!CONFIG_SOC_HAS_REALTIME_COUNTER.
This is actually not necessary since the SOC which need this feature
will explicitly select the configuration.

So just drop the unused stub to avoid the build warning.

Patch is made after seeing Jon's patch which was wrapping the
real-time counter code under needed SOC #ifdef

Cc: Jon Hunter jon-hun...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
  arch/arm/mach-omap2/timer.c |3 ---
  1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69e4663..79d8e6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)

  iounmap(base);
  }
-#else
-static inline void __init realtime_counter_init(void)
-{}
  #endif

  #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,\


Hi Santosh,

Thanks for the feedback. Unfortunately, the above is not enough. If I
disable SOC_OMAP5 and leave SOC_HAS_REALTIME_COUNTER enabled, then I
still see the warning message. So I could see that people could still
hit this with randconfig.


Yes. For the same reason initially, the stub was added.


Understand the desire to make this a selectable configuration, but given
to date only OMAP5 uses it, it was simpler and cleaner just to remove
the option. However, we could keep the option and just do something like ...

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..500f2f6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC

  config SOC_HAS_REALTIME_COUNTER
 bool Real time free running counter
+   depends on SOC_OMAP5
+   default y

  config ARCH_OMAP2
 bool TI OMAP2
@@ -79,7 +81,6 @@ config SOC_OMAP5
 select ARM_GIC
 select CPU_V7
 select HAVE_SMP
-   select SOC_HAS_REALTIME_COUNTER
 select COMMON_CLK

I have tested this and this resolves the warning.


Good. Am ok with above additional update.
May be you can add this

Re: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c


On 11/28/2012 01:20 AM, Santosh Shilimkar wrote:
 On Wednesday 28 November 2012 12:16 PM, Igor Grinberg wrote:
 On 11/28/12 08:28, Santosh Shilimkar wrote:
 On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
 When compiling the kernel with configuration options ...

# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
CONFIG_SOC_AM33XX=y

... the following build warning is seen.

 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:395:19: warning:
 ‘omap2_sync32k_clocksource_init’
 defined but not used [-Wunused-function]

 This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
 CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
 longer referenced by the timer initialisation function for the AM335x
 device as it has no 32k-sync timer.

 Fix this by only including the omap2_sync32k_clocksource_init()
 function
 if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.

 Cc: Igor Grinberg grinb...@compulab.co.il

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
arch/arm/mach-omap2/timer.c |3 +++
1 file changed, 3 insertions(+)

 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index eb96712..085c7e7 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
}

 +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
 +defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 #ifndef CONFIG_SOC_AM33XX ?

 #ifdef things are really ugly and needs constant patching and
 hence something like CONFIG_HAS_32K kind of feature flags are
 better. But that will undo certain part of f80b3b
 (ARM: OMAP2+: timer: remove  CONFIG_OMAP_32K_TIMER).

 Agreed on ugliness of ifdefs.
 What about adding __maybe_unused to the function signature?
 That will cover any future SoC also w/o the need to extend the ifdefs.

 Sounds good to me.

Yes agree on the ugliness of this. However, my thought was these would
only remain until we migrate over to device-tree and then the detection
of the a 32k source can be determine via DT.

However, I can update to use __maybe_unused for now. We just need to
remember to remove this in the future if it becomes unnecessary :-)

Cheers
Jon
--
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/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c


On Wednesday 28 November 2012 09:31 PM, Jon Hunter wrote:


On 11/28/2012 09:55 AM, Santosh Shilimkar wrote:

On Wednesday 28 November 2012 09:17 PM, Jon Hunter wrote:


On 11/28/2012 12:09 AM, Santosh Shilimkar wrote:

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

 CC  arch/arm/mach-omap2/timer.o
 arch/arm/mach-omap2/timer.c:489:20: warning:
‘realtime_counter_init’
 defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then
the
a stub function for realtime_counter_init() is defined.

The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
really needed because ...

1. For non-OMAP5 devices, there is no realtime counter and so
  realtime_counter_init() function is not used.
2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always
selected
  and cannot be disabled, so the stub function for
realtime_counter_init()
  is never used.

Fix this warning by removing the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

Cc: Santosh Shilimkar santosh.shilim...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---

The #ifdef was avoided because the real-time counter can be used on
other future SOCs. And the those SOCs just select
SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
work without real-time counter configuration enabled using 32K counter.
But since we are any way have that SOC_HAS_REALTIME_COUNTER always
set for SOC which wants to use it, we can actually remove the stub
and hence avoid the warning. Let me know if below patch is ok
with you ? attached the same for mailer issues

  From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 28 Nov 2012 11:28:57 +0530
Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in
timer.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning:
‘realtime_counter_init’
  defined but not used [-Wunused-function]

It is because of the stub init function which was added for the cases
where realtime_counter_init() is called with
!CONFIG_SOC_HAS_REALTIME_COUNTER.
This is actually not necessary since the SOC which need this feature
will explicitly select the configuration.

So just drop the unused stub to avoid the build warning.

Patch is made after seeing Jon's patch which was wrapping the
real-time counter code under needed SOC #ifdef

Cc: Jon Hunter jon-hun...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
   arch/arm/mach-omap2/timer.c |3 ---
   1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69e4663..79d8e6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)

   iounmap(base);
   }
-#else
-static inline void __init realtime_counter_init(void)
-{}
   #endif

   #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,\


Hi Santosh,

Thanks for the feedback. Unfortunately, the above is not enough. If I
disable SOC_OMAP5 and leave SOC_HAS_REALTIME_COUNTER enabled, then I
still see the warning message. So I could see that people could still
hit this with randconfig.


I did mention that but since OMAP5 selects the feature, I was thinking
it is fine.


Understand the desire to make this a selectable configuration, but given
to date only OMAP5 uses it, it was simpler and cleaner just to remove
the option. However, we could keep the option and just do something
like ...

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..500f2f6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC

   config SOC_HAS_REALTIME_COUNTER
  bool Real time free running counter
+   depends on SOC_OMAP5
+   default y

   config ARCH_OMAP2
  bool TI OMAP2
@@ -79,7 +81,6 @@ config SOC_OMAP5
  select ARM_GIC
  select CPU_V7
  select HAVE_SMP
-   select

Re: [PATCH v2 13/22] mfd: omap-usb-host: override number of ports from platform data

* Roger Quadros rog...@ti.com [121128 06:52]:
 Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
 but they have different number of ports i.e. 2 and 3 respectively.
 So we can't rely on REVISION register for number of ports on OMAP5
 and depend on platform data (or device tree) instead.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/mach-omap2/usb-host.c|1 +
  arch/arm/plat-omap/include/plat/usb.h |2 +
  drivers/mfd/omap-usb-host.c   |   34 
  3 files changed, 24 insertions(+), 13 deletions(-)

Note that plat/usb.h is now include/linux/platform_data/usb-omap.h
in linux next so you need to coordinate with that.

For the arch/arm/*omap*/* parts:

Acked-by: Tony Lindgren t...@atomide.com
 
 diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
 index 3c43449..eb85528 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data 
 *pdata)
   ohci_data.es2_compatibility = pdata-es2_compatibility;
   usbhs_data.ehci_data = ehci_data;
   usbhs_data.ohci_data = ohci_data;
 + usbhs_data.nports = pdata-nports;
  
   if (cpu_is_omap34xx()) {
   setup_ehci_io_mux(pdata-port_mode);
 diff --git a/arch/arm/plat-omap/include/plat/usb.h 
 b/arch/arm/plat-omap/include/plat/usb.h
 index 87ee140..6b618a1 100644
 --- a/arch/arm/plat-omap/include/plat/usb.h
 +++ b/arch/arm/plat-omap/include/plat/usb.h
 @@ -27,6 +27,7 @@ enum usbhs_omap_port_mode {
  };
  
  struct usbhs_omap_board_data {
 + int nports;
   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
  
   /* have to be valid if phy_reset is true and portx is in phy mode */
 @@ -59,6 +60,7 @@ struct ohci_hcd_omap_platform_data {
  };
  
  struct usbhs_omap_platform_data {
 + int nports;
   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
  
   struct ehci_hcd_omap_platform_data  *ehci_data;
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 87b574b..fda235a 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -495,19 +495,27 @@ static int __devinit usbhs_omap_probe(struct 
 platform_device *pdev)
*/
   pm_runtime_put_sync(dev);
  
 - switch (omap-usbhs_rev) {
 - case OMAP_USBHS_REV1:
 - omap-nports = 3;
 - break;
 - case OMAP_USBHS_REV2:
 - omap-nports = 2;
 - break;
 - default:
 - omap-nports = OMAP3_HS_USB_PORTS;
 - dev_dbg(dev,
 -   USB HOST Rev : 0x%d not recognized, assuming %d ports\n,
 -omap-usbhs_rev, omap-nports);
 - break;
 + /*
 +  * If platform data contains nports then use that
 +  * else make out number of ports from USBHS revision
 +  */
 + if (pdata-nports) {
 + omap-nports = pdata-nports;
 + } else {
 + switch (omap-usbhs_rev) {
 + case OMAP_USBHS_REV1:
 + omap-nports = 3;
 + break;
 + case OMAP_USBHS_REV2:
 + omap-nports = 2;
 + break;
 + default:
 + omap-nports = OMAP3_HS_USB_PORTS;
 + dev_dbg(dev,
 + USB HOST Rev:0x%d not recognized, assuming %d ports\n,
 + omap-usbhs_rev, omap-nports);
 + break;
 + }
   }
  
   for (i = 0; i  omap-nports; i++)
 -- 
 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
--
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 18/22] mfd: omap-usb-host: get rid of cpu_is_omap..() macros

* Roger Quadros rog...@ti.com [121128 06:51]:
 Instead of using cpu_is_omap..() macros in the device driver we
 rely on information provided in the platform data.
 
 The only information we need is whether the USB Host module has
 a single ULPI bypass control bit for all ports or individual bypass
 control bits for each port. OMAP3 REV2.1 and earlier have the former.

Does this depend on the other patches in this series? If not,
this should be applied first as this is blocking omap multiplatform
development. And this too needs to be updated for the new location
of usb-omap.h in linux next.

Other than that:

Acked-by: Tony Lindgren t...@atomide.com

 Signed-off-by: Roger Quadros rog...@ti.com
 CC: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/usb-host.c|4 
  arch/arm/plat-omap/include/plat/usb.h |3 +++
  drivers/mfd/omap-usb-host.c   |3 +--
  3 files changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
 index eb85528..455b135 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -509,6 +509,10 @@ void __init usbhs_init(const struct 
 usbhs_omap_board_data *pdata)
   if (cpu_is_omap34xx()) {
   setup_ehci_io_mux(pdata-port_mode);
   setup_ohci_io_mux(pdata-port_mode);
 +
 + if (omap_rev() = OMAP3430_REV_ES2_1)
 + usbhs_data.single_ulpi_bypass = true;
 +
   } else if (cpu_is_omap44xx()) {
   setup_4430ehci_io_mux(pdata-port_mode);
   setup_4430ohci_io_mux(pdata-port_mode);
 diff --git a/arch/arm/plat-omap/include/plat/usb.h 
 b/arch/arm/plat-omap/include/plat/usb.h
 index 6b618a1..3f2336a 100644
 --- a/arch/arm/plat-omap/include/plat/usb.h
 +++ b/arch/arm/plat-omap/include/plat/usb.h
 @@ -65,6 +65,9 @@ struct usbhs_omap_platform_data {
  
   struct ehci_hcd_omap_platform_data  *ehci_data;
   struct ohci_hcd_omap_platform_data  *ohci_data;
 +
 + /* OMAP3 = ES2.1 have a single ulpi bypass control bit */
 + unsignedsingle_ulpi_bypass:1;
  };
  
  struct usbtll_omap_platform_data {
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 62e1f21..aaf272d 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -24,7 +24,6 @@
  #include linux/clk.h
  #include linux/dma-mapping.h
  #include linux/gpio.h
 -#include plat/cpu.h
  #include plat/usb.h
  #include linux/pm_runtime.h
  
 @@ -400,7 +399,7 @@ static void omap_usbhs_init(struct device *dev)
   reg = ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
  
   /* Bypass the TLL module for PHY mode operation */
 - if (cpu_is_omap3430()  (omap_rev() = OMAP3430_REV_ES2_1)) {
 + if (pdata-single_ulpi_bypass) {
   dev_dbg(dev, OMAP3 ES version = ES2.1\n);
   if (is_ehci_phy_mode(pdata-port_mode[0]) ||
   is_ehci_phy_mode(pdata-port_mode[1]) ||
 -- 
 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: [PATCH v5 3/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs

* Daniel Mack zon...@gmail.com [121128 06:40]:

Please add a patch description here.

Regards,

Tony

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  arch/arm/mach-omap2/gpmc-nand.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
 index f9f23a2..c8a72ba 100644
 --- a/arch/arm/mach-omap2/gpmc-nand.c
 +++ b/arch/arm/mach-omap2/gpmc-nand.c
 @@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
  static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
  {
   /* support only OMAP3 class */
 - if (!cpu_is_omap34xx()) {
 + if (!cpu_is_omap34xx()  !soc_is_am33xx()) {
   pr_err(BCH ecc is not supported on this CPU\n);
   return 0;
   }
  
   /*
 -  * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
 -  * Other chips may be added if confirmed to work.
 +  * For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
 +  * and AM33xx derivates. Other chips may be added if confirmed to work.
*/
   if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW) 
 - (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
 + (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)) 
 + (!soc_is_am33xx())) {
   pr_err(BCH 4-bit mode is not supported on this CPU\n);
   return 0;
   }
 -- 
 1.7.11.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: [RFC PATCH 1/5] drivers : introduce device_path api

2012-11-28 Thread Alan Stern

On Wed, 28 Nov 2012, Roger Quadros wrote:

  board file:
  
  static struct regulator myreg = {
  .name = mydevice-regulator,
  };
  
  static struct device_asset mydevice_assets[] = {
  {
  .name = mydevice-regulator,
  .handler = regulator_default_asset_handler,
  },
  { }
  };
  
  static struct platform_device mydevice = {
  ...
  .dev = {
  .assets = mydevice_assets,
  },
  ...
  };
  
 
 From Pandaboard's point of view, is mydevice supposed to be referring to
 ehci-omap, LAN95xx or something else?

ehci-omap.0.

 Strictly speaking, the regulator doesn't belongs neither to ehci-omap
 nor LAN95xx. It belongs to a power domain on the board. And user should
 have control to switch it OFF when required without hampering operation
 of ehci-omap, so that the other USB ports are still usable.

That is the one disadvantage of the approach we are discussing.

But what API would you use to give the user this control?  Neither the
GPIO nor the regulator has a struct device, so you can't use sysfs
directly.  And even if you could, it would probably be a bad idea
because the user might turn off power to the LAN95xx while the chip was
being used.

The natural answer is to associate the regulator with the USB port that 
the LAN95xx is connected to, so that the new port-power mechanism could 
provide the control you want.  Then how should that association be set 
up?

Lei Ming provided a partial answer, but his suggestion is tied to USB.  
It would be better to have a more general approach.  So far nobody has 
come up with a suggestion that everybody approves of.

Alan Stern

--
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 v5 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

* Daniel Mack zon...@gmail.com [121128 06:40]:
 This patch adds basic DT bindings for OMAP GPMC.
 
 The actual peripherals are instantiated from child nodes within the GPMC
 node, and the only type of device that is currently supported is NAND.
 
 Code was added to parse the generic GPMC timing parameters and some
 documentation with examples on how to use them.
 
 Successfully tested on an AM33xx board.

Please resend this with devicetree-disc...@lists.ozlabs.org and
the people listed in MAINTAINERS in the cc:

Grant Likely grant.lik...@secretlab.ca
Rob Herring rob.herr...@calxeda.com

Regards,

Tony
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
  .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
  arch/arm/mach-omap2/gpmc.c | 181 
 -
  3 files changed, 337 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 
 diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
 b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
 new file mode 100644
 index 000..ba3d6a5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
 @@ -0,0 +1,76 @@
 +Device tree bindings for OMAP general purpose memory controllers (GPMC)
 +
 +The actual devices are instantiated from the child nodes of a GPMC node.
 +
 +Required properties:
 +
 + - compatible:   Should be set to ti,gpmc
 + - reg:  A resource specifier for the register space
 + (see the example below)
 + - ti,hwmods:Should be set to ti,gpmc until the DT 
 transition is
 + completed.
 + - #address-cells:   Must be set to 2 to allow memory address translation
 + - #size-cells:  Must be set to 1 to allow CS address passing
 + - num-cs:   The maximum number of chip-select lines that controller
 + can support.
 + - num-waitpins: The maximum number of wait pins that controller can
 + support.
 + - ranges:   Must be set up to reflect the memory layout with four
 + integer values for each chip-select line in use:
 +
 +cs-number 0 physical address of mapping size
 +
 + Note that this property is not currently parsed.
 + Calculated values derived from the contents of the
 + per-CS register GPMC_CONFIG7 (as set up by the
 + bootloader) are used. That will change in the future,
 + so be sure to fill the correct values here.
 +
 +Timing properties for child nodes. All are optional and default to 0.
 +
 + - gpmc,sync-clk:Minimum clock period for synchronous mode, in 
 picoseconds
 +
 + Chip-select signal timings corresponding to GPMC_CONFIG2:
 + - gpmc,cs-on:   Assertion time
 + - gpmc,cs-rd-off:   Read deassertion time
 + - gpmc,cs-wr-off:   Write deassertion time
 +
 + ADV signal timings corresponding to GPMC_CONFIG3:
 + - gpmc,adv-on:  Assertion time
 + - gpmc,adv-rd-off:  Read deassertion time
 + - gpmc,adv-wr-off:  Write deassertion time
 +
 + WE signals timings corresponding to GPMC_CONFIG4:
 + - gpmc,we-on:   Assertion time
 + - gpmc,we-off:  Deassertion time
 +
 + OE signals timings corresponding to GPMC_CONFIG4:
 + - gpmc,oe-on:   Assertion time
 + - gpmc,oe-off:  Deassertion time
 +
 + Access time and cycle time timings corresponding to GPMC_CONFIG5:
 + - gpmc,page-burst-access: Multiple access word delay
 + - gpmc,access:  Start-cycle to first data valid delay
 + - gpmc,rd-cycle:Total read cycle time
 + - gpmc,wr-cycle:Total write cycle time
 +
 +The following are only on OMAP3430:
 + - gpmc,wr-access
 + - gpmc,wr-data-mux-bus
 +
 +
 +Example for an AM33xx board:
 +
 + gpmc: gpmc@5000 {
 + compatible = ti,gpmc;
 + ti,hwmods = gpmc;
 + reg = 0x5000 0x2000;
 + interrupts = 100;
 +
 + num-cs = 8;
 + #address-cells = 2;
 + #size-cells = 1;
 + ranges = 0 0 0x0800 0x1000; /* CS0 @addr 0x800, 
 size 0x1000 */
 +
 + /* child nodes go here */
 + };
 diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
 b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 new file mode 100644
 index 000..635f550
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 @@ -0,0 +1,81 @@
 +Device tree bindings for GPMC connected NANDs
 +
 +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
 +the GPMC controller with a name of nand.
 +
 +All timing relevant properties as well as generic gpmc child properties are
 +explained in a

Re: [PATCH v2 18/22] mfd: omap-usb-host: get rid of cpu_is_omap..() macros

On 11/28/2012 06:36 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [121128 06:51]:
 Instead of using cpu_is_omap..() macros in the device driver we
 rely on information provided in the platform data.

 The only information we need is whether the USB Host module has
 a single ULPI bypass control bit for all ports or individual bypass
 control bits for each port. OMAP3 REV2.1 and earlier have the former.
 
 Does this depend on the other patches in this series? If not,
 this should be applied first as this is blocking omap multiplatform
 development. And this too needs to be updated for the new location
 of usb-omap.h in linux next.

OK. I'll send this patch separately based on top of linux-next.

 
 Other than that:
 
 Acked-by: Tony Lindgren t...@atomide.com

Thanks.

cheers,
-roger
--
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 v5 2/4] ARM: OMAP: gpmc-nand: drop __init annotation

gpmc_nand_init() will be called from another driver's probe() function,
so the easiest way to prevent section mismatches is to drop the
annotation here.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/gpmc-nand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..f9f23a2 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -89,7 +89,7 @@ static int omap2_nand_gpmc_retime(
return 0;
 }
 
-static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
+static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
/* support only OMAP3 class */
if (!cpu_is_omap34xx()) {
@@ -110,8 +110,8 @@ static bool __init gpmc_hwecc_bch_capable(enum omap_ecc 
ecc_opt)
return 1;
 }
 
-int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
- struct gpmc_timings *gpmc_t)
+int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
+  struct gpmc_timings *gpmc_t)
 {
int err = 0;
struct device *dev = gpmc_nand_device.dev;
-- 
1.7.11.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

[PATCH v5 1/4] mtd: omap-nand: pass device_node in platform data

Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.

For non-DT boards, this change has no effect.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+   struct mtd_part_parser_data ppdata = {};
 
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1556,7 +1557,8 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
goto out_release_mem_region;
}
 
-   mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+   ppdata.of_node = pdata-of_node;
+   mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
  pdata-nr_parts);
 
platform_set_drvdata(pdev, info-mtd);
-- 
1.7.11.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

[PATCH v5 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

This patch adds basic DT bindings for OMAP GPMC.

The actual peripherals are instantiated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.

Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.

Successfully tested on an AM33xx board.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
 arch/arm/mach-omap2/gpmc.c | 181 -
 3 files changed, 337 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 000..ba3d6a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,76 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to ti,gpmc
+ - reg:A resource specifier for the register space
+   (see the example below)
+ - ti,hwmods:  Should be set to ti,gpmc until the DT transition is
+   completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:Must be set to 1 to allow CS address passing
+ - num-cs: The maximum number of chip-select lines that controller
+   can support.
+ - num-waitpins:   The maximum number of wait pins that controller can
+   support.
+ - ranges: Must be set up to reflect the memory layout with four
+   integer values for each chip-select line in use:
+
+  cs-number 0 physical address of mapping size
+
+   Note that this property is not currently parsed.
+   Calculated values derived from the contents of the
+   per-CS register GPMC_CONFIG7 (as set up by the
+   bootloader) are used. That will change in the future,
+   so be sure to fill the correct values here.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk:  Minimum clock period for synchronous mode, in 
picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:Assertion time
+ - gpmc,adv-rd-off:Read deassertion time
+ - gpmc,adv-wr-off:Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off:Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off:Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle:  Total read cycle time
+ - gpmc,wr-cycle:  Total write cycle time
+
+The following are only on OMAP3430:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+   gpmc: gpmc@5000 {
+   compatible = ti,gpmc;
+   ti,hwmods = gpmc;
+   reg = 0x5000 0x2000;
+   interrupts = 100;
+
+   num-cs = 8;
+   #address-cells = 2;
+   #size-cells = 1;
+   ranges = 0 0 0x0800 0x1000; /* CS0 @addr 0x800, 
size 0x1000 */
+
+   /* child nodes go here */
+   };
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..635f550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,81 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of nand.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional

[PATCH v5 3/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs

The am33xx is capable of handling bch error correction modes, so
enable that feature in the driver.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/gpmc-nand.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index f9f23a2..c8a72ba 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,17 +92,18 @@ static int omap2_nand_gpmc_retime(
 static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
 {
/* support only OMAP3 class */
-   if (!cpu_is_omap34xx()) {
+   if (!cpu_is_omap34xx()  !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
 
/*
-* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1.
-* Other chips may be added if confirmed to work.
+* For now, assume 4-bit mode is only supported on OMAP3630 ES1.x, x=1
+* and AM33xx derivates. Other chips may be added if confirmed to work.
 */
if ((ecc_opt == OMAP_ECC_BCH4_CODE_HW) 
-   (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0))) {
+   (!cpu_is_omap3630() || (GET_OMAP_REVISION() == 0)) 
+   (!soc_is_am33xx())) {
pr_err(BCH 4-bit mode is not supported on this CPU\n);
return 0;
}
-- 
1.7.11.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 v5 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

On 28.11.2012 17:46, Tony Lindgren wrote:
 * Daniel Mack zon...@gmail.com [121128 06:40]:
 This patch adds basic DT bindings for OMAP GPMC.

 The actual peripherals are instantiated from child nodes within the GPMC
 node, and the only type of device that is currently supported is NAND.

 Code was added to parse the generic GPMC timing parameters and some
 documentation with examples on how to use them.

 Successfully tested on an AM33xx board.
 
 Please resend this with devicetree-disc...@lists.ozlabs.org and
 the people listed in MAINTAINERS in the cc:
 
 Grant Likely grant.lik...@secretlab.ca
 Rob Herring rob.herr...@calxeda.com

Sorry - I picked the wrong entry from my history when sending. Resent now.


Daniel

--
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 RESEND v5 0/4] OMAP GPMC DT bindings

[Resending +devicetree-discuss, +Rob, +Grant]


This is a series of patches to support GPMC peripherals on OMAP boards.

Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)

The only supported peripheral for now is NAND, but other types would be
easy to add.

Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed
and Rob Herring:

 - add reg and ti,hwmod properties to Documentation
 - use generic of_mtd functions and the property names defined by them,
   namely nand-bus-width and nand-ecc-mode
 - reduce the default register space size in the Documentation to 8K,
   as found in the hwmod code
 - switch to a DT layout based on ranges and address translation.
   Although this property is not currently looked at as long as the
   handling code still uses the runtime calculation methods, we now
   have these values in the bindings, eventually allowing us to
   switch the implementation with less pain.

Version 3 includes fixes pointed out by Jon Hunter:

 - better documentation of the 'ranges' property to describe the
   fact that it's representing the CS lines
 - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments
 - drop interrupt-parent from example bindings
 - add of_node_put() at the end of the child iteration

Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more
details from Jon Hunter and Avinash, Philip:

 - Add num-cs and num-waitpins properties, which will eventually
   be used to get rid of GPMC_CS_NUM
 - Better description of generic nand DT properties
 - Dropped patch 3/4 as an equivalent fix was already merged
 - Added ti,nand-ecc-use-elm property

Version 5 with regards to Avinash, Philip and Peter Korsgaard:

 - Re-add accidentially forgotten
   Documentation/devicetree/bindings/bus/ti-gpmc.txt
 - Rename software ecc mode to sw
 - Initialize gpmc_nand_data-is_elm_used to 'true' rather than 1
 - Drop ti,nand-ecc-use-elm binding in favor of a new ecc mode
   named bch8-am335xrbl-compatible
 - Add two more patches for section mismatch fixups

Daniel Mack (4):
  mtd: omap-nand: pass device_node in platform data
  ARM: OMAP: gpmc-nand: drop __init annotation
  ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
  ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
 arch/arm/mach-omap2/gpmc-nand.c|  15 +-
 arch/arm/mach-omap2/gpmc.c | 181 -
 drivers/mtd/nand/omap2.c   |   4 +-
 5 files changed, 348 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
 create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt

-- 
1.7.11.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 V6 2/2] dmaengine: add helper function to request a slave DMA channel

2012-11-28 Thread Vinod Koul

On Fri, 2012-11-16 at 09:45 -0600, Jon Hunter wrote:
 
 Thanks, Vinod. Can you make sure you also pick up the two fixes  [1][2]
 I sent out?
 
 Cheers
 Jon
 
 [1] http://marc.info/?l=linux-omapm=134859981920598w=2
 [2] http://marc.info/?l=linux-omapm=134998461526129w=2
 
Applied both and merged the branch to my next.
It should show up in linux-next tomorrow

Please check

Thanks

-- 
Vinod Koul
Intel Corp.

--
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] gpio: New driver for GPO emulation using PWM generators

2012-11-28 Thread Thierry Reding

On Wed, Nov 28, 2012 at 09:54:57AM +0100, Peter Ujfalusi wrote:
 Hi Grant, Lars, Thierry,
 
 On 11/26/2012 04:46 PM, Grant Likely wrote:
  You're effectively asking the pwm layer to behave like a gpio (which
  is completely reasonable). Having a completely separate translation node
  really doesn't make sense because it is entirely a software construct.
  In fact, the way your using it is *entirely* to make the Linux driver
  model instantiate the translation code. It has *nothing* to do with the
  structure of the hardware. It makes complete sense that if a PWM is
  going to be used as a GPIO, then the PWM node should conform to the GPIO
  binding.
 
 I understand your point around this. I might say I agree with it as well...
 I spent yesterday with prototyping and I'm not really convinced that it is a
 good approach from C code point of view. I got it working, yes.
 In essence this is what I have on top of the slightly modified gpio-pwm.c
 driver I have submitted:
 
 DTS files:
 twl_pwm: pwm {
   /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
   compatible = ti,twl6030-pwm;
   #pwm-cells = 2;
 
   /* Enable GPIO us of the PWMs */
   gpio-controller = 1;
   #gpio-cells = 2;
   pwm,period_ns = 7812500;
 };
 
 leds {
   compatible = gpio-leds;
   backlight {
   label = omap4::backlight;
   gpios = twl_pwm 1 0; /* PWM1 of twl6030 */
   };
 
   keypad {
   label = omap4::keypad;
   gpios = twl_pwm 0 0; /* PWM0 of twl6030 */
   };
 };
 
 The bulk of the code in drivers/pwm/core.c to create the pwm-gpo device when
 it is requested going to look something like this. I have removed the error
 checks for now and I still don't have the code to clean up the allocated
 memory for the created device on error, or in case the module is unloaded. We
 should also prevent the pwm core from removal when the pwm-gpo driver is 
 loaded.
 We need to create the platform device for gpo-pwm, create the pdata structure
 for it and fill it in. We also need to hand craft the pwm_lookup table so we
 can use pwm_get() to request the PWM. I have other minor changes around this
 to get things working when we booted with DT.
 So the function to do the heavy lifting is something like this:
 static void of_pwmchip_as_gpio(struct pwm_chip *chip)
 {
   struct platform_device *pdev;
   struct gpio_pwm *gpos;
   struct gpio_pwm_pdata *pdata;
   struct pwm_lookup *lookup;
   char gpodev_name[15];
   int i;
   u32 gpio_mode = 0;
   u32 period_ns = 0;
 
   of_property_read_u32(chip-dev-of_node, gpio-controller,
gpio_mode);
   if (!gpio_mode)
   return;
 
   of_property_read_u32(chip-dev-of_node, pwm,period_ns, period_ns);
   if (!period_ns) {
   dev_err(chip-dev,
   period_ns is not specified for GPIO use\n);
   return;
   }
 
   lookup = devm_kzalloc(chip-dev, sizeof(*lookup) * chip-npwm,
 GFP_KERNEL);
   pdata = devm_kzalloc(chip-dev, sizeof(*pdata), GFP_KERNEL);
   gpos = devm_kzalloc(chip-dev, sizeof(*gpos) * chip-npwm,
   GFP_KERNEL);
 
   pdata-gpos = gpos;
   pdata-num_gpos = chip-npwm;
   pdata-gpio_base = -1;
 
   pdev = platform_device_alloc(pwm-gpo, chip-base);
   pdev-dev.parent = chip-dev;
 
   sprintf(gpodev_name, pwm-gpo.%d, chip-base);
   for (i = 0; i  chip-npwm; i++) {
   struct gpio_pwm *gpo = gpos[i];
   struct pwm_lookup *pl = lookup[i];
   char con_id[15];
 
   sprintf(con_id, pwm-gpo.%d, chip-base + i);
 
   /* prepare GPO information */
   gpo-pwm_period_ns = period_ns;
   gpo-name = kmemdup(con_id, sizeof(con_id), GFP_KERNEL);;
 
   /* prepare pwm lookup table */
   pl-provider = dev_name(chip-dev);
   pl-index = i;
   pl-dev_id = kmemdup(gpodev_name, sizeof(gpodev_name),
GFP_KERNEL);
   pl-con_id = kmemdup(con_id, sizeof(con_id), GFP_KERNEL);
   }
 
   platform_device_add_data(pdev, pdata, sizeof(*pdata));
   pwm_add_table(lookup, chip-npwm);
   platform_device_add(pdev);
 }
 
 PS: as I have said I have removed the error check just to make the code
 snippet more readable and yes we need to do some memory cleanup as well at the
 right time.
 
 Is this something you would like to see?

I must say I'm not terribly thrilled to integrate something like this
into the PWM subsystem. I wish hardware engineers wouldn't come up with
such designs. But since this seems to be a real use-case, if we want to
support it we should try and find the right solution.

Reading the above sounds overly complicated. Couldn't we, instead of
instantiating an extra driver, just register a GPIO chip if a chip wants
to support this

Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

2012-11-28 Thread Lars-Peter Clausen

On 11/28/2012 09:54 AM, Peter Ujfalusi wrote:
 Hi Grant, Lars, Thierry,
 
 On 11/26/2012 04:46 PM, Grant Likely wrote:
 You're effectively asking the pwm layer to behave like a gpio (which
 is completely reasonable). Having a completely separate translation node
 really doesn't make sense because it is entirely a software construct.
 In fact, the way your using it is *entirely* to make the Linux driver
 model instantiate the translation code. It has *nothing* to do with the
 structure of the hardware. It makes complete sense that if a PWM is
 going to be used as a GPIO, then the PWM node should conform to the GPIO
 binding.
 
 I understand your point around this. I might say I agree with it as well...
 I spent yesterday with prototyping and I'm not really convinced that it is a
 good approach from C code point of view. I got it working, yes.
 In essence this is what I have on top of the slightly modified gpio-pwm.c
 driver I have submitted:
 
 DTS files:
 twl_pwm: pwm {
   /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
   compatible = ti,twl6030-pwm;
   #pwm-cells = 2;
 
   /* Enable GPIO us of the PWMs */
   gpio-controller = 1;
   #gpio-cells = 2;
   pwm,period_ns = 7812500;
 };
 
 leds {
   compatible = gpio-leds;
   backlight {
   label = omap4::backlight;
   gpios = twl_pwm 1 0; /* PWM1 of twl6030 */
   };
 
   keypad {
   label = omap4::keypad;
   gpios = twl_pwm 0 0; /* PWM0 of twl6030 */
   };
 };
 
 The bulk of the code in drivers/pwm/core.c to create the pwm-gpo device when
 it is requested going to look something like this. I have removed the error
 checks for now and I still don't have the code to clean up the allocated
 memory for the created device on error, or in case the module is unloaded. We
 should also prevent the pwm core from removal when the pwm-gpo driver is 
 loaded.
 We need to create the platform device for gpo-pwm, create the pdata structure
 for it and fill it in. We also need to hand craft the pwm_lookup table so we
 can use pwm_get() to request the PWM. I have other minor changes around this
 to get things working when we booted with DT.
 So the function to do the heavy lifting is something like this:
 static void of_pwmchip_as_gpio(struct pwm_chip *chip)
 {
   struct platform_device *pdev;
   struct gpio_pwm *gpos;
   struct gpio_pwm_pdata *pdata;
   struct pwm_lookup *lookup;
   char gpodev_name[15];
   int i;
   u32 gpio_mode = 0;
   u32 period_ns = 0;
 
   of_property_read_u32(chip-dev-of_node, gpio-controller,
gpio_mode);
   if (!gpio_mode)
   return;
 
   of_property_read_u32(chip-dev-of_node, pwm,period_ns, period_ns);
   if (!period_ns) {
   dev_err(chip-dev,
   period_ns is not specified for GPIO use\n);
   return;
   }
 
   lookup = devm_kzalloc(chip-dev, sizeof(*lookup) * chip-npwm,
 GFP_KERNEL);
   pdata = devm_kzalloc(chip-dev, sizeof(*pdata), GFP_KERNEL);
   gpos = devm_kzalloc(chip-dev, sizeof(*gpos) * chip-npwm,
   GFP_KERNEL);
 
   pdata-gpos = gpos;
   pdata-num_gpos = chip-npwm;
   pdata-gpio_base = -1;
 
   pdev = platform_device_alloc(pwm-gpo, chip-base);
   pdev-dev.parent = chip-dev;
 
   sprintf(gpodev_name, pwm-gpo.%d, chip-base);
   for (i = 0; i  chip-npwm; i++) {
   struct gpio_pwm *gpo = gpos[i];
   struct pwm_lookup *pl = lookup[i];
   char con_id[15];
 
   sprintf(con_id, pwm-gpo.%d, chip-base + i);
 
   /* prepare GPO information */
   gpo-pwm_period_ns = period_ns;
   gpo-name = kmemdup(con_id, sizeof(con_id), GFP_KERNEL);;
 
   /* prepare pwm lookup table */
   pl-provider = dev_name(chip-dev);
   pl-index = i;
   pl-dev_id = kmemdup(gpodev_name, sizeof(gpodev_name),
GFP_KERNEL);
   pl-con_id = kmemdup(con_id, sizeof(con_id), GFP_KERNEL);
   }
 
   platform_device_add_data(pdev, pdata, sizeof(*pdata));
   pwm_add_table(lookup, chip-npwm);
   platform_device_add(pdev);
 }
 

The whole pwm lookup table creation is a bit ugly. I wonder if we can somehow
bypass this by using pwm_request_from_chip directly in the pwm-gpo driver.

- Lars

--
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: OMAP* Latest build failures


On 11/28/2012 09:18 AM, Russell King - ARM Linux wrote:
 On Tue, Nov 20, 2012 at 05:00:19PM -0600, Jon Hunter wrote:

 On 11/20/2012 11:57 AM, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [121117 01:35]:
 On Wed, Nov 14, 2012 at 09:26:43AM +, Russell King - ARM Linux wrote:
 OMAP* allnoconfig fails:

 arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
 twl-common.c:(.text+0x1e08): undefined reference to 
 `omap_pm_set_min_bus_tput'
 arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup':
 twl-common.c:(.init.text+0x8f8): undefined reference to 
 `omap_pm_if_early_init'
 arch/arm/mach-omap2/built-in.o: In function `omap_serial_init_port':
 twl-common.c:(.init.text+0x1284): undefined reference to 
 `omap_pm_get_dev_context_loss_count'
 arch/arm/mach-omap2/built-in.o: In function `omap_timer_init':
 twl-common.c:(.init.text+0x1544): undefined reference to 
 `omap_pm_get_dev_context_loss_count'
 arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_init':
 twl-common.c:(.init.text+0x1af0): undefined reference to `omap_pm_if_init'
 arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init':
 twl-common.c:(.init.text+0x2168): undefined reference to 
 `omap_pm_get_dev_context_loss_count'
 arch/arm/mach-omap2/built-in.o: In function `omap_display_init':
 twl-common.c:(.init.text+0x25cc): undefined reference to 
 `omap_pm_get_dev_context_loss_count'

 These are now gone, but we have a new warning:

 arch/arm/mach-omap2/timer.c:163:28: warning: 'omap_counter_match' defined 
 but not used

 Jon, care to fix this one?

 Fix already available here [1]. I actually included this in my latest
 pull request with some other timer clean-ups [2]. Let me know if you are
 ok with this being part of this pull request or if you want to handle
 this separately.

 Cheers
 Jon

 [1] http://marc.info/?l=linux-omapm=135300866115036w=2
 [2] http://marc.info/?l=linux-omapm=135308624321232w=2
 
 Well, it's now two weeks on, and the warning is still there... what's going
 on?  Why aren't fixes propagating upstream?

I saw a pull request from Tony on Monday night [1], however, does not
appear to have made its way to ARM SoC yet. So it's on it's way.

Cheers
Jon

[1] http://marc.info/?l=linux-omapm=135397838631792w=2

--
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 0/4] ARM: OMAP2+: Timer build warnings and error fixes

Fixes for build warnings and errors seen with various kernel
configuration combinations. Based upon Tony Lindgren's OMAP
master branch.

V2 changes:
- Update fix for realtime counter per feedback from Santosh
- Update fix when building for only AM335x with Igor's suggestion to
  use __maybe_unused (thanks Igor!)
- Add Vaibhav's fixes for sparse warnings

Jon Hunter (3):
  ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
  ARM: OMAP4: Fix build error and warning in timer.c
  ARM: AM335x: Fix warning in timer.c

Vaibhav Hiremath (1):
  ARM: OMAP2+: Fix sparse warnings in timer.c

 arch/arm/mach-omap2/Kconfig |3 ++-
 arch/arm/mach-omap2/timer.c |8 
 2 files changed, 6 insertions(+), 5 deletions(-)

-- 
1.7.10.4

--
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 4/4] ARM: OMAP2+: Fix sparse warnings in timer.c

From: Vaibhav Hiremath hvaib...@ti.com

Sparse generates the following warnings when compiling mach-omap2/timer.c.

  CHECK   arch/arm/mach-omap2/timer.c
  arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
  was not declared. Should it be static?
  arch/arm/mach-omap2/timer.c:213:12: warning: symbol
  'omap_dm_timer_get_errata' was not declared. Should it be static?

Add static to function declaration to fix warnings.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 79df809..c6d173f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -190,7 +190,7 @@ static struct device_node * __init omap_get_timer_dt(struct 
of_device_id *match,
  * kernel registering these devices remove them dynamically from the device
  * tree on boot.
  */
-void __init omap_dmtimer_init(void)
+static void __init omap_dmtimer_init(void)
 {
struct device_node *np;
 
@@ -210,7 +210,7 @@ void __init omap_dmtimer_init(void)
  *
  * Get the timer errata flags that are specific to the OMAP device being used.
  */
-u32 __init omap_dm_timer_get_errata(void)
+static u32 __init omap_dm_timer_get_errata(void)
 {
if (cpu_is_omap24xx())
return 0;
-- 
1.7.10.4

--
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 1/4] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
  defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

For non-OMAP5 devices, there is no realtime counter and so
realtime_counter_init() function and stub function are not used for
these devices. Therefore, fix this warning by only allowing the kernel
configuration option CONFIG_SOC_HAS_REALTIME_COUNTER to be enabled for
OMAP5 devices.

Cc: Santosh Shilimkar santosh.shilim...@ti.com

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..500f2f6 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -26,6 +26,8 @@ config SOC_HAS_OMAP2_SDRC
 
 config SOC_HAS_REALTIME_COUNTER
bool Real time free running counter
+   depends on SOC_OMAP5
+   default y
 
 config ARCH_OMAP2
bool TI OMAP2
@@ -79,7 +81,6 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_SMP
-   select SOC_HAS_REALTIME_COUNTER
select COMMON_CLK
 
 comment OMAP Core Type
-- 
1.7.10.4

--
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 3/4] ARM: AM335x: Fix warning in timer.c

When compiling the kernel with configuration options ...

 # CONFIG_ARCH_OMAP2 is not set
 # CONFIG_ARCH_OMAP3 is not set
 # CONFIG_ARCH_OMAP4 is not set
 # CONFIG_SOC_OMAP5 is not set
 CONFIG_SOC_AM33XX=y

 ... the following build warning is seen.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by adding the __maybe_unused compiler directive to the
omap2_sync32k_clocksource_init() function to indicate that this function
may be used for certain configurations.

Cc: Igor Grinberg grinb...@compulab.co.il

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 3bbb244..79df809 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -392,7 +392,7 @@ static struct of_device_id omap_counter_match[] __initdata 
= {
 };
 
 /* Setup free-running counter for clocksource */
-static int __init omap2_sync32k_clocksource_init(void)
+static int __init __maybe_unused omap2_sync32k_clocksource_init(void)
 {
int ret;
struct device_node *np = NULL;
-- 
1.7.10.4

--
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 2/4] ARM: OMAP4: Fix build error and warning in timer.c

When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
warning is seen.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
  arch/arm/mach-omap2/timer.c:630:2: error: implicit declaration of
function ‘omap4_sync32_timer_init’
[-Werror=implicit-function-declaration]
  arch/arm/mach-omap2/timer.c: At top level:
  arch/arm/mach-omap2/timer.c:607:1: warning: ‘omap4_sync32k_timer_init’
defined but not used [-Wunused-function]
  cc1: some warnings being treated as errors
  make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the k is missing from the sync32k in
the function name omap4_sync32_timer_init. Therefore, correct this
typo to resolve the above error and warning.

Cc: Igor Grinberg grinb...@compulab.co.il

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
 arch/arm/mach-omap2/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b9cff72..3bbb244 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -630,7 +630,7 @@ static void __init omap4_local_timer_init(void)
 #else /* CONFIG_LOCAL_TIMERS */
 static inline void omap4_local_timer_init(void)
 {
-   omap4_sync32_timer_init();
+   omap4_sync32k_timer_init();
 }
 #endif /* CONFIG_LOCAL_TIMERS */
 OMAP_SYS_TIMER(4, local);
-- 
1.7.10.4

--
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] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected

2012-11-28 Thread David Miller

From: Mugunthan V N mugunthan...@ti.com
Date: Tue, 27 Nov 2012 23:23:40 +0530

   CC  drivers/net/ethernet/ti/cpsw.o
 drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
 drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'
 
 The build warning is generated when CPTS is not selected in Kernel Build.
 Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

Applied.
--
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 0/3] ARM/dts: omap3: Add DT support for IGEP devices

IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patchset adds initial device
tree support for these devices.

The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:

- MMC/SD
- UARTs
- GPIO LEDs
- TWL4030 codec audio
- pinmux/pinconf pinctrl

Some peripheral are still not working such as Flash storage and
Ethernet but support for these will also be included once the
OMAP GPMC device tree binding patches land on mainline.

The patchset is composed of the following patches:

[PATCH 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices
[PATCH 2/3] ARM/dts: omap3: Add support for IGEPv2 board
[PATCH 3/3] ARM/dts: omap3: Add support for IGEP COM Module
--
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 2/3] ARM/dts: omap3: Add support for IGEPv2 board

ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.

This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.

Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/omap3-igep0020.dts |   56 ++
 2 files changed, 57 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-igep0020.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..1dc0f39 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,6 +66,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+   omap3-igep0020.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
new file mode 100644
index 000..9dd4d22
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -0,0 +1,56 @@
+/*
+ * Device Tree Source for IGEPv2 board
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+   model = IGEPv2;
+   compatible = isee,omap3-igep0020, ti,omap3;
+
+   leds {
+   compatible = gpio-leds;
+   boot {
+label = omap3:green:boot;
+gpios = gpio1 26 0;
+linux,default-trigger = default-on;
+   };
+
+   user0 {
+label = omap3:red:user0;
+gpios = gpio1 27 0;
+default-state = off;
+   };
+
+   user1 {
+label = omap3:red:user1;
+gpios = gpio1 28 0;
+default-state = off;
+   };
+
+   user2 {
+   label = omap3:green:user1;
+   gpios = twl_gpio 19 1;
+   };
+   };
+};
+
+i2c3 {
+   clock-frequency = 10;
+
+   /*
+* Display monitor features are burnt in the EEPROM
+* as EDID data.
+*/
+   eeprom@50 {
+   compatible = ti,eeprom;
+   reg = 0x50;
+   };
+};
-- 
1.7.7.6

--
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 3/3] ARM/dts: omap3: Add support for IGEP COM Module

ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.

This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/omap3-igep0030.dts |   43 ++
 2 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-igep0030.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1dc0f39..78c99bc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -67,6 +67,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap3-igep0020.dtb \
+   omap3-igep0030.dtb \
omap4-panda.dtb \
omap4-pandaES.dtb \
omap4-var_som.dtb \
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
b/arch/arm/boot/dts/omap3-igep0030.dts
new file mode 100644
index 000..5ed7033
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -0,0 +1,43 @@
+/*
+ * Device Tree Source for IGEP COM Module
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ omap3-igep.dtsi
+
+/ {
+   model = IGEP COM Module;
+   compatible = isee,omap3-igep0030, ti,omap3;
+
+   leds {
+   compatible = gpio-leds;
+   boot {
+label = omap3:green:boot;
+gpios = gpio1 54 0;
+linux,default-trigger = default-on;
+   };
+
+   user0 {
+label = omap3:red:user0;
+gpios = gpio1 53 0;
+default-state = off;
+   };
+
+   user1 {
+label = omap3:red:user1;
+gpios = gpio1 16 0;
+default-state = off;
+   };
+
+   user2 {
+   label = omap3:green:user1;
+   gpios = twl_gpio 19 1;
+   };
+   };
+};
-- 
1.7.7.6

--
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 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices

Add a generic .dtsi device tree source file for the
common characteristics across IGEP Technology devices.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/omap3-igep.dtsi |   93 +
 1 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-igep.dtsi

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
new file mode 100644
index 000..a093bff
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -0,0 +1,93 @@
+/*
+ * Device Tree Source for IGEP Technology devices
+ *
+ * Copyright (C) 2012 Javier Martinez Canillas jav...@collabora.co.uk
+ * Copyright (C) 2012 Enric Balletbo i Serra eballe...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x2000; /* 512 MB */
+   };
+
+   sound {
+   compatible = ti,omap-twl4030;
+   ti,model = igep2;
+   ti,mcbsp = mcbsp2;
+   ti,codec = twl_audio;
+   };
+};
+
+omap3_pmx_core {
+   pinctrl-names = default;
+   pinctrl-0 = 
+ mcbsp2_pins
+   ;
+
+   uart3_pins: pinmux_uart3_pins {
+   pinctrl-single,pins = 
+   0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0 */
+   0x170 0 /* uart3_tx.uart3_tx OUTPUT | MODE0 */
+   ;
+   };
+
+   mcbsp2_pins: pinmux_mcbsp2_pins {
+   pinctrl-single,pins = 
+   0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4 */
+   ;
+   };
+};
+
+i2c1 {
+   clock-frequency = 260;
+
+   twl: twl@48 {
+   reg = 0x48;
+   interrupts = 7; /* SYS_NIRQ cascaded to intc */
+   interrupt-parent = intc;
+
+   vsim: regulator@10 {
+   compatible = ti,twl4030-vsim;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 300;
+   };
+
+   twl_audio: audio {
+   compatible = ti,twl4030-audio;
+   codec {
+ };
+   };
+   };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+   clock-frequency = 40;
+};
+
+mmc1 {
+   vmmc-supply = vmmc1;
+   vmmc_aux-supply = vsim;
+   bus-width = 8;
+};
+
+mmc2 {
+   status = disabled;
+};
+
+mmc3 {
+   status = disabled;
+};
+
+twl_gpio {
+   ti,use-leds;
+};
-- 
1.7.7.6

--
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] MAINTAINERS: update email address for Kevin Hilman

2012-11-28 Thread Kevin Hilman

Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9386a63..17f2ad2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5236,7 +5236,7 @@ S:Maintained
 F: arch/arm/*omap*/*clock*
 
 OMAP POWER MANAGEMENT SUPPORT
-M: Kevin Hilman khil...@ti.com
+M: Kevin Hilman khil...@deeprootsystems.com
 L: linux-omap@vger.kernel.org
 S: Maintained
 F: arch/arm/*omap*/*pm*
@@ -5331,7 +5331,7 @@ F:arch/arm/*omap*/usb*
 
 OMAP GPIO DRIVER
 M: Santosh Shilimkar santosh.shilim...@ti.com
-M: Kevin Hilman khil...@ti.com
+M: Kevin Hilman khil...@deeprootsystems.com
 L: linux-omap@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-omap.c
@@ -6610,7 +6610,7 @@ F:arch/arm/mach-s3c2410/bast-irq.c
 
 TI DAVINCI MACHINE SUPPORT
 M: Sekhar Nori nsek...@ti.com
-M: Kevin Hilman khil...@ti.com
+M: Kevin Hilman khil...@deeprootsystems.com
 L: davinci-linux-open-sou...@linux.davincidsp.com (moderated for 
non-subscribers)
 T: git git://gitorious.org/linux-davinci/linux-davinci.git
 Q: http://patchwork.kernel.org/project/linux-davinci/list/
-- 
1.8.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/5] drivers : introduce device_path api

2012-11-28 Thread Ming Lei

On Thu, Nov 29, 2012 at 12:43 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Wed, 28 Nov 2012, Roger Quadros wrote:

  board file:
 
  static struct regulator myreg = {
  .name = mydevice-regulator,
  };
 
  static struct device_asset mydevice_assets[] = {
  {
  .name = mydevice-regulator,
  .handler = regulator_default_asset_handler,
  },
  { }
  };
 
  static struct platform_device mydevice = {
  ...
  .dev = {
  .assets = mydevice_assets,
  },
  ...
  };
 

 From Pandaboard's point of view, is mydevice supposed to be referring to
 ehci-omap, LAN95xx or something else?

 ehci-omap.0.

 Strictly speaking, the regulator doesn't belongs neither to ehci-omap
 nor LAN95xx. It belongs to a power domain on the board. And user should
 have control to switch it OFF when required without hampering operation
 of ehci-omap, so that the other USB ports are still usable.

 That is the one disadvantage of the approach we are discussing.

 But what API would you use to give the user this control?  Neither the
 GPIO nor the regulator has a struct device, so you can't use sysfs
 directly.  And even if you could, it would probably be a bad idea
 because the user might turn off power to the LAN95xx while the chip was
 being used.

After Tianyu introduced the power power on/off mechanism, sometimes
one port power need to be switched off/on. Embedded system is more
power sensitive than PC, sounds we have no reason to reject applying
the mechanism on embedded world(non ACPI). Looks better to associate
the power domain thing(regulator, clock, ...) with one usb port device in
this USB problem.


 The natural answer is to associate the regulator with the USB port that
 the LAN95xx is connected to, so that the new port-power mechanism could
 provide the control you want.  Then how should that association be set
 up?

As I suggested in below link, the association can be set up easily with one
structure of 'struct port_power_domain'.

 http://www.spinics.net/lists/linux-omap/msg83158.html


 Lei Ming provided a partial answer, but his suggestion is tied to USB.

If we want to set up the association between usb port and power domain,
usb knowledge is required, at least bus info and port topology are needed.

One difficulty is the fact that the device(such as usb port) is independent
with the 'power domain', for example, the device isn't created(ports of the
root hub is created after ehci-omap probe, and port device of non-root
hub may depend on powering on the power domain) when defining the regulator
things, so could we figure out one general way in theory to describe the
associated device with the 'power domain'? Andy has tried the wildcard dev
path, and port topology string is introduced in my suggestion, looks both
are not general.

I admit the suggestion is partial because we still have not a general abstract
on 'power domain' in this problem, and once it is ready, the solution might be
in a shape at least for USB. In PC world, ACPI might do sort of something of
the 'power domain'

Maybe we need to create a new thread on this discussion and make more
guys involved(PM/USB/driver core/OMAP/). I will study the problem further,
and hope I can post something for starting the discussion later.

 It would be better to have a more general approach.  So far nobody has

Yes, I agree. IMO, my suggestion is still in the direction to being general,
because a general 'power domain' concept is introduced in it, for example
the 'struct power_domain' is associated with 'struct port_power_domain'.

I understand the same 'power domain' concept should be applied to other
device or bus too, and the power associated with this device can be switched off
sometimes too for saving power consumption. But still looks specific
device/subsystem knowledge is required to set up the association.

Alan, so could the above be your concern on a more general approach?
Or you hope a more general way(such as, do it in driver core or dev PM core)
to associate the 'power domain' with one device(for example, usb port in
the LAN95xx problem) too? Or other things?


Thanks,
-- 
Ming Lei
--
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 3/4] ARM: AM335x: Fix warning in timer.c


On Thursday 29 November 2012 03:34 AM, Jon Hunter wrote:

When compiling the kernel with configuration options ...

  # CONFIG_ARCH_OMAP2 is not set
  # CONFIG_ARCH_OMAP3 is not set
  # CONFIG_ARCH_OMAP4 is not set
  # CONFIG_SOC_OMAP5 is not set
  CONFIG_SOC_AM33XX=y

  ... the following build warning is seen.

   CC  arch/arm/mach-omap2/timer.o
   arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by adding the __maybe_unused compiler directive to the
omap2_sync32k_clocksource_init() function to indicate that this function
may be used for certain configurations.

Cc: Igor Grinberg grinb...@compulab.co.il

Signed-off-by: Jon Hunter jon-hun...@ti.com
---

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

--
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 4/4] ARM: OMAP2+: Fix sparse warnings in timer.c


On Thursday 29 November 2012 03:35 AM, Jon Hunter wrote:

From: Vaibhav Hiremath hvaib...@ti.com

Sparse generates the following warnings when compiling mach-omap2/timer.c.

   CHECK   arch/arm/mach-omap2/timer.c
   arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
   was not declared. Should it be static?
   arch/arm/mach-omap2/timer.c:213:12: warning: symbol
   'omap_dm_timer_get_errata' was not declared. Should it be static?

Add static to function declaration to fix warnings.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

--
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 RESEND v5 0/4] OMAP GPMC DT bindings

2012-11-28 Thread Philip, Avinash

On Wed, Nov 28, 2012 at 22:28:55, Daniel Mack wrote:
 [Resending +devicetree-discuss, +Rob, +Grant]
 
 
 This is a series of patches to support GPMC peripherals on OMAP boards.
 
 Depends on Linus' master +
 omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)

Can you resend this series on top of linux_next?
Some of the missing items I seen 
1. Of_node not populated in  omap_nand_platform_data structure.
2. Remove platform device creation from hwmod as GPMC DT is populating.
   Currently GPMC device creaing from DT  HWMOD.

Also can you address how this patch series depends on
mtd: nand: OMAP: ELM error correction support for BCH ecc

Thanks
Avinash

 
 The only supported peripheral for now is NAND, but other types would be
 easy to add.
 
 Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed
 and Rob Herring:
 
  - add reg and ti,hwmod properties to Documentation
  - use generic of_mtd functions and the property names defined by them,
namely nand-bus-width and nand-ecc-mode
  - reduce the default register space size in the Documentation to 8K,
as found in the hwmod code
  - switch to a DT layout based on ranges and address translation.
Although this property is not currently looked at as long as the
handling code still uses the runtime calculation methods, we now
have these values in the bindings, eventually allowing us to
switch the implementation with less pain.
 
 Version 3 includes fixes pointed out by Jon Hunter:
 
  - better documentation of the 'ranges' property to describe the
fact that it's representing the CS lines
  - GPMC_CS_CONFIGx - GPMC_CONFIGx in comments
  - drop interrupt-parent from example bindings
  - add of_node_put() at the end of the child iteration
 
 Version 4 fixes compilation for !CONFIG_MTD_NAND and includes more
 details from Jon Hunter and Avinash, Philip:
 
  - Add num-cs and num-waitpins properties, which will eventually
be used to get rid of GPMC_CS_NUM
  - Better description of generic nand DT properties
  - Dropped patch 3/4 as an equivalent fix was already merged
  - Added ti,nand-ecc-use-elm property
 
 Version 5 with regards to Avinash, Philip and Peter Korsgaard:
 
  - Re-add accidentially forgotten
Documentation/devicetree/bindings/bus/ti-gpmc.txt
  - Rename software ecc mode to sw
  - Initialize gpmc_nand_data-is_elm_used to 'true' rather than 1
  - Drop ti,nand-ecc-use-elm binding in favor of a new ecc mode
named bch8-am335xrbl-compatible
  - Add two more patches for section mismatch fixups
 
 Daniel Mack (4):
   mtd: omap-nand: pass device_node in platform data
   ARM: OMAP: gpmc-nand: drop __init annotation
   ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
   ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
 
  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |  76 +
  .../devicetree/bindings/mtd/gpmc-nand.txt  |  81 +
  arch/arm/mach-omap2/gpmc-nand.c|  15 +-
  arch/arm/mach-omap2/gpmc.c | 181 
 -
  drivers/mtd/nand/omap2.c   |   4 +-
  5 files changed, 348 insertions(+), 9 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
  create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
 
 -- 
 1.7.11.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: [try#1 PATCH 5/7] omap4: panda: add smsc95xx regulator and reset dependent on root hub