[PATCH] gpio: twl4030: Correct status reporting when the GPIO is used as output
When the GPIO is configured as output we need to read the GPIODATAOUT* register to get correct information. When the GPIO is output the GPIODATAIN* registers report 0 all the time (no feedback from output path). Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/gpio/gpio-twl4030.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c index 55b4fe4..e7aa620 100644 --- a/drivers/gpio/gpio-twl4030.c +++ b/drivers/gpio/gpio-twl4030.c @@ -191,13 +191,19 @@ static int twl4030_get_gpio_datain(int gpio) u8 d_bnk = gpio 3; u8 d_off = gpio 0x7; u8 base = 0; + int direction; int ret = 0; if (unlikely((gpio = TWL4030_GPIO_MAX) || !(gpio_usage_count BIT(gpio return -EPERM; - base = REG_GPIODATAIN1 + d_bnk; + direction = gpio_twl4030_read(REG_GPIODATADIR1 + d_bnk); + if (direction 0 (direction d_off) 0x1) + base = REG_SETGPIODATAOUT1 + d_bnk; + else + base = REG_GPIODATAIN1 + d_bnk; + ret = gpio_twl4030_read(base); if (ret 0) ret = (ret d_off) 0x1; -- 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
[PATCH V2 0/6] OMAPDSS: Cleanup omap_dss_features
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 omapdss_reg_field * moved data from dss_reg_fields to dispc_reg_fields The 3rd patch * added definition of struct omapdss_param_range * moved data from dss_param_range to dispc_param_ranges The 4th patch * created struct feats and initialized dsi_feats * moved data from dss_reg_fields to dsi_reg_fields * created dsi_init_features() to initialize dsi_feats The 5th patch * 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 and dss_param_range and their respective initializations as omap2_dss_reg_fields, omap3_dss_reg_fields, etc. * removed members reg_fields and num_reg_fields from struct omap_dss_features * removed enum dss_feat_reg_field and dss_range_param and corresponding initializations omap2_dss_param_range, omap3_dss_param_range etc. * removed function dss_feat_get_reg_field(), dss_feat_get_param_min() and dss_feat_get_param_max() Changes from V1 * 1st patch: added comments in bytes for new members burst_size_unit and buffer_size_unit * 2nd patch: renamed register_field to omapdss_reg_field removed definition of enum dispc_feat_reg_field created and initialized struct dispc_reg_fields * 3rd patch: renamed struct param_range to omapdss_param_range removed definition of enum dispc_range_param created and initialized struct dispc_param_ranges * 4th patch: removed enum dsi_feat_reg_field created and initialized struct dsi_reg_fields * 5th patch: removed enum dsi_range_param created and initialized struct dsi_param_ranges added member dss_fck corresponding to FEAT_PARAM_DSS_FCK * 6th patch: removed struct dss_param_range and enum dss_range_param removed functions dss_feat_get_param_min() and dss_feat_get_param_max() * 7th patch has been removed 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 (6): 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 drivers/video/omap2/dss/dispc.c| 218 +++- drivers/video/omap2/dss/dsi.c | 206 ++ 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, 368 insertions(+), 334 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 V2 1/6] 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 ce594a1..bbba83f 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -107,6 +107,9 @@ struct dispc_features {
/* no DISPC_IRQ_FRAMEDONETV on this SoC */
bool no_framedone_tv:1;
+
+ u32 buffer_size_unit; /* in bytes */
+ u32 burst_size_unit; /* in bytes */
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1050,7 +1053,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;
}
@@ -1139,7 +1142,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);
@@ -1197,7 +1200,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);
@@ -1241,7 +1244,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;
@@ -4060,6 +4063,8 @@ static const struct dispc_features omap24xx_dispc_feats
__initconst = {
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
.no_framedone_tv= true,
+ .buffer_size_unit = 1,
+ .burst_size_unit= 8,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -4077,6 +4082,8 @@ static const struct dispc_features
omap34xx_rev1_0_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.no_framedone_tv= true,
+ .buffer_size_unit = 1,
+ .burst_size_unit= 8,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -4094,6 +4101,8 @@ static const struct dispc_features
omap34xx_rev3_0_dispc_feats __initconst = {
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
.no_framedone_tv= true,
+ .buffer_size_unit = 1,
+ .burst_size_unit= 8,
};
static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -4111,6 +4120,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 = {
@@ -4128,6 +4139,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 omap_dss_features
[PATCH V2 2/6] 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| 114
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, 89 insertions(+), 64 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index bbba83f..ee4b152 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];
};
+struct dispc_reg_fields {
+ struct omapdss_reg_field firhinc;
+ struct omapdss_reg_field firvinc;
+ struct omapdss_reg_field fifo_low_thresh;
+ struct omapdss_reg_field fifo_high_thresh;
+ struct omapdss_reg_field fifosize;
+ struct omapdss_reg_field hori_accu;
+ struct omapdss_reg_field vert_accu;
+};
+
struct dispc_features {
u8 sw_start;
u8 fp_start;
@@ -110,6 +120,8 @@ struct dispc_features {
u32 buffer_size_unit; /* in bytes */
u32 burst_size_unit; /* in bytes */
+
+ struct dispc_reg_fields *reg_fields;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -1137,17 +1149,17 @@ static void dispc_mgr_set_size(enum omap_channel
channel, u16 width,
static void dispc_init_fifos(void)
{
- u32 size;
+ u32 size, unit;
int fifo;
- u8 start, end;
- u32 unit;
+ const struct omapdss_reg_field *fifo_field;
unit = dispc.feat-buffer_size_unit;
- dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
+ fifo_field = dispc.feat-reg_fields-fifosize;
for (fifo = 0; fifo dispc.feat-num_fifos; ++fifo) {
- size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
+ size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo),
+ fifo_field-start, fifo_field-end);
size *= unit;
dispc.fifo_size[fifo] = size;
@@ -1197,8 +1209,8 @@ static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
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;
+ const struct omapdss_reg_field *hi_field, *lo_field;
unit = dispc.feat-buffer_size_unit;
@@ -1208,20 +1220,20 @@ 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_field = dispc.feat-reg_fields-fifo_high_thresh;
+ lo_field = dispc.feat-reg_fields-fifo_low_thresh;
DSSDBG(fifo(%d) threshold (bytes), old %u/%u, new %u/%u\n,
plane,
REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
- lo_start, lo_end) * unit,
+ lo_field-start, lo_field-end) * unit,
REG_GET(DISPC_OVL_FIFO_THRESHOLD(plane),
- hi_start, hi_end) * unit,
+ hi_field-start, hi_field-end) * unit,
low * unit, high * unit);
dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
- FLD_VAL(high, hi_start, hi_end) |
- FLD_VAL(low, lo_start, lo_end));
+ FLD_VAL(high, hi_field-start, hi_field-end) |
+ FLD_VAL(low, lo_field-start, lo_field-end));
}
void dispc_enable_fifomerge(bool enable)
@@ -1289,14 +1301,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
u32 val;
if (color_comp == DISPC_COLOR_COMPONENT_RGB_Y) {
- u8 hinc_start, hinc_end, vinc_start, vinc_end;
+ const struct omapdss_reg_field *hinc_field, *vinc_field;
- dss_feat_get_reg_field(FEAT_REG_FIRHINC,
- hinc_start, hinc_end);
- dss_feat_get_reg_field(FEAT_REG_FIRVINC,
- vinc_start, vinc_end);
- val = FLD_VAL(vinc, vinc_start, vinc_end) |
- FLD_VAL(hinc, hinc_start, hinc_end);
+ hinc_field = dispc.feat-reg_fields-firhinc;
+ vinc_field = dispc.feat-reg_fields-firvinc;
+
+ val = FLD_VAL(vinc, vinc_field-start, vinc_field-end) |
+ FLD_VAL(hinc, hinc_field-start, hinc_field-end);
dispc_write_reg(DISPC_OVL_FIR(plane), val);
} else {
@@ -1308,13 +1319,13 @@ static void dispc_ovl_set_fir(enum omap_plane plane,
static
[PATCH V2 3/6] 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| 83 +++-
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(+), 43 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ee4b152..6a449a5 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -90,6 +90,14 @@ struct dispc_reg_fields {
struct omapdss_reg_field vert_accu;
};
+struct dispc_param_ranges {
+ struct omapdss_param_range pcd;
+ struct omapdss_param_range downscale;
+ struct omapdss_param_range linewidth;
+ struct omapdss_param_range mgr_width;
+ struct omapdss_param_range 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) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -122,6 +128,7 @@ struct dispc_features {
u32 burst_size_unit; /* in bytes */
struct dispc_reg_fields *reg_fields;
+ struct dispc_param_ranges *params;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -2159,8 +2166,7 @@ static int dispc_ovl_calc_scaling_24xx(unsigned long
pclk, unsigned long lclk,
int error;
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
- const int maxsinglelinewidth =
- dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ const int maxsinglelinewidth = dispc.feat-params-linewidth.max;
*five_taps = false;
@@ -2200,8 +2206,7 @@ static int dispc_ovl_calc_scaling_34xx(unsigned long
pclk, unsigned long lclk,
int error;
u16 in_width, in_height;
int min_factor = min(*decim_x, *decim_y);
- const int maxsinglelinewidth =
- dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ const int maxsinglelinewidth = dispc.feat-params-linewidth.max;
do {
in_height = DIV_ROUND_UP(height, *decim_y);
@@ -2266,9 +2271,8 @@ static int dispc_ovl_calc_scaling_44xx(unsigned long
pclk, unsigned long lclk,
u16 in_width, in_width_max;
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);
+ const int maxsinglelinewidth = dispc.feat-params-linewidth.max;
+ const int maxdownscale = dispc.feat-params-downscale.max;
if (mem_to_mem) {
in_width_max = out_width * maxdownscale;
@@ -2306,7 +2310,7 @@ static int dispc_ovl_calc_scaling(unsigned long pclk,
unsigned long lclk,
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-downscale.max;
const int max_decim_limit = 16;
unsigned long core_clk = 0;
int decim_x, decim_y, ret;
@@ -2974,8 +2978,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-mgr_width.max
+ height = dispc.feat-params-mgr_height.max;
}
static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
@@ -3547,8 +3551,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-pcd.min;
+ pcd_max = dispc.feat-params-pcd.max;
best_pck = 0;
best_ld = 0;
@@ -4099,6 +4103,42 @@ static struct dispc_reg_fields omap5_dispc_reg_fields = {
.vert_accu = { 26, 16 },
};
+static struct dispc_param_ranges omap2_dispc_param_ranges = {
+ .pcd= { 2, 255 },
+ .downscale = { 1,
[PATCH V2 4/6] 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 | 126 +---
drivers/video/omap2/dss/dss_features.c | 16
drivers/video/omap2/dss/dss_features.h |4 -
3 files changed, 114 insertions(+), 32 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index cf32dc7..472cdb4 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;
};
+struct dsi_reg_fields {
+ struct omapdss_reg_field regn;
+ struct omapdss_reg_field regm;
+ struct omapdss_reg_field regm_dispc;
+ struct omapdss_reg_field regm_dsi;
+};
+
+struct feats {
+ const struct dsi_reg_fields *reg_fields;
+};
+
+static const struct feats *dsi_feat;
+
#ifdef DEBUG
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -1602,8 +1615,8 @@ int dsi_pll_set_clock_div(struct platform_device *dsidev,
int r = 0;
u32 l;
int f = 0;
- u8 regn_start, regn_end, regm_start, regm_end;
- u8 regm_dispc_start, regm_dispc_end, regm_dsi_start, regm_dsi_end;
+ const struct omapdss_reg_field *regn_field, *regm_field;
+ const struct omapdss_reg_field *regm_dispc_field, *regm_dsi_field;
DSSDBG(DSI PLL clock config starts);
@@ -1645,12 +1658,10 @@ 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_field = dsi_feat-reg_fields-regn;
+ regm_field = dsi_feat-reg_fields-regm;
+ regm_dispc_field = dsi_feat-reg_fields-regm_dispc;
+ regm_dsi_field = dsi_feat-reg_fields-regm_dsi;
/* DSI_PLL_AUTOMODE = manual */
REG_FLD_MOD(dsidev, DSI_PLL_CONTROL, 0, 0, 0);
@@ -1658,15 +1669,15 @@ int dsi_pll_set_clock_div(struct platform_device
*dsidev,
l = dsi_read_reg(dsidev, DSI_PLL_CONFIGURATION1);
l = FLD_MOD(l, 1, 0, 0);/* DSI_PLL_STOPMODE */
/* DSI_PLL_REGN */
- l = FLD_MOD(l, cinfo-regn - 1, regn_start, regn_end);
+ l = FLD_MOD(l, cinfo-regn - 1, regn_field-start, regn_field-end);
/* DSI_PLL_REGM */
- l = FLD_MOD(l, cinfo-regm, regm_start, regm_end);
+ l = FLD_MOD(l, cinfo-regm, regm_field-start, regm_field-end);
/* DSI_CLOCK_DIV */
l = FLD_MOD(l, cinfo-regm_dispc 0 ? cinfo-regm_dispc - 1 : 0,
- regm_dispc_start, regm_dispc_end);
+ regm_dispc_field-start, regm_dispc_field-end);
/* DSIPROTO_CLOCK_DIV */
l = FLD_MOD(l, cinfo-regm_dsi 0 ? cinfo-regm_dsi - 1 : 0,
- regm_dsi_start, regm_dsi_end);
+ regm_dsi_field-start, regm_dsi_field-end);
dsi_write_reg(dsidev, DSI_PLL_CONFIGURATION1, l);
BUG_ON(cinfo-fint dsi-fint_min || cinfo-fint dsi-fint_max);
@@ -5198,6 +5209,93 @@ static void __exit dsi_uninit_output(struct
platform_device *dsidev)
dss_unregister_output(out);
}
+static struct dsi_reg_fields omap2_dsi_reg_fields = {
+ .regn = { 0, 0 },
+ .regm = { 0, 0 },
+ .regm_dispc = { 0, 0 },
+ .regm_dsi = { 0, 0 },
+};
+
+static struct dsi_reg_fields omap3_dsi_reg_fields = {
+ .regn = { 7, 1 },
+ .regm = { 18, 8 },
+ .regm_dispc = { 22, 19 },
+ .regm_dsi = { 26, 23 },
+};
+
+static struct dsi_reg_fields omap4_dsi_reg_fields = {
+ .regn = { 8, 1 },
+ .regm = { 20, 9 },
+ .regm_dispc = { 25, 21 },
+ .regm_dsi = { 30, 26 },
+};
+
+static struct dsi_reg_fields omap5_dsi_reg_fields = {
+ .regn = { 8, 1 },
+ .regm = { 20, 9 },
+ .regm_dispc = { 25, 21 },
+ .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
[PATCH V2 5/6] 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 | 80 +++-
drivers/video/omap2/dss/dss_features.c | 27 ---
drivers/video/omap2/dss/dss_features.h |7 ---
3 files changed, 69 insertions(+), 45 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 472cdb4..a1ea5ac 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -351,8 +351,20 @@ struct dsi_reg_fields {
struct omapdss_reg_field regm_dsi;
};
+struct dsi_param_ranges {
+ struct omapdss_param_range regn;
+ struct omapdss_param_range regm;
+ struct omapdss_param_range regm_dispc;
+ struct omapdss_param_range regm_dsi;
+ struct omapdss_param_range fint;
+ struct omapdss_param_range lpdiv;
+ struct omapdss_param_range dsi_fck;
+ struct omapdss_param_range dss_fck;
+};
+
struct feats {
const struct dsi_reg_fields *reg_fields;
+ const struct dsi_param_ranges *params;
};
static const struct feats *dsi_feat;
@@ -1342,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-dss_fck.max;
if (req_pck == dsi-cache_req_pck
dsi-cache_cinfo.clkin == dss_sys_clk) {
@@ -1518,7 +1530,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-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;
@@ -1536,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-dss_fck.max;
min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
@@ -5077,14 +5089,13 @@ 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-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-regn_max = dsi_feat-params-regn.max;
+ dsi-regm_max = dsi_feat-params-regm.max;
+ dsi-regm_dispc_max = dsi_feat-params-regm_dispc.max;
+ dsi-regm_dsi_max = dsi_feat-params-regm_dsi.max;
+ dsi-fint_min = dsi_feat-params-fint.min;
+ dsi-fint_max = dsi_feat-params-fint.max;
+ dsi-lpdiv_max = dsi_feat-params-lpdiv.max;
}
static int dsi_get_clocks(struct platform_device *dsidev)
@@ -5237,20 +5248,67 @@ static struct dsi_reg_fields omap5_dsi_reg_fields = {
.regm_dsi = { 30, 26 },
};
+static struct dsi_param_ranges omap2_dsi_param_ranges = {
+ .regn = { 0, 0 },
+ .regm = { 0, 0 },
+ .regm_dispc = { 0, 0 },
+ .regm_dsi = { 0, 0 },
+ .fint = { 0, 0 },
+ .lpdiv = { 0, 0 },
+ .dss_fck= { 0, 17300 },
+};
+
+static struct dsi_param_ranges omap3_dsi_param_ranges = {
+ .regn = { 0, (1 7) - 1 },
+ .regm = { 0, (1 11) - 1 },
+ .regm_dispc = { 0, (1 4) - 1 },
+ .regm_dsi = { 0, (1 4) - 1 },
+ .fint = { 75, 210 },
+ .lpdiv = { 1, (1 13) - 1},
+ .dsi_fck= { 0, 17300 },
+ .dss_fck= { 0, 17300 },
+};
+
+static struct dsi_param_ranges omap4_dsi_param_ranges = {
+ .regn = { 0, (1 8) - 1 },
+ .regm = { 0, (1 12) - 1 },
+ .regm_dispc = { 0, (1 5) - 1 },
+ .regm_dsi = { 0, (1 5) - 1 },
+ .fint = { 50, 250 },
+ .lpdiv =
[PATCH V2 6/6] 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, num_reg_fields and dss_params 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 | 96
drivers/video/omap2/dss/dss_features.h | 12
3 files changed, 16 insertions(+), 114 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 6ca69d5..ef005e2 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 omapdss_reg_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..e7fca28 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -27,19 +27,7 @@
#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
Re: [PATCH v4 0/8] crypto: omap-sham updates
Hello, I am not working on OMAP anymore and not able to test anything. But in general changes are OK for me. - Dmitry On Mon, Nov 19, 2012 at 8:54 PM, Mark A. Greer mgr...@animalcreek.com wrote: From: Mark A. Greer mgr...@animalcreek.com Changes since v3: - Added hwmod support for SIDLEMODE. This requires adding a specific omap_hwmod_sysc_fields structure since there are not generic ones that have the correct offsets. - Added patch to remove the cpu check from the omap-sham driver. This can likely be ignored since there is a patch that already does this in Tony's branch. I added it to make it easier for others to test while Tony's patch makes its way to the k.o. Changes since v2: - Reworked pm_runtime calls to match where original clk_* calls were so provide better PM (as per Kevin Hilman's comments). Changes since v1: - Removed the check of CM_IDLEST to see if the module exists and instead add the hwmod data for all omap2's and omap3 GP's. - Placed new sha_ick clk entries after the 'omap-sham' entry in the clockxxx_data.c files - Removed cpu_is_xxx() checks in arch/arm/mach-omap2/devices.c:omap_init_sham() - Rebased on the latest k.o. kernel This series updates the crypto omap-sham driver and supporting infrastructure. Notes: a) Based on 3587b1b (fanotify: fix FAN_Q_OVERFLOW case of fanotify_read()). b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 5-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. If you have different hardware available and a few minutes, please test them. A quick and easy test is to enable tcrypt as a module (CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'. 'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be enabled. A quick 'grep omap-sham /proc/interrupts' will tell you if the omap-sham driver was really used. d) To test these patches, you will likely need... i) The patch included here: http://marc.info/?l=kernel-janitorsm=134910841909057w=2 ii) This patch from linux-omap/master: 27615a9 (ARM: OMAP: Trivial driver changes to remove include plat/cpu.h) iii) This patch from Paul Walmsley: http://www.spinics.net/lists/linux-omap/msg79436.html e) If you prefer, a version you can test is available at g...@github.com:mgreeraz/linux-mag.git wip/crypto/sham-v3+test f) There is a reduction in DMA performance after switching to dmaengine (see http://www.spinics.net/lists/linux-omap/msg79855.html) g) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (8): ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no SHA IP is present crypto: omap-sham: Remove cpu_is/omap_type check from driver crypto: omap-sham: Convert to use pm_runtime API crypto: omap-sham: Add code to use dmaengine API crypto: omap_sham: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 73 ++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 43 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 66 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-sham.c | 202 +++-- 10 files changed, 251 insertions(+), 157 deletions(-) -- 1.7.12 -- 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 0/7] crypto: omap-aes updates
Hello, I am not working on OMAP anymore and not able to test anything. But in general changes are OK for me. - Dmitry On Tue, Nov 20, 2012 at 2:08 PM, Kasatkin, Dmitry dmitry.kasat...@intel.com wrote: Great. You also worked on AES... Will take a loos asap. On Mon, Nov 19, 2012 at 9:03 PM, Mark A. Greer mgr...@animalcreek.com wrote: From: Mark A. Greer mgr...@animalcreek.com This series updates the crypto omap-aes driver and supporting infrastructure. Notes: a) Based on omap-sham patches recently submitted, XXX b) Since these patches will likely go though the OMAP tree (and not through the crypto tree), it would be nice if the crypto guy(s) would ACK or NACK patches 4-7 which modify the drivers/crypto/omap-sham.c driver. c) These have only been tested on an omap2420 h4 and an am37x evm. d) Many thanks to Jon Hunter for testing on his omap2420 h4. Mark A. Greer (7): ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no AES IP is present crypto: omap-aes: Remove cpu_is/omap_type check from driver crypto: omap-aes: Convert to use pm_runtime API crypto: omap-aes: Add code to use dmaengine API crypto: omap-aes: Remove usage of private DMA API arch/arm/mach-omap2/clock2430_data.c | 1 + arch/arm/mach-omap2/clock3xxx_data.c | 1 + arch/arm/mach-omap2/devices.c | 75 +--- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 38 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 +++ arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 + drivers/crypto/omap-aes.c | 202 - 10 files changed, 251 insertions(+), 150 deletions(-) -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] mtd: nand: omap2: Update nerrors using ecc.strength
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro definitions BCH8_ERROR_MAX BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors was
incorrect? Was it causing any issues in any particular configuration?
Mentioning this will help maintainers assign priority to your patch. If
this is a real bug affecting existing platforms, then there is a chance
this patch can get into v3.7 (or at least into v3.8-rc1).
Like Peter who commented on this before, I am not a fan of using macros
for self-describing constants - especially when you end up using the
same numbers inside the macro name itself. No need to resend any thing
just for this, you can wait to see if the maintainers are okay with it.
Thanks,
Sekhar
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 359293e... 7e61dac... Mdrivers/mtd/nand/omap2.c
drivers/mtd/nand/omap2.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 359293e..7e61dac 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -118,6 +118,9 @@
#define OMAP24XX_DMA_GPMC4
+#define BCH8_MAX_ERROR 8 /* upto 8 bit correctable */
+#define BCH4_MAX_ERROR 4 /* upto 4 bit correctable */
+
/* oob info generated runtime depending on ecc algorithm and layout selected
*/
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -1042,7 +1045,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
struct nand_chip *chip = mtd-priv;
u32 val;
- nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
+ nerrors = info-nand.ecc.strength;
dev_width = (chip-options NAND_BUSWIDTH_16) ? 1 : 0;
nsectors = 1;
/*
@@ -1219,13 +1222,14 @@ static int omap3_init_bch(struct mtd_info *mtd, int
ecc_opt)
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
#ifdef CONFIG_MTD_NAND_OMAP_BCH8
- const int hw_errors = 8;
+ const int hw_errors = BCH8_MAX_ERROR;
#else
- const int hw_errors = 4;
+ const int hw_errors = BCH4_MAX_ERROR;
#endif
info-bch = NULL;
- max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ? 8 : 4;
+ max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ?
+ BCH8_MAX_ERROR : BCH4_MAX_ERROR;
if (max_errors != hw_errors) {
pr_err(cannot configure %d-bit BCH ecc, only %d-bit supported,
max_errors, hw_errors);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/3] mtd: nand: omap2: Update nerrors using ecc.strength
On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote:
Hi Avinash,
On 11/29/2012 5:16 PM, Philip, Avinash wrote:
Update number of errors using nand ecc strength.
Also add macro definitions BCH8_ERROR_MAX BCH4_ERROR_MAX
Can you please describe why the original method of setting nerrors was
incorrect? Was it causing any issues in any particular configuration?
It affects the reusability of the code. For example BCH8 with AM335x RBL
compatibility requires 14 bytes instead of 13 byte. So setting nerrors
with
nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
will break am335x RBL compatibility.
Mentioning this will help maintainers assign priority to your patch. If
this is a real bug affecting existing platforms, then there is a chance
this patch can get into v3.7 (or at least into v3.8-rc1).
Like Peter who commented on this before, I am not a fan of using macros
for self-describing constants - especially when you end up using the
same numbers inside the macro name itself. No need to resend any thing
just for this, you can wait to see if the maintainers are okay with it.
Yes I agree. But the same constants are used in multiple places here.
So usage of macro helps in readability code debugging.
Thanks
Avinash
Thanks,
Sekhar
Signed-off-by: Philip, Avinash avinashphi...@ti.com
---
:100644 100644 359293e... 7e61dac... M drivers/mtd/nand/omap2.c
drivers/mtd/nand/omap2.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 359293e..7e61dac 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -118,6 +118,9 @@
#define OMAP24XX_DMA_GPMC 4
+#define BCH8_MAX_ERROR 8 /* upto 8 bit correctable */
+#define BCH4_MAX_ERROR 4 /* upto 4 bit correctable */
+
/* oob info generated runtime depending on ecc algorithm and layout
selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -1042,7 +1045,7 @@ static void omap3_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
struct nand_chip *chip = mtd-priv;
u32 val;
- nerrors = (info-nand.ecc.bytes == 13) ? 8 : 4;
+ nerrors = info-nand.ecc.strength;
dev_width = (chip-options NAND_BUSWIDTH_16) ? 1 : 0;
nsectors = 1;
/*
@@ -1219,13 +1222,14 @@ static int omap3_init_bch(struct mtd_info *mtd, int
ecc_opt)
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
#ifdef CONFIG_MTD_NAND_OMAP_BCH8
- const int hw_errors = 8;
+ const int hw_errors = BCH8_MAX_ERROR;
#else
- const int hw_errors = 4;
+ const int hw_errors = BCH4_MAX_ERROR;
#endif
info-bch = NULL;
- max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ? 8 : 4;
+ max_errors = (ecc_opt == OMAP_ECC_BCH8_CODE_HW) ?
+ BCH8_MAX_ERROR : BCH4_MAX_ERROR;
if (max_errors != hw_errors) {
pr_err(cannot configure %d-bit BCH ecc, only %d-bit supported,
max_errors, hw_errors);
Re: [PATCH v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM, Daniel Mack wrote:
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;
}
Sorry I should have seen this earlier. Ideally, this type of thing
should be reflected by the device-tree/platform-data and we should get
away from these cpu_is_ macros for hardware features (where we can).
Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
the single zImage work (I see the omap nand driver is including gpmc.h).
Tony, should this be addressed now or can we live this for the minute
and fix-up later?
Actually, I see that you do read the ecc mode from DT, so is this really
needed? It would be good to eliminate this.
The ecc mode is read from DT, right. But the gpmc bindings can be used
for many OMAP derivates in the future, and this check is there to make
sure the configured settings are supported by the hardware after all,
just like if the ecc mode would have been passed as static platform
data. So what is it exactly that you want to get rid of?
The above function.
If there is a hardware bug that prevents us from using the hw-ecc mode
that is supported (which is the case for omap3630 es1.0), then we should
have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
flags should be populated at probe.
I agree though that we could solve this with via the of_device_id's data
pointer of the matching driver. But as you said yourself, this can well
be done later, and the problem here is that we still need the
cpu_is_xxx() macros for older platforms, right?
Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
driver code. Ok, here we can calling a platform function that is calling
the macro, but for single zImage we cannot do that either. We cannot
include platform headers in drivers for single zImage. We have to get
away from that. Therefore, such information needs to be passed by
platform data, device tree, etc.
I will let Tony decide on how he wants us to handle this.
Any idea yet about this detail? The other small Documentation changes
you brought up are fixed in my tree and ready for resubmission.
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
Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
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 | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ 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, 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
- failed error:%d\n, ret);
+ dev_dbg(dev, xclk60mhsp1_ck set parent failed : %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
- failed error:%d\n, ret);
+ dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
- dev_err(dev, xclk60mhsp2_ck set parent
- failed error:%d\n, ret);
+ dev_dbg(dev, xclk60mhsp2_ck set parent failed : %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
- failed error:%d\n, ret);
+ dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/23] mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path
Hello.
On 04-12-2012 18:12, Roger Quadros wrote:
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 e67cafc..828207f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
[...]
@@ -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;
- }
Not clear why you removed the error check...
-
- 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;
Why you changed this from ENOMEM?
WBR, Sergei
--
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
Hi Jassi, On 12/01/2012 09:49 AM, Jassi Brar wrote: On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: We should have a more generic solution in a more central location, like the device core. For example, each struct platform_device could have a list of resources to be enabled when the device is bound to a driver and disabled when the device is unbound. Such a list could include regulators, clocks, and whatever else people can invent. In this case, when it is created the ehci-omap.0 platform device could get an entry pointing to the LAN95xx's regulator. Then the regulator would automatically be turned on when the platform device is bound to the ehci-omap driver. How does this sound? That sounds much better, and it might come in handy for other types of devices than platform devices, so feel free to put this on the core 'struct device' instead if needed. Isn't enabling/disabling of clocks and regulators what dev.probe()/remove() of any driver already does? If we mean only board specific setup/teardown, still it would mean having the device core to do an extra 'probe' call when the current probe() is already meant to do whatever it takes to bring the device up. To my untrained eyes, it seem like messing with the probe()/remove()'s semantics. IMHO, if we really must implement something like that, may be we should employ some 'broadcast mechanism' so that anything anywhere in kernel knows which new device has been probed()/removed() successfully. I haven't thought exactly how because I am not sure even that would be the right way to approach PandaBoard's problem. Looking at Figure 15 – Panda USBB1 Interface Block Diagram of http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf gives me visions ... 1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So we should have a platform device for USB3320C, the probe() of which should simply Actually the EHCI controller within OMAP provides the root hub with 3 ports but no PHY. One of them is connected to the USB3320 which is just a ULPI PHY. a) Enable REFCLK (FREF_CLK3_OUT) b) Reset itself by cycling RESETB (GPIO_62) c) Create one ehci-omap platform device c) is not appropriate. ehci-omap must be created before usb3320. (or in appropriate order if the above isn't) That way insmod/rmmod'ing the USB3320C driver would power-up/down the whole subsystem. Yes, this is where we can think of a generic PHY driver to make sure thy PHY has necessary resources enabled. In the Panda case it would be the PHY clock and RESET gpio. The LAN95xx chip still needs to be powered up and the PHY driver isn't the right place for that (though it could be done there as a hack). The closest we can get to emulating right USB behavior is to map the SET/CLEAR PORT_FEATURE of the root hub port to the regulator that powers the LAN95xx. This way, we still don't fall in the dynamically probed space, so we could still provide the regulator information to the ehci hub via platform data and handle the regulator in ehci_hub_control (Set/ClearPortFeature). I'm looking at this as a software workaround for all platforms not implementing the EHCI set port power feature correctly. The same could be repeated for other HCDs as well if required. 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
Re: [PATCH v3 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On 12/05/2012 03:42 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:31, Roger Quadros wrote:
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 | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..e5257dc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ 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, 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
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp1_ck set parent failed : %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
-failed error:%d\n, ret);
+dev_dbg(dev, P0 init_60m_fclk set parent failed: %d\n,
+ret);
}
if (is_ehci_phy_mode(pdata-port_mode[1])) {
ret = clk_set_parent(omap-utmi_clk[1],
omap-xclk60mhsp2_ck);
if (ret != 0)
-dev_err(dev, xclk60mhsp2_ck set parent
-failed error:%d\n, ret);
+dev_dbg(dev, xclk60mhsp2_ck set parent failed : %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
-failed error:%d\n, ret);
+dev_dbg(dev, P1 init_60m_fclk set parent failed: %d\n,
+ret);
Hm, you sometimes put a space before colon in the error message and
sometimes not. Inconsistent. :-)
That was because it fit in 80 characters without the space. I'm not sure
what is more important, fitting in 80 or consistency in the print
message. Maybe i should have removed the spaces everywhere so that it is
consistent as well. :)
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
Re: [PATCH v3 04/23] mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path
On 12/05/2012 04:08 PM, Sergei Shtylyov wrote:
Hello.
On 04-12-2012 18:12, Roger Quadros wrote:
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 e67cafc..828207f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
[...]
@@ -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;
-}
Not clear why you removed the error check...
It is because devm_request_and_ioremap does it for you.
http://lxr.free-electrons.com/source/lib/devres.c#L88
-
-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;
Why you changed this from ENOMEM?
as per the documentation for devm_request_and_ioremap() in the
same link I sent above.
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
Re: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is created?
Currently what I have (this is before changing it to pm domain, but this
should be unchanged) lets the asset define a callback op which will
receive notifications for all added child devices that have the device
the asset is bound to as an ancestor.
So you would bind an asset to the host controller device...
static struct device_asset assets_ehci_omap0[] = {
{
.name = -0:1.0/port1,
.asset = assets_ehci_omap0_smsc_port,
.ops = device_descendant_attach_default_asset_ops,
},
{ }
};
...with this descendant filter callback pointing to a generic end of
the device path matcher.
when device_descendant_attach_default_asset_ops() sees the child that
was foretold has appeared (and it only hears about children of
ehci-omap.0 in this case), it binds the assets pointed to by .asset to
the new child before its probe. assets_ehci_omap0_smsc_port is an array
of the actual regulator and clock that need switching by the child. So
the effect is to magic the right assets to the child device just before
it gets added (and probe called etc).
This is working well and the matcher helper is small and simple.
Right. The question is should it be done in this somewhat roundabout
way (you've got two separate assets for setting up this one thing), or
should the USB port code be responsible for explicitly checking if
there are any applicable assets when the port is created?
The advantange of the second approach is that it doesn't involve
checking all the ancestors every time a new device is added (and it
involves only one asset). The disadvantage is that it works only for
USB ports.
To answer the question, we need to know how other subsystems might
want to use the asset-matching approach. My guess is that only a small
number of device types would care about assets (in the same way that
assets matter to USB ports but not to other USB device types). And it
might not be necessary to check against every ancestor; we might know
beforehand where to check (just as the USB port would know to look for
an asset attached to the host controller device).
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: [RFC PATCH 1/5] Device Power: introduce power controller
On 12/03/2012 05:00 AM, Ming Lei wrote: On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote: On 02/12/12 23:01, the mail apparently from Ming Lei included: Power controller is an abstract on simple power on/off switch. One power controller can bind to more than one device, which provides power logically, for example, we can think one usb port in hub provides power to the usb device attached to the port, even though the power is supplied actually by other ways, eg. the usb hub is a self-power device. From hardware view, more than one device can share one power domain, and power controller can power on if one of these devices need to provide power, and power off if all these devices don't need to provide power. What stops us using struct regulator here? If you have child regulators supplied by a parent supply, isn't that the right semantic already without introducing a whole new thing? Apologies if I missed the point. There are two purposes: One is to hide the implementation details of the power controller because the user doesn't care how it is implemented, maybe clock, regulator, gpio and other platform dependent stuffs involved, so the patch simplify the usage from the view of users. Which user are you talking about? AFAIK for Panda we only need a regulator and a clock for each root port. IMHO we should just use the existing regulator and clock frameworks. Another is that several users may share one power controller, and the introduced power controller can help users to use it. True. e.g. the same regulator could be used to power 3 root hub ports in a ganged setup. But the regulator framework is sufficient to deal with that. Each port will call regulator_get() and regulator_enable() and the physical regulator won't be disabled till all of them have called regulator_disable(). 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
Re: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices
Hi,
* Ming Lei tom.leim...@gmail.com [121202 07:05]:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
...
+
+static struct notifier_block usb_port_nb = {
+ .notifier_call = device_notify,
+};
+
We'll be flipping omap4 over to be device tree only soon.
So let's not make the conversion more complex by adding more
platform code.
This means that for am33xx, omap4, and omap5 this code
can be device tree only code.
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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
* Daniel Mack zon...@gmail.com [121205 05:07]:
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM, Daniel Mack wrote:
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;
}
Sorry I should have seen this earlier. Ideally, this type of thing
should be reflected by the device-tree/platform-data and we should get
away from these cpu_is_ macros for hardware features (where we can).
Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
the single zImage work (I see the omap nand driver is including gpmc.h).
Tony, should this be addressed now or can we live this for the minute
and fix-up later?
Actually, I see that you do read the ecc mode from DT, so is this really
needed? It would be good to eliminate this.
The ecc mode is read from DT, right. But the gpmc bindings can be used
for many OMAP derivates in the future, and this check is there to make
sure the configured settings are supported by the hardware after all,
just like if the ecc mode would have been passed as static platform
data. So what is it exactly that you want to get rid of?
The above function.
If there is a hardware bug that prevents us from using the hw-ecc mode
that is supported (which is the case for omap3630 es1.0), then we should
have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
flags should be populated at probe.
I agree though that we could solve this with via the of_device_id's data
pointer of the matching driver. But as you said yourself, this can well
be done later, and the problem here is that we still need the
cpu_is_xxx() macros for older platforms, right?
Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
driver code. Ok, here we can calling a platform function that is calling
the macro, but for single zImage we cannot do that either. We cannot
include platform headers in drivers for single zImage. We have to get
away from that. Therefore, such information needs to be passed by
platform data, device tree, etc.
I will let Tony decide on how he wants us to handle this.
Any idea yet about this detail? The other small Documentation changes
you brought up are fixed in my tree and ready for resubmission.
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.
For legacy booting systems, this flag should be just passed in the
platform_data from the platform init code. Then device tree can
deal with it based on the compatible flag.
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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
Hi Tony,
On 05.12.2012 18:19, Tony Lindgren wrote:
* Daniel Mack zon...@gmail.com [121205 05:07]:
On 29.11.2012 21:59, Jon Hunter wrote:
On 11/29/2012 02:42 PM, Daniel Mack wrote:
On 29.11.2012 21:32, Jon Hunter wrote:
On 11/29/2012 01:59 PM, Jon Hunter wrote:
On 11/29/2012 10:01 AM, Daniel Mack wrote:
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;
}
Sorry I should have seen this earlier. Ideally, this type of thing
should be reflected by the device-tree/platform-data and we should get
away from these cpu_is_ macros for hardware features (where we can).
Furthermore, we need to avoid including plat-omap/gpmc.h in drivers for
the single zImage work (I see the omap nand driver is including gpmc.h).
Tony, should this be addressed now or can we live this for the minute
and fix-up later?
Actually, I see that you do read the ecc mode from DT, so is this really
needed? It would be good to eliminate this.
The ecc mode is read from DT, right. But the gpmc bindings can be used
for many OMAP derivates in the future, and this check is there to make
sure the configured settings are supported by the hardware after all,
just like if the ecc mode would have been passed as static platform
data. So what is it exactly that you want to get rid of?
The above function.
If there is a hardware bug that prevents us from using the hw-ecc mode
that is supported (which is the case for omap3630 es1.0), then we should
have a GPMC_ERRATA_xxx flag somewhere to indicate this and these errata
flags should be populated at probe.
I agree though that we could solve this with via the of_device_id's data
pointer of the matching driver. But as you said yourself, this can well
be done later, and the problem here is that we still need the
cpu_is_xxx() macros for older platforms, right?
Yes, but we cannot/shouldn't use these cpu_is_xxx macros from within
driver code. Ok, here we can calling a platform function that is calling
the macro, but for single zImage we cannot do that either. We cannot
include platform headers in drivers for single zImage. We have to get
away from that. Therefore, such information needs to be passed by
platform data, device tree, etc.
I will let Tony decide on how he wants us to handle this.
Any idea yet about this detail? The other small Documentation changes
you brought up are fixed in my tree and ready for resubmission.
The plat/cpu.h file will disappear after the merge window, which means
omap2+ related drivers cannot use cpu_is_omap macros.
For legacy booting systems, this flag should be just passed in the
platform_data from the platform init code. Then device tree can
deal with it based on the compatible flag.
Ok, thanks for explaining.
Does that mean this patch series should be postponed until after the
merge window and then build upon that change or should we merge the
patch in question here as is and then care for the cleanups after the
window?
I can also rebase this set on top of the removal patches if they exist
already somewhere.
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
Re: [PATCH v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
* Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. I can also rebase this set on top of the removal patches if they exist already somewhere. ..please check that your patches work with current linux next. It's too late to queue thing for v3.8 merge window at this point, as we want the patches sitting in linux next for a week at least before they get pulled. And we still need the acks for the device tree binding as well. So let's plan on queueing these after -rc1. 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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On 12/05/2012 11:41 AM, Tony Lindgren wrote: * Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. The real problem here is that drivers/mtd/nand/omap2.c is including plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So although Daniel's patches are not introducing any new problems for single zImage, they do highlight a problem that we have with the omap2 nand driver that needs to be addressed for single zImage. So either we fix this now or after merging Daniel's changes. Either is fine with me. 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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
* Jon Hunter jon-hun...@ti.com [121205 10:22]: On 12/05/2012 11:41 AM, Tony Lindgren wrote: * Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. The real problem here is that drivers/mtd/nand/omap2.c is including plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So although Daniel's patches are not introducing any new problems for single zImage, they do highlight a problem that we have with the omap2 nand driver that needs to be addressed for single zImage. So either we fix this now or after merging Daniel's changes. Either is fine with me. Ah I see. Yes it would be good to fix that issue first to avoid adding any new blockers for multiplatform build. 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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On 05.12.2012 19:33, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121205 10:22]: On 12/05/2012 11:41 AM, Tony Lindgren wrote: * Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. The real problem here is that drivers/mtd/nand/omap2.c is including plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So although Daniel's patches are not introducing any new problems for single zImage, they do highlight a problem that we have with the omap2 nand driver that needs to be addressed for single zImage. So either we fix this now or after merging Daniel's changes. Either is fine with me. Ah I see. Yes it would be good to fix that issue first to avoid adding any new blockers for multiplatform build. Already fixed by Afzal here: https://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=2ef9f3dd ... which is also in linux-next. 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
Re: [PATCH v3 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
* Roger Quadros rog...@ti.com [121204 06:15]:
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.
Thanks for moving this one earlier in the series. Looks like
you're missing Samuel as the MFD maintainer from your cc.
You should resend again with Samuel Ortiz sa...@linux.intel.com
added.
Maybe check the patches in this series with scripts/get_maintainer.pl
to see who all should be cc:ed?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,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/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,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]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,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;
};
/*-*/
--
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 v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On 05.12.2012 18:41, Tony Lindgren wrote: * Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. I can also rebase this set on top of the removal patches if they exist already somewhere. ..please check that your patches work with current linux next. It's too late to queue thing for v3.8 merge window at this point, as we want the patches sitting in linux next for a week at least before they get pulled. And we still need the acks for the device tree binding as well. Ok, I'll resubmit a v7 with the nits fixed that Jon pointed out, and then hope for the maintainer's Acks. So let's plan on queueing these after -rc1. No problem really. The only thing is that I'll be on vacation when the merge window closes, hence I'd appreciate if you could already queue them up on your side, so they'll be taken care for :) 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 v7 1/5] ARM: OMAP: gpmc: don't create devices from initcall on DT
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65468f6..d5cbd29 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1214,6 +1214,13 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = gpmc;
+ /*
+* if the board boots up with a populated DT, do not
+* manually add the device from this initcall
+*/
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err(Could not look up %s\n, oh_name);
--
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 v7 0/5] OMAP GPMC DT bindings
This is a series of patches to support GPMC peripherals on OMAP boards. Grant, Rob, could you have a look and give your Acked-by if appropriate? Many thanks again, Daniel Tested on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) Generated from linux-next as of today, resolving one trivial include file rebase conflict. 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 Version 6: - Dropped bch8-am335xrbl-compatible mode again. As discussed with Avinash, the ELM issue will be solved subsequently in s separate series. - re-added a patch to bail out of automatic GPMC instanciation in case of DT boot. - re-added the of_node addition in mtd_nand_omap2.h in 2/5 Version 7: comments from Jon Hunter, all affecting the documentation: - add num-wait pins properties as they are marked 'required' - make reg sizes consistent - AM335x only has 2 wait-pins Again, many thanks to everybody, in particular Avinash, for the long disussion about how to the these details right in the first place. Daniel Daniel Mack (5): ARM: OMAP: gpmc: don't create devices from initcall on DT 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 | 76 + arch/arm/mach-omap2/gpmc-nand.c| 15 +- arch/arm/mach-omap2/gpmc.c | 178 - drivers/mtd/nand/omap2.c | 4 +- include/linux/platform_data/mtd-nand-omap2.h | 4 +- 6 files changed, 343 insertions(+), 10 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 v7 4/5] 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 3059f5e..afc1e8c 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 v7 2/5] 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 +++-
include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0002d5e..1d333497c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1332,6 +1332,7 @@ static int 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) {
@@ -1557,7 +1558,8 @@ static int 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);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..6bf9ef4 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
-};
+ /* for passing the partitions */
+ struct device_node *of_node;
+};
#endif
--
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 v7 5/5] 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 | 77 ++
.../devicetree/bindings/mtd/gpmc-nand.txt | 76 +
arch/arm/mach-omap2/gpmc.c | 171 -
3 files changed, 323 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..7d2a645
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,77 @@
+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 applicable to OMAP3+ and AM335x:
+ - 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;
+ num-waitpins = 2;
+ #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..b3fafb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,76 @@
+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
[PATCH v7 3/5] 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 db969a5..3059f5e 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
Re: [PATCH v6 4/5] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
On 12/05/2012 12:40 PM, Daniel Mack wrote: On 05.12.2012 19:33, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121205 10:22]: On 12/05/2012 11:41 AM, Tony Lindgren wrote: * Daniel Mack zon...@gmail.com [121205 09:29]: On 05.12.2012 18:19, Tony Lindgren wrote: The plat/cpu.h file will disappear after the merge window, which means omap2+ related drivers cannot use cpu_is_omap macros. For legacy booting systems, this flag should be just passed in the platform_data from the platform init code. Then device tree can deal with it based on the compatible flag. Ok, thanks for explaining. Does that mean this patch series should be postponed until after the merge window and then build upon that change or should we merge the patch in question here as is and then care for the cleanups after the window? Well to me it seems that you only have cpu_is_omap usage in arch/arm/mach-omap2/gpmc-nand.c, which will be OK. Only the code under drivers/* needs to be fixed for that. So your patches may be OK, but.. The real problem here is that drivers/mtd/nand/omap2.c is including plat/gpmc.h and calling a function in arch/arm/mach-omap/gpmc-nand.c. So although Daniel's patches are not introducing any new problems for single zImage, they do highlight a problem that we have with the omap2 nand driver that needs to be addressed for single zImage. So either we fix this now or after merging Daniel's changes. Either is fine with me. Ah I see. Yes it would be good to fix that issue first to avoid adding any new blockers for multiplatform build. Already fixed by Afzal here: https://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=2ef9f3dd ... which is also in linux-next. Great! So we can drop this change. 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 v7 0/5] OMAP GPMC DT bindings
On 12/05/2012 01:09 PM, Daniel Mack wrote: This is a series of patches to support GPMC peripherals on OMAP boards. Grant, Rob, could you have a look and give your Acked-by if appropriate? Many thanks again, Daniel Tested on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) Generated from linux-next as of today, resolving one trivial include file rebase conflict. 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 Version 6: - Dropped bch8-am335xrbl-compatible mode again. As discussed with Avinash, the ELM issue will be solved subsequently in s separate series. - re-added a patch to bail out of automatic GPMC instanciation in case of DT boot. - re-added the of_node addition in mtd_nand_omap2.h in 2/5 Version 7: comments from Jon Hunter, all affecting the documentation: - add num-wait pins properties as they are marked 'required' - make reg sizes consistent - AM335x only has 2 wait-pins Again, many thanks to everybody, in particular Avinash, for the long disussion about how to the these details right in the first place. Daniel Daniel Mack (5): ARM: OMAP: gpmc: don't create devices from initcall on DT mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc-nand: drop __init annotation ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Do you still need patch #4 now? Can't we drop this? May be worth just including what is required for linux-next as this is 3.9 material. 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 v7 0/5] OMAP GPMC DT bindings
On 05.12.2012 20:22, Jon Hunter wrote: On 12/05/2012 01:09 PM, Daniel Mack wrote: This is a series of patches to support GPMC peripherals on OMAP boards. Grant, Rob, could you have a look and give your Acked-by if appropriate? Many thanks again, Daniel Tested on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) Generated from linux-next as of today, resolving one trivial include file rebase conflict. 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 Version 6: - Dropped bch8-am335xrbl-compatible mode again. As discussed with Avinash, the ELM issue will be solved subsequently in s separate series. - re-added a patch to bail out of automatic GPMC instanciation in case of DT boot. - re-added the of_node addition in mtd_nand_omap2.h in 2/5 Version 7: comments from Jon Hunter, all affecting the documentation: - add num-wait pins properties as they are marked 'required' - make reg sizes consistent - AM335x only has 2 wait-pins Again, many thanks to everybody, in particular Avinash, for the long disussion about how to the these details right in the first place. Daniel Daniel Mack (5): ARM: OMAP: gpmc: don't create devices from initcall on DT mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc-nand: drop __init annotation ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Do you still need patch #4 now? Can't we drop this? May be worth just including what is required for linux-next as this is 3.9 material. Well, yes, otherwise the driver init will bail of course, so I need it locally. Feel free to drop it when that's not needed at the time of merging the series, but for now I resubmitted everything you need to test and use these patches :) 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
OMAP baseline test results for v3.7-rc8
Here are some basic OMAP test results for Linux v3.7-rc8. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc8/20121204220128/ Passing tests - Boot to userspace (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone, 4460pandaes PM ret/off, suspend + dynamic idle (3/4): 3530es3beagle, 3730beaglexm, 37xxevm Failing tests: fixed by posted patches -- Boot tests: * 3730 Beagle XM: attempt to access beyond end of device - Not an OMAP-specific problem - Should be fixed by http://marc.info/?l=linux-kernelm=135458657217682w=2 Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 - http://marc.info/?l=linux-omapm=135274739624125w=2 Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC root - Due to missing MMC setup in board file Other: * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed - Unknown cause; could be due to the lack of hierarchical enable/disable in hwmod code - Jon Hunter reports this does not appear with the same X-loader/bootloader on his 4430ES2.3 Panda, so could be ES-level dependent Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test PM tests: * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not yet part of the automated test suite; cause unknown - Pending re-test vmlinux object size (delta in bytes from test_v3.7-rc7 (9489e9dcae718d5fde988e4a684a0f55b5f94d17)): text data bsstotal kernel -162400-1624 am33xx_only -128000-1280 n800_multi_omap2xxx -126400-1264 n800_only_a -150800-1508 omap1_defconfig -149200-1492 omap1_defconfig_1510innovator_only -152400-1524 omap1_defconfig_5912osk_only -176800-1768 omap2plus_defconfig -157600-1576 omap2plus_defconfig_2430sdp_only -170400-1704 omap2plus_defconfig_cpupm -170400-1704 omap2plus_defconfig_no_pm -170400-1704 omap2plus_defconfig_omap2_4_only -183200-1832 omap2plus_defconfig_omap3_4_only -12440 +68-1176 rmk_omap3430_ldp_allnoconfig -172800-1728 rmk_omap3430_ldp_oldconfig -12440 +68-1176 rmk_omap4430_sdp_allnoconfig -131200-1312 rmk_omap4430_sdp_oldconfig -- 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote:
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 | 77 ++
.../devicetree/bindings/mtd/gpmc-nand.txt | 76 +
arch/arm/mach-omap2/gpmc.c | 171
-
3 files changed, 323 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..7d2a645
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,77 @@
+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
Please, be specific. Use something like ti,am3340-gpmc or
ti,omap3430-gpmc. The compatible property is a list so that new
devices can claim compatibility with old. Compatible strings that are
overly generic are a pet-peave of mine.
+ - 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.
gpmc,num-cs
+ - num-waitpins: The maximum number of wait pins that controller can
+ support.
gpmc,num-waitpins
+ - 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.
The core linux code will use ranges to decode the reg property of child
devices, even if the gpmc driver doesn't use it, so the comment here is
misleading.
Otherwise the binding looks fine to me.
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..b3fafb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,76 @@
+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 properties:
+
+ - nand-bus-width: Set this numeric value to 16 if the hardware
+ is wired that way. If not specified, a bus
+ width of 8 is assumed.
+
+ - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
+
+ swSoftware method (default)
+ hwHardware method
+ hw-romcodegpmc hamming mode method romcode layout
+ bch4 4-bit BCH ecc code
+ bch8 8-bit BCH ecc code
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ num-cs = 8;
+ num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0
Re: [PATCH v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: 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 | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 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..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +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 Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Thanks 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] gpio: twl4030: Correct status reporting when the GPIO is used as output
On Wed, 5 Dec 2012 10:49:45 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote: When the GPIO is configured as output we need to read the GPIODATAOUT* register to get correct information. When the GPIO is output the GPIODATAIN* registers report 0 all the time (no feedback from output path). Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/gpio/gpio-twl4030.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c index 55b4fe4..e7aa620 100644 --- a/drivers/gpio/gpio-twl4030.c +++ b/drivers/gpio/gpio-twl4030.c @@ -191,13 +191,19 @@ static int twl4030_get_gpio_datain(int gpio) u8 d_bnk = gpio 3; u8 d_off = gpio 0x7; u8 base = 0; + int direction; int ret = 0; if (unlikely((gpio = TWL4030_GPIO_MAX) || !(gpio_usage_count BIT(gpio return -EPERM; - base = REG_GPIODATAIN1 + d_bnk; + direction = gpio_twl4030_read(REG_GPIODATADIR1 + d_bnk); + if (direction 0 (direction d_off) 0x1) + base = REG_SETGPIODATAOUT1 + d_bnk; + else + base = REG_GPIODATAIN1 + d_bnk; + This is probably quite expensive considering that reads need to go out the i2c bus. Things like the output state and the pin direction should be cached by the driver in its private data structure so that you don't add an additional i2c round trip. g. -- 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: 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 | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 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..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +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 Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. g. Thanks Jon ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
* Grant Likely grant.lik...@secretlab.ca [121205 15:26]: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: On 12/05/2012 04:22 PM, Grant Likely wrote: Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. The compatible property can also be used to figure out which ones need the workarounds in patch #4 of this series for the DT case. So we should be specific with the compatible. 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: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices
On 06/12/12 00:42, the mail apparently from Alan Stern included:
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is created?
Currently what I have (this is before changing it to pm domain, but this
should be unchanged) lets the asset define a callback op which will
receive notifications for all added child devices that have the device
the asset is bound to as an ancestor.
So you would bind an asset to the host controller device...
static struct device_asset assets_ehci_omap0[] = {
{
.name = -0:1.0/port1,
.asset = assets_ehci_omap0_smsc_port,
.ops = device_descendant_attach_default_asset_ops,
},
{ }
};
...with this descendant filter callback pointing to a generic end of
the device path matcher.
when device_descendant_attach_default_asset_ops() sees the child that
was foretold has appeared (and it only hears about children of
ehci-omap.0 in this case), it binds the assets pointed to by .asset to
the new child before its probe. assets_ehci_omap0_smsc_port is an array
of the actual regulator and clock that need switching by the child. So
the effect is to magic the right assets to the child device just before
it gets added (and probe called etc).
This is working well and the matcher helper is small and simple.
Right. The question is should it be done in this somewhat roundabout
way (you've got two separate assets for setting up this one thing), or
should the USB port code be responsible for explicitly checking if
there are any applicable assets when the port is created?
The advantange of the second approach is that it doesn't involve
checking all the ancestors every time a new device is added (and it
involves only one asset). The disadvantage is that it works only for
USB ports.
It's done in two steps to strongly filter candidate child devices
against being children of a known platform device. If you go around
that, you will be back to full device path matching with wildcards at
the USB child to determine if he is the one. So that's a feature not
an issue I think.
I can see doing it generically or not is equally a political issue as a
technical one, but I think if we bother to add this kind of support we
should prefer to do it generally. It's going to be about the same
amount of code.
As Tony Lindgren said, even board-omap4panda.c itself is deprecated, to
project platform info into USB stack you either have to add DT code into
usb stack then to go find things directly, or provide a generic
methodology like assets which have the dt bindings done outside of any
subsystem and apply their operations outside the subsystem too.
To answer the question, we need to know how other subsystems might
want to use the asset-matching approach. My guess is that only a small
number of device types would care about assets (in the same way that
assets matter to USB ports but not to other USB device types). And it
might not be necessary to check against every ancestor; we might know
beforehand where to check (just as the USB port would know to look for
an asset attached to the host controller device).
Yes I think it boils down to buses in general can benefit from this.
They're the thing that dynamically - later - create child devices you
might need to target with what was ultimately platform information.
On Panda the other bus thing that can benefit is the WLAN module on
SDIO. In fact that's a very illuminating case for your question above.
Faced with exactly the same problem, that they needed to project
platform info on to SDIO-probed device instance to tell it what clock
rate it had been given, they invented an api which you can see today in
board-omap4panda.c and other boards there, wl12xx_set_platform_data().
This is from board-4430sdp:
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};
...
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
You can find the other end of it here in
drivers/net/wireless/ti/wlcore/wl12xx_platform_data.c
static struct wl12xx_platform_data *platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
if (platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
if (!platform_data)
return -ENOMEM;
return 0;
}
when the driver for the device instance wants to get its platform data
it reads the static pointer via another api. Obviously if you want two
modules on your platform that's not so good.
I doubt that's the only SDIO device that wants to know platform info.
So I think by
Re: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices
Hi, Well, I'm not any less busy than yesterday, as it turns out, but I'm expecting that to continue tomorrow, so I may as well have a look at it now. :-) On Tuesday, December 04, 2012 12:10:32 PM Alan Stern wrote: [CC: list trimmed; the people who were on it should be subscribed to at least one of the lists anyway.] [...] Not only regulators involved, clock or other things might be involved too. Also the same power domain might be shared with more than one port, so it is better to introduce power domain to the problem. Looks generic_pm_domain is overkill, so I introduced power controller which only focuses on power on/off and being shared by multiple devices. Even though it is overkill, it may be better than introducing a new abstraction. After all, this is exactly the sort of thing that PM domains were originally created to handle. Rafael, do you have any advice on this? The generic_pm_domain structure is fairly complicated, there's a lot of code in drivers/base/power/domain.c (it's the biggest source file in its directory), and I'm not aware of any documentation. Yeah, documentation is missing, which obviously is my fault. That code is designed to cover the case in which multiple devices share a power switch that can be used to remove power from all of them at once (eg. through a register write). It also assumes that there will be a stop operation, such as disable clock, allowing each device in the domain to be put into a shallow low-power state (individually) without the necessity to save its state. Device states only have to be saved when the power switch is about to be used, which generally happens when they all have been stopped (their runtime PM status is RPM_SUSPENDED). The stop operation may be defined in a different way for each device in the domain (actually, that applies to the save state, restore state, and start - opposite to stop - operations too) and PM QoS latency constraints are used to decide if and when to turn the whole domain off. Moreover, it supports hierarchies of power domains that may be pretty much arbitarily complicated. A big part of this code is for the handling of system suspend/resume in such a way that it is consistent with runtime PM. For USB ports I'd recommend to use something simpler. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] Device Power: introduce power controller
On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros rog...@ti.com wrote: On 12/03/2012 05:00 AM, Ming Lei wrote: On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote: On 02/12/12 23:01, the mail apparently from Ming Lei included: Power controller is an abstract on simple power on/off switch. One power controller can bind to more than one device, which provides power logically, for example, we can think one usb port in hub provides power to the usb device attached to the port, even though the power is supplied actually by other ways, eg. the usb hub is a self-power device. From hardware view, more than one device can share one power domain, and power controller can power on if one of these devices need to provide power, and power off if all these devices don't need to provide power. What stops us using struct regulator here? If you have child regulators supplied by a parent supply, isn't that the right semantic already without introducing a whole new thing? Apologies if I missed the point. There are two purposes: One is to hide the implementation details of the power controller because the user doesn't care how it is implemented, maybe clock, regulator, gpio and other platform dependent stuffs involved, so the patch simplify the usage from the view of users. Which user are you talking about? Here it is the usb port device. At least, there are many boards which have hardwired and self-powered usb devices, so in theory they can benefits from the power controller. Maybe only regulator and clock can't be covered completely for other boards. The patch can make usb port deal with the 'power controller' only, and make it avoid to deal with regulators/clocks/... directly. 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: [RFC PATCH 1/5] Device Power: introduce power controller
On 6 December 2012 06:57, Ming Lei tom.leim...@gmail.com wrote: On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros rog...@ti.com wrote: On 12/03/2012 05:00 AM, Ming Lei wrote: On Mon, Dec 3, 2012 at 12:02 AM, Andy Green andy.gr...@linaro.org wrote: On 02/12/12 23:01, the mail apparently from Ming Lei included: Power controller is an abstract on simple power on/off switch. One power controller can bind to more than one device, which provides power logically, for example, we can think one usb port in hub provides power to the usb device attached to the port, even though the power is supplied actually by other ways, eg. the usb hub is a self-power device. From hardware view, more than one device can share one power domain, and power controller can power on if one of these devices need to provide power, and power off if all these devices don't need to provide power. What stops us using struct regulator here? If you have child regulators supplied by a parent supply, isn't that the right semantic already without introducing a whole new thing? Apologies if I missed the point. There are two purposes: One is to hide the implementation details of the power controller because the user doesn't care how it is implemented, maybe clock, regulator, gpio and other platform dependent stuffs involved, so the patch simplify the usage from the view of users. Which user are you talking about? Here it is the usb port device. At least, there are many boards which have hardwired and self-powered usb devices, so in theory they can benefits from the power controller. Maybe only regulator and clock can't be covered completely for other boards. The patch can make usb port deal with the 'power controller' only, and make it avoid to deal with regulators/clocks/... directly. I am curious too, except for clocks and voltage supplies (regulators), what other external resources does a chip need ? -- 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
