[PATCH V6 6/6] OMAPDSS: DPI: Remove cpu_is_xxxx checks
The OMAP3 checks have been removed and replaced by a dss feature
FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches
"OMAP: DSS2: enable VDDS_DSI when using DPI" (8a2cfea8cc) by Tomi Valkeinen
and "ARM: omap: fix oops in
drivers/video/omap2/dss/dpi.c" (4041071571) by Russell King
had introduced these checks. As it is evident
from these patches a dependency exists for some DSS pins on VDDS_DSI which is
better shown by dss feature FEAT_DPI_USES_VDDS_DSI.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dpi.c | 12 +++-
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/dss_features.h |1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index f260343..25fb895 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -34,6 +34,7 @@
#include
#include "dss.h"
+#include "dss_features.h"
static struct {
struct regulator *vdds_dsi_reg;
@@ -175,7 +176,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
mutex_lock(&dpi.lock);
- if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) && !dpi.vdds_dsi_reg) {
DSSERR("no VDSS_DSI regulator\n");
r = -ENODEV;
goto err_no_reg;
@@ -193,7 +194,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_start_dev;
}
- if (cpu_is_omap34xx()) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -239,7 +240,7 @@ err_dsi_pll_init:
err_get_dsi:
dispc_runtime_put();
err_get_dispc:
- if (cpu_is_omap34xx())
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -265,7 +266,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dispc_runtime_put();
- if (cpu_is_omap34xx())
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
regulator_disable(dpi.vdds_dsi_reg);
omap_dss_stop_device(dssdev);
@@ -362,7 +363,8 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
{
DSSDBG("init_display\n");
- if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL) {
+ if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
+ dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 9387097..2fe39d6 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -373,6 +373,7 @@ static const enum dss_feat_id omap3430_dss_feat_list[] = {
FEAT_ALPHA_FIXED_ZORDER,
FEAT_FIFO_MERGE,
FEAT_OMAP3_DSI_FIFO_BUG,
+ FEAT_DPI_USES_VDDS_DSI,
};
static const enum dss_feat_id omap3630_dss_feat_list[] = {
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 996ffcb..26d43a4 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -50,6 +50,7 @@ enum dss_feat_id {
FEAT_DSI_VC_OCP_WIDTH,
FEAT_DSI_REVERSE_TXCLKESC,
FEAT_DSI_GNQ,
+ FEAT_DPI_USES_VDDS_DSI,
FEAT_HDMI_CTS_SWMODE,
FEAT_HDMI_AUDIO_USE_MCLK,
FEAT_HANDLE_UV_SEPARATE,
--
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 V6 4/6] ARM: OMAP: Disable venc for OMAP4
This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash" (ba02fa37de) by Tomi Valkeinen to prevent
VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial registration
of a device for VENC on OMAP4.
Signed-off-by: Chandrabhanu Mahapatra
---
arch/arm/mach-omap2/display.c |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index af1ed7d..ee40739 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -95,7 +95,6 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ "dss_core", "omapdss_dss", -1 },
{ "dss_dispc", "omapdss_dispc", -1 },
{ "dss_rfbi", "omapdss_rfbi", -1 },
- { "dss_venc", "omapdss_venc", -1 },
{ "dss_dsi1", "omapdss_dsi", 0 },
{ "dss_dsi2", "omapdss_dsi", 1 },
{ "dss_hdmi", "omapdss_hdmi", -1 },
--
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 V6 5/6] OMAPDSS: VENC: Remove cpu_is_xxxx checks
OMAP4 checks are removed from VENC to provide it a cleaner interface. These
checks were introduced by patches "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4
to prevent crash" (ba02fa37de) by Tomi Valkeinen and
"OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on
OMAP4" (cc1d3e032d) by Danny Kukawka to prevent VENC
from crashing OMAP4 kernel.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/venc.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 7d3eef8..4a6caf9 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -674,11 +674,6 @@ static void venc_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, "%-35s %08x\n", #r, venc_read_reg(r))
- if (cpu_is_omap44xx()) {
- seq_printf(s, "VENC currently disabled on OMAP44xx\n");
- return;
- }
-
if (venc_runtime_get())
return;
@@ -893,16 +888,10 @@ static struct platform_driver omap_venchw_driver = {
int __init venc_init_platform_driver(void)
{
- if (cpu_is_omap44xx())
- return 0;
-
return platform_driver_probe(&omap_venchw_driver, omap_venchw_probe);
}
void __exit venc_uninit_platform_driver(void)
{
- if (cpu_is_omap44xx())
- return;
-
platform_driver_unregister(&omap_venchw_driver);
}
--
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 V6 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dss_init_features function providing a
much more generic and cleaner interface. The OMAP version and revision specific
initializations in various functions are cleaned and the necessary data are
moved to dss_features structure which is local to dss.c.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dss.c | 120 +++--
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index e2e0fa4..31a553a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
@@ -65,6 +66,12 @@ struct dss_reg {
static int dss_runtime_get(void);
static void dss_runtime_put(void);
+struct dss_features {
+ u8 fck_div_max;
+ u8 dss_fck_multiplier;
+ const char *clk_name;
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -83,6 +90,8 @@ static struct {
boolctx_valid;
u32 ctx[DSS_SZ_REGS / sizeof(u32)];
+
+ const struct dss_features *feat;
} dss;
static const char * const dss_generic_clk_source_names[] = {
@@ -91,6 +100,30 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_FCK] = "DSS_FCK",
};
+static const struct dss_features omap24xx_dss_feats __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = NULL,
+};
+
+static const struct dss_features omap34xx_dss_feats __initconst = {
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
+ .clk_name = "dpll4_m4_ck",
+};
+
+static const struct dss_features omap3630_dss_feats __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = "dpll4_m4_ck",
+};
+
+static const struct dss_features omap44xx_dss_feats __initconst = {
+ .fck_div_max= 32,
+ .dss_fck_multiplier = 1,
+ .clk_name = "dpll_per_m5x2_ck",
+};
+
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
{
__raw_writel(val, dss.base + idx.idx);
@@ -236,7 +269,6 @@ const char *dss_get_generic_clk_source_name(enum
omap_dss_clk_source clk_src)
return dss_generic_clk_source_names[clk_src];
}
-
void dss_dump_clocks(struct seq_file *s)
{
unsigned long dpll4_ck_rate;
@@ -259,18 +291,10 @@ void dss_dump_clocks(struct seq_file *s)
seq_printf(s, "dpll4_ck %lu\n", dpll4_ck_rate);
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- seq_printf(s, "%s (%s) = %lu / %lu = %lu\n",
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
- else
- seq_printf(s, "%s (%s) = %lu / %lu * 2 = %lu\n",
- fclk_name, fclk_real_name,
- dpll4_ck_rate,
- dpll4_ck_rate / dpll4_m4_ck_rate,
- fclk_rate);
+ seq_printf(s, "%s (%s) = %lu / %lu * %d = %lu\n",
+ fclk_name, fclk_real_name, dpll4_ck_rate,
+ dpll4_ck_rate / dpll4_m4_ck_rate,
+ dss.feat->dss_fck_multiplier, fclk_rate);
} else {
seq_printf(s, "%s (%s) = %lu\n",
fclk_name, fclk_real_name,
@@ -470,7 +494,7 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
unsigned long fck, max_dss_fck;
- u16 fck_div, fck_div_max = 16;
+ u16 fck_div;
int match = 0;
int min_fck_per_pck;
@@ -480,9 +504,8 @@ int dss_calc_clock_div(unsigned long req_pck, struct
dss_clock_info *dss_cinfo,
max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
fck = clk_get_rate(dss.dss_clk);
- if (req_pck == dss.cache_req_pck &&
- ((cpu_is_omap34xx() && prate == dss.cache_prate) ||
-dss.cache_dss_cinfo.fck == fck)) {
+ if (req_pck == dss.cache_req_pck && prate == dss.cache_prate &&
+ dss.cache_dss_cinfo.fck == fck) {
DSSDBG("dispc clock info found from cache.\n");
*dss_cinfo = dss.cache_dss_cinfo;
*dispc_cinfo = dss.cache_dispc_cinfo;
@@ -519,16 +542,10 @@ retry:
goto found;
} else {
- if (cpu_is_omap3630() || cpu_is_omap44xx())
-
[PATCH V6 2/6] OMAPDSS: DSS: Remove redundant functions
Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these
functions have become redundant and no longer used.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dss.c | 45 -
drivers/video/omap2/dss/dss.h |2 --
2 files changed, 47 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 92353be..e2e0fa4 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -431,31 +431,6 @@ enum omap_dss_clk_source dss_get_lcd_clk_source(enum
omap_channel channel)
}
}
-/* calculate clock rates using dividers in cinfo */
-int dss_calc_clock_rates(struct dss_clock_info *cinfo)
-{
- if (dss.dpll4_m4_ck) {
- unsigned long prate;
- u16 fck_div_max = 16;
-
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- fck_div_max = 32;
-
- if (cinfo->fck_div > fck_div_max || cinfo->fck_div == 0)
- return -EINVAL;
-
- prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
-
- cinfo->fck = prate / cinfo->fck_div;
- } else {
- if (cinfo->fck_div != 0)
- return -EINVAL;
- cinfo->fck = clk_get_rate(dss.dss_clk);
- }
-
- return 0;
-}
-
int dss_set_clock_div(struct dss_clock_info *cinfo)
{
if (dss.dpll4_m4_ck) {
@@ -478,26 +453,6 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
return 0;
}
-int dss_get_clock_div(struct dss_clock_info *cinfo)
-{
- cinfo->fck = clk_get_rate(dss.dss_clk);
-
- if (dss.dpll4_m4_ck) {
- unsigned long prate;
-
- prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
-
- if (cpu_is_omap3630() || cpu_is_omap44xx())
- cinfo->fck_div = prate / (cinfo->fck);
- else
- cinfo->fck_div = prate / (cinfo->fck / 2);
- } else {
- cinfo->fck_div = 0;
- }
-
- return 0;
-}
-
unsigned long dss_get_dpll4_rate(void)
{
if (dss.dpll4_m4_ck)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 41c00dc..d6cca82 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -296,9 +296,7 @@ void dss_set_venc_output(enum omap_dss_venc_type type);
void dss_set_dac_pwrdn_bgz(bool enable);
unsigned long dss_get_dpll4_rate(void);
-int dss_calc_clock_rates(struct dss_clock_info *cinfo);
int dss_set_clock_div(struct dss_clock_info *cinfo);
-int dss_get_clock_div(struct dss_clock_info *cinfo);
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo);
--
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 V6 1/6] OMAPDSS: DISPC: Cleanup cpu_is_xxxx checks
All the cpu_is checks have been moved to dispc_init_features function providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure which is
local to dispc.c.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/video/omap2/dss/dispc.c | 434 +--
1 file changed, 279 insertions(+), 155 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ff52702..0de9a7e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -81,6 +81,23 @@ struct dispc_irq_stats {
unsigned irqs[32];
};
+struct dispc_features {
+ u8 sw_start;
+ u8 fp_start;
+ u8 bp_start;
+ u16 sw_max;
+ u16 vp_max;
+ u16 hp_max;
+ int (*calc_scaling) (enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk);
+ unsigned long (*calc_core_clk) (enum omap_channel channel,
+ u16 width, u16 height, u16 out_width, u16 out_height);
+};
+
static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -101,6 +118,8 @@ static struct {
boolctx_valid;
u32 ctx[DISPC_SZ_REGS / sizeof(u32)];
+ const struct dispc_features *feat;
+
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
spinlock_t irq_stats_lock;
struct dispc_irq_stats irq_stats;
@@ -1939,7 +1958,18 @@ static unsigned long calc_core_clk_five_taps(enum
omap_channel channel,
return core_clk;
}
-static unsigned long calc_core_clk(enum omap_channel channel, u16 width,
+static unsigned long calc_core_clk_24xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (height > out_height && width > out_width)
+ return pclk * 4;
+ else
+ return pclk * 2;
+}
+
+static unsigned long calc_core_clk_34xx(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height)
{
unsigned int hf, vf;
@@ -1958,25 +1988,163 @@ static unsigned long calc_core_clk(enum omap_channel
channel, u16 width,
hf = 2;
else
hf = 1;
-
if (height > out_height)
vf = 2;
else
vf = 1;
- if (cpu_is_omap24xx()) {
- if (vf > 1 && hf > 1)
- return pclk * 4;
- else
- return pclk * 2;
- } else if (cpu_is_omap34xx()) {
- return pclk * vf * hf;
- } else {
- if (hf > 1)
- return DIV_ROUND_UP(pclk, out_width) * width;
- else
- return pclk;
+ return pclk * vf * hf;
+}
+
+static unsigned long calc_core_clk_44xx(enum omap_channel channel, u16 width,
+ u16 height, u16 out_width, u16 out_height)
+{
+ unsigned long pclk = dispc_mgr_pclk_rate(channel);
+
+ if (width > out_width)
+ return DIV_ROUND_UP(pclk, out_width) * width;
+ else
+ return pclk;
+}
+
+static int dispc_ovl_calc_scaling_24xx(enum omap_channel channel,
+ const struct omap_video_timings *mgr_timings,
+ u16 width, u16 height, u16 out_width, u16 out_height,
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim, int *decim_x, int *decim_y,
+ u16 pos_x, unsigned long *core_clk)
+{
+ 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);
+ *five_taps = false;
+
+ do {
+ in_height = DIV_ROUND_UP(height, *decim_y);
+ in_width = DIV_ROUND_UP(width, *decim_x);
+ *core_clk = dispc.feat->calc_core_clk(channel, in_width,
+ in_height, out_width, out_height);
+ error = (in_width > maxsinglelinewidth || !*core_clk ||
+ *core_clk > dispc_core_clk_rate());
+ if (error) {
+ if (*decim_x == *decim_y) {
+ *decim_x = min_factor;
+ ++*decim_y;
+ } else {
+ swap(*decim_x, *decim_y);
+ if (*decim_x < *decim_y)
+ ++*decim_x;
+ }
+ }
+ }
[PATCH V6 0/6] OMAPDSS: Cleanup cpu_is checks
Hi everyone, this patch series aims at cleaning up of DSS of cpu_is checks thereby making it more generic. The 1st patch cleans up cpu_is checks from DISPC code. The 2nd patch removes unused functions from DSS code. The 3rd patch cleans up cpu_is checks from DSS code. The 4th patch disables VENC support on OMAP4. The 5th patch removes cpu_is checks from VENC code. The 6th patch removes cpu_is checks from DPI code and replaces it with a dss feature. Changes from V1 to V5 series: 1st patch : * moved dispc_ops structure definitions from dss_features.c to dispc.c and renamed it to dispc_features * moved dispc_features definitions close to dispc_init_features() thereby eliminating various functions declarations from top of dispc.c * used __initconst before dispc_features definitions and __init before dispc_init_features() * removed definitions of _dispc_lcd_timings_ok_24xx, _dispc_lcd_timings_ok_44xx, _dispc_mgr_set_lcd_timings_hv_24xx and _dispc_mgr_set_lcd_timings_hv_44xx replacing them with appropiate variables * renamed various dispc_features structures to give consistent naming 3rd patch : * moved dss_ops structure definitions from dss_features.c to dss.c and renamed it to dss_features * removed all functions from dss_features structure and replaced them with appropiate variables * used __initconst before dss_features definitions and __init before dss_init_features() * renamed various dss_features structures to give consistent naming * renamed factor variable of dss_features structure to dss_fck_multiplier Changes from V5 to V6 series: * The "ARM: OMAP: Disable venc for OMAP4" patch has been placed before "OMAPDSS: VENC: Remove cpu_is_ checks" patch 1st patch: * The dispc_init_features() implementation has been corrected * The variables types of variables in dispc_features has been changed to u8 and u16 as found appropiate 2nd patch: * The dss_init_features() implementation has been corrected * In dss_features struct char * has been changed to const char * and int replaced with u8 All your comments and suggestions are welcome. Refenence Tree: g...@gitorious.org:~chandrabhanu/linux-omap-dss2/chandrabhanus-linux.git dss_cleanup Regards, Chandrabhanu Chandrabhanu Mahapatra (6): OMAPDSS: DISPC: Cleanup cpu_is_ checks OMAPDSS: DSS: Remove redundant functions OMAPDSS: DSS: Cleanup cpu_is_ checks ARM: OMAP: Disable venc for OMAP4 OMAPDSS: VENC: Remove cpu_is_ checks OMAPDSS: DPI: Remove cpu_is_ checks arch/arm/mach-omap2/display.c |1 - drivers/video/omap2/dss/dispc.c| 434 drivers/video/omap2/dss/dpi.c | 12 +- drivers/video/omap2/dss/dss.c | 165 ++-- drivers/video/omap2/dss/dss.h |2 - drivers/video/omap2/dss/dss_features.c |1 + drivers/video/omap2/dss/dss_features.h |1 + drivers/video/omap2/dss/venc.c | 11 - 8 files changed, 367 insertions(+), 260 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
Re: [PATCH 0/3] ARM: OMAP2/3: DSS HWMOD fixes
On Wed, 2012-07-04 at 06:11 -0600, Paul Walmsley wrote: > Hi Tomi > > On Wed, 27 Jun 2012, Paul Walmsley wrote: > > > On Thu, 10 May 2012, Tomi Valkeinen wrote: > > > > > These patches fix DSS hwmod data related to sysc flags. I haven't seen any > > > problem produced by these missing bits, but by looking at the TRM it's > > > clear > > > that they should be defined. > > > > > > However, applying these will cause additional warnings to show during > > > boot: > > > > > > omap_hwmod: dss_dispc: softreset failed (waited 1 usec) > > > omap_hwmod: dss_rfbi: softreset failed (waited 1 usec) > > > > > > Most likely the softreset fails even now, but as there's no check to > > > verify it, > > > no warnings are visible. > > > > > > I think the reason for the failing softreset is the same problem as we > > > have on > > > OMAP4: dss_core hwmod should be enabled before other dss hwmods can be > > > enabled > > > (and reset). > > > > Thanks, queued for 3.6. > > > > Not sure what to do about the softreset issues at the moment, due to > > competing priorities. But for sure the data should match the hardware. > > I've dropped these for 3.6 since they cause a PM regression during a > system suspend test: > > [ 39.721282] Powerdomain (dss_pwrdm) didn't enter target state 1 > > Probably before we can pull these in, we need to figure out what's going > on there. I was testing with omap3 overo, on v3.6-rc2 + git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc fixes-for-linus I don't seem to be able to enter full suspend even without dss. This is with DSS compiled as modules, and not loaded: # echo mem > /sys/power/state [ 21.697265] PM: Syncing filesystems ... done. [ 21.711059] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 21.740722] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 21.911407] PM: suspend of devices complete after 134.399 msecs [ 21.921874] PM: late suspend of devices complete after 4.150 msecs [ 21.934753] PM: noirq suspend of devices complete after 6.256 msecs [ 21.941467] Disabling non-boot CPUs ... [ 24.639495] Powerdomain (iva2_pwrdm) didn't enter target state 1 [ 24.645812] Powerdomain (dss_pwrdm) didn't enter target state 1 [ 24.652008] Powerdomain (per_pwrdm) didn't enter target state 1 [ 24.658233] Powerdomain (core_pwrdm) didn't enter target state 1 [ 24.664550] Powerdomain (usbhost_pwrdm) didn't enter target state 1 [ 24.671112] Could not enter target state in pm_suspend [ 24.679901] PM: noirq resume of devices complete after 3.173 msecs [ 24.691101] PM: early resume of devices complete after 2.716 msecs [ 25.086517] PM: resume of devices complete after 388.793 msecs [ 25.097564] Restarting tasks ... done. There's also still the old bug that happens if I have USB ethernet gadget as built-in: # echo mem > /sys/power/state [ 25.011657] PM: Syncing filesystems ... done. [ 25.026184] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 25.055145] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 25.086303] Suspending console(s) (use no_console_suspend to debug) [ 25.264953] PM: suspend of devices complete after 166.717 msecs [ 25.269348] PM: late suspend of devices complete after 4.394 msecs [ 25.275482] twl: i2c_read failed to transfer all messages [ 25.275543] twl: i2c_write failed to transfer all messages [ 25.275604] twl: i2c_write failed to transfer all messages [ 25.275634] [ cut here ] [ 25.275665] WARNING: at drivers/usb/otg/twl4030-usb.c:360 __twl4030_phy_power+0x88/0x98() [ 25.275665] Modules linked in: [ 25.275726] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c /0x64) [ 25.275756] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0 x1c/0x24) [ 25.275787] [] (warn_slowpath_null+0x1c/0x24) from [] (__twl4030_phy_power+0x 88/0x98) [ 25.275787] [] (__twl4030_phy_power+0x88/0x98) from [] (twl4030_phy_power+0x8 c/0xf4) [ 25.275817] [] (twl4030_phy_power+0x8c/0xf4) from [] (twl4030_phy_suspend.clo ne.7+0x18/0x44) [ 25.275848] [] (twl4030_phy_suspend.clone.7+0x18/0x44) from [] (twl4030_set_s uspend+0x1c/0x24) [ 25.275878] [] (twl4030_set_suspend+0x1c/0x24) from [] (omap2430_runtime_susp end+0x4c/0x54) [ 25.275909] [] (omap2430_runtime_suspend+0x4c/0x54) from [] (pm_generic_runti me_suspend+0x2c/0x40) [ 25.275939] [] (pm_generic_runtime_suspend+0x2c/0x40) from [] (_od_suspend_no irq+0x34/0x68) [ 25.275939] [] (_od_suspend_noirq+0x34/0x68) from [] (dpm_run_callback.clone. 10+0x30/0xb4) [ 25.275970] [] (dpm_run_callback.clone.10+0x30/0xb4) from [] (dpm_suspend_end +0x30c/0x514) [ 25.276000] [] (dpm_suspend_end+0x30c/0x514) from [] (suspend_devices_and_ent er+0xbc/0x2d0) [ 25.276031] [] (suspend_devices_and_enter+0xbc/0x2d0) from [] (pm_suspend+0x1 8c/0x208) [ 25.276031] [] (pm_suspend+0x18c/0x208) from [] (state_store+0x120/0x134)
[PATCHv2 1/3] spi: omap2-mcspi: Call pm_runtime_* functions directly
Call the pm_runtime functions directly making room for possible
pm optimisations. Also the runtime functions aren't just about
enabling and disabling of clocks though it does enable clocks also.
Acked-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/spi/spi-omap2-mcspi.c | 28 +++-
1 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..f542f3d 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -260,16 +260,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
list_for_each_entry(cs, &ctx->cs, node)
__raw_writel(cs->chconf0, cs->base + OMAP2_MCSPI_CHCONF0);
}
-static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
-{
- pm_runtime_mark_last_busy(mcspi->dev);
- pm_runtime_put_autosuspend(mcspi->dev);
-}
-
-static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
-{
- return pm_runtime_get_sync(mcspi->dev);
-}
static int omap2_prepare_transfer(struct spi_master *master)
{
@@ -848,12 +838,13 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
- ret = omap2_mcspi_enable_clocks(mcspi);
+ ret = pm_runtime_get_sync(mcspi->dev);
if (ret < 0)
return ret;
ret = omap2_mcspi_setup_transfer(spi, NULL);
- omap2_mcspi_disable_clocks(mcspi);
+ pm_runtime_mark_last_busy(mcspi->dev);
+ pm_runtime_put_autosuspend(mcspi->dev);
return ret;
}
@@ -1067,7 +1058,7 @@ static int __devinit omap2_mcspi_master_setup(struct
omap2_mcspi *mcspi)
struct omap2_mcspi_regs *ctx = &mcspi->ctx;
int ret = 0;
- ret = omap2_mcspi_enable_clocks(mcspi);
+ ret = pm_runtime_get_sync(mcspi->dev);
if (ret < 0)
return ret;
@@ -1076,7 +1067,8 @@ static int __devinit omap2_mcspi_master_setup(struct
omap2_mcspi *mcspi)
ctx->wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
omap2_mcspi_set_master_mode(master);
- omap2_mcspi_disable_clocks(mcspi);
+ pm_runtime_mark_last_busy(mcspi->dev);
+ pm_runtime_put_autosuspend(mcspi->dev);
return 0;
}
@@ -1252,7 +1244,8 @@ static int __devexit omap2_mcspi_remove(struct
platform_device *pdev)
mcspi = spi_master_get_devdata(master);
dma_channels = mcspi->dma_channels;
- omap2_mcspi_disable_clocks(mcspi);
+ pm_runtime_mark_last_busy(mcspi->dev);
+ pm_runtime_put_autosuspend(mcspi->dev);
pm_runtime_disable(&pdev->dev);
spi_unregister_master(master);
@@ -1278,7 +1271,7 @@ static int omap2_mcspi_resume(struct device *dev)
struct omap2_mcspi_regs *ctx = &mcspi->ctx;
struct omap2_mcspi_cs *cs;
- omap2_mcspi_enable_clocks(mcspi);
+ pm_runtime_get_sync(mcspi->dev);
list_for_each_entry(cs, &ctx->cs, node) {
if ((cs->chconf0 & OMAP2_MCSPI_CHCONF_FORCE) == 0) {
/*
@@ -1291,7 +1284,8 @@ static int omap2_mcspi_resume(struct device *dev)
__raw_writel(cs->chconf0, cs->base +
OMAP2_MCSPI_CHCONF0);
}
}
- omap2_mcspi_disable_clocks(mcspi);
+ pm_runtime_mark_last_busy(mcspi->dev);
+ pm_runtime_put_autosuspend(mcspi->dev);
return 0;
}
#else
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] spi: omap2-mcspi: At remove dont use the runtime_autosuspend calls
At remove we shouldnt be using the autosuspend timeout as we are calling pm_runtime_disable immediately after. Acked-by: Felipe Balbi Signed-off-by: Shubhrajyoti D --- drivers/spi/spi-omap2-mcspi.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index 8a5e2c0..1c1dd34 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -1244,8 +1244,7 @@ static int __devexit omap2_mcspi_remove(struct platform_device *pdev) mcspi = spi_master_get_devdata(master); dma_channels = mcspi->dma_channels; - pm_runtime_mark_last_busy(mcspi->dev); - pm_runtime_put_autosuspend(mcspi->dev); + pm_runtime_put_sync(mcspi->dev); pm_runtime_disable(&pdev->dev); spi_unregister_master(master); -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] spi: omap2-mcspi: Remove the macro MOD_REG_BIT
Remove the macro MOD_REG_BIT instead make the bit field modifications
directly. This deletes a branch operation in cases where the the set
is predecided. While at it optimise two sequential bit clear in one step.
Acked-by: Felipe Balbi
Signed-off-by: Shubhrajyoti D
---
drivers/spi/spi-omap2-mcspi.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index f542f3d..8a5e2c0 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -140,13 +140,6 @@ struct omap2_mcspi_cs {
u32 chconf0;
};
-#define MOD_REG_BIT(val, mask, set) do { \
- if (set) \
- val |= mask; \
- else \
- val &= ~mask; \
-} while (0)
-
static inline void mcspi_write_reg(struct spi_master *master,
int idx, u32 val)
{
@@ -205,7 +198,11 @@ static void omap2_mcspi_set_dma_req(const struct
spi_device *spi,
else
rw = OMAP2_MCSPI_CHCONF_DMAW;
- MOD_REG_BIT(l, rw, enable);
+ if (enable)
+ l |= rw;
+ else
+ l &= ~rw;
+
mcspi_write_chconf0(spi, l);
}
@@ -224,7 +221,11 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
int cs_active)
u32 l;
l = mcspi_cached_chconf0(spi);
- MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ if (cs_active)
+ l |= OMAP2_MCSPI_CHCONF_FORCE;
+ else
+ l &= ~OMAP2_MCSPI_CHCONF_FORCE;
+
mcspi_write_chconf0(spi, l);
}
@@ -239,9 +240,8 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
* to single-channel master mode
*/
l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
- MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_STEST, 0);
- MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 0);
- MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
+ l &= ~(OMAP2_MCSPI_MODULCTRL_STEST | OMAP2_MCSPI_MODULCTRL_MS);
+ l |= OMAP2_MCSPI_MODULCTRL_SINGLE;
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
ctx->modulctrl = l;
@@ -1278,9 +1278,9 @@ static int omap2_mcspi_resume(struct device *dev)
* We need to toggle CS state for OMAP take this
* change in account.
*/
- MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
+ cs->chconf0 |= OMAP2_MCSPI_CHCONF_FORCE;
__raw_writel(cs->chconf0, cs->base +
OMAP2_MCSPI_CHCONF0);
- MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
+ cs->chconf0 &= ~OMAP2_MCSPI_CHCONF_FORCE;
__raw_writel(cs->chconf0, cs->base +
OMAP2_MCSPI_CHCONF0);
}
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] spi: omap2-mcspi: spi cleanups
This patch does the following Calls the pm_runtime_* functions directly. Remove the MOD_REG_BIT macro usage thereby removiing un-needed branch. At remove dont use the autosuspend runtime calls. Changes from v1: Fix the comments on changelogs. Add acks to the patches. The following changes since commit 23dcfa61bac244e1200ff9ad19c6e9144dcb6bb5: Merge branch 'akpm' (Andrew's patch-bomb) (2012-08-21 17:22:22 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git for_3.6/spi Shubhrajyoti D (3): spi: omap2-mcspi: Call pm_runtime_* functions directly spi: omap2-mcspi: Remove the macro MOD_REG_BIT spi: omap2-mcspi: At remove dont use the runtime_autosuspend calls drivers/spi/spi-omap2-mcspi.c | 55 ++--- 1 files changed, 24 insertions(+), 31 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] spi: omap2-mcspi: Remove the macro MOD_REG_BIT
Hi Felipe,
Thanks for the review
On Tuesday 21 August 2012 02:35 PM, Felipe Balbi wrote:
> On Tue, Aug 21, 2012 at 11:47:43AM +0530, Shubhrajyoti D wrote:
>> Remove the macro MOD_REG_BIT instead make the bit field modifications
>> directly. This deletes a branch operation in cases where the the set
>> is predecided.While at it optimise two sequential bit clear in one step.
>^^
> you need a space here, besides you can add the ack below
Will fix that and resend.
>> Signed-off-by: Shubhrajyoti D
> Acked-by: Felipe Balbi
>
>> ---
>> drivers/spi/spi-omap2-mcspi.c | 28 ++--
>> 1 files changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
>> index dd887eb..5642111 100644
>> --- a/drivers/spi/spi-omap2-mcspi.c
>> +++ b/drivers/spi/spi-omap2-mcspi.c
>> @@ -140,13 +140,6 @@ struct omap2_mcspi_cs {
>> u32 chconf0;
>> };
>>
>> -#define MOD_REG_BIT(val, mask, set) do { \
>> -if (set) \
>> -val |= mask; \
>> -else \
>> -val &= ~mask; \
>> -} while (0)
>> -
>> static inline void mcspi_write_reg(struct spi_master *master,
>> int idx, u32 val)
>> {
>> @@ -205,7 +198,11 @@ static void omap2_mcspi_set_dma_req(const struct
>> spi_device *spi,
>> else
>> rw = OMAP2_MCSPI_CHCONF_DMAW;
>>
>> -MOD_REG_BIT(l, rw, enable);
>> +if (enable)
>> +l |= rw;
>> +else
>> +l &= ~rw;
>> +
>> mcspi_write_chconf0(spi, l);
>> }
>>
>> @@ -224,7 +221,11 @@ static void omap2_mcspi_force_cs(struct spi_device
>> *spi, int cs_active)
>> u32 l;
>>
>> l = mcspi_cached_chconf0(spi);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
>> +if (cs_active)
>> +l |= OMAP2_MCSPI_CHCONF_FORCE;
>> +else
>> +l &= ~OMAP2_MCSPI_CHCONF_FORCE;
>> +
>> mcspi_write_chconf0(spi, l);
>> }
>>
>> @@ -239,9 +240,8 @@ static void omap2_mcspi_set_master_mode(struct
>> spi_master *master)
>> * to single-channel master mode
>> */
>> l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_STEST, 0);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_MS, 0);
>> -MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
>> +l &= ~(OMAP2_MCSPI_MODULCTRL_STEST | OMAP2_MCSPI_MODULCTRL_MS);
>> +l |= OMAP2_MCSPI_MODULCTRL_SINGLE;
>> mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
>>
>> ctx->modulctrl = l;
>> @@ -1276,9 +1276,9 @@ static int omap2_mcspi_resume(struct device *dev)
>> * We need to toggle CS state for OMAP take this
>> * change in account.
>> */
>> -MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 1);
>> +cs->chconf0 |= OMAP2_MCSPI_CHCONF_FORCE;
>> __raw_writel(cs->chconf0, cs->base +
>> OMAP2_MCSPI_CHCONF0);
>> -MOD_REG_BIT(cs->chconf0, OMAP2_MCSPI_CHCONF_FORCE, 0);
>> +cs->chconf0 &= ~OMAP2_MCSPI_CHCONF_FORCE;
>> __raw_writel(cs->chconf0, cs->base +
>> OMAP2_MCSPI_CHCONF0);
>> }
>> }
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
Some IP blocks might not be using/controlling more than one
reset line, this check loosens the restriction to fully use
hwmod framework for those drivers.
E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
- As of now cpu1 is not used and hence (with previous check) the
IP block isn't fully enabled by hwmod code.
- Usually ipu and dsp processors configure their mmu module first
and then enable the processors, this involves:
* Deasserting mmu reset line, and enabling the module.
* Deasserting cpu0 reset line, and enabling the processor.
The ones portrayed in this example are controlled through
rproc_fw_boot in drivers/remoteproc/remoteproc_core.c
While at it, prevent _omap4_module_disable if all the hardreset
lines on an IP block are not under reset.
This will allow the driver to:
a. Deassert the reset line.
b. Enable the hwmod through runtime PM default callbacks.
c. Do its usecase.
d. Disable hwmod through runtime PM.
e. Assert the reset line.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 6ca8e51..eaedc33 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1558,25 +1558,28 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
}
/**
- * _are_any_hardreset_lines_asserted - return true if part of @oh is hard-reset
+ * _are_all_hardreset_lines_asserted - return true if the @oh is hard-reset
* @oh: struct omap_hwmod *
*
- * If any hardreset line associated with @oh is asserted, then return true.
- * Otherwise, if @oh has no hardreset lines associated with it, or if
- * no hardreset lines associated with @oh are asserted, then return false.
+ * If all hardreset lines associated with @oh are asserted, then return true.
+ * Otherwise, if part of @oh is out hardreset or if no hardreset lines
+ * associated with @oh are asserted, then return false.
* This function is used to avoid executing some parts of the IP block
- * enable/disable sequence if a hardreset line is set.
+ * enable/disable sequence if its hardreset line is set.
*/
-static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+static bool _are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
{
- int i;
+ int i, rst_cnt = 0;
if (oh->rst_lines_cnt == 0)
return false;
for (i = 0; i < oh->rst_lines_cnt; i++)
if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
- return true;
+ rst_cnt++;
+
+ if (oh->rst_lines_cnt == rst_cnt)
+ return true;
return false;
}
@@ -1595,6 +1598,13 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
if (!oh->clkdm || !oh->prcm.omap4.modulemode)
return -EINVAL;
+ /*
+* Since integration code might still be doing something, only
+* disable if all lines are under hardreset.
+*/
+ if (!_are_all_hardreset_lines_asserted(oh))
+ return 0;
+
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
omap4_cminst_module_disable(oh->clkdm->prcm_partition,
@@ -1602,9 +1612,6 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
oh->clkdm->clkdm_offs,
oh->prcm.omap4.clkctrl_offs);
- if (_are_any_hardreset_lines_asserted(oh))
- return 0;
-
v = _omap4_wait_target_disable(oh);
if (v)
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
@@ -1830,7 +1837,7 @@ static int _enable(struct omap_hwmod *oh)
}
/*
-* If an IP block contains HW reset lines and any of them are
+* If an IP block contains HW reset lines and all of them are
* asserted, we let integration code associated with that
* block handle the enable. We've received very little
* information on what those driver authors need, and until
@@ -1838,7 +1845,7 @@ static int _enable(struct omap_hwmod *oh)
* posted to the public lists, this is probably the best we
* can do.
*/
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
/* Mux pins for device runtime if populated */
@@ -1918,7 +1925,7 @@ static int _idle(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
return 0;
if (oh->class->sysc)
@@ -2006,7 +2013,7 @@ static int _shutdown(struct omap_hwmod *oh)
return -EINVAL;
}
- if (_are_any_hardreset_lines_asserted(oh))
+ if (_are_all_hardreset_lines_asserted(oh))
[PATCH 2/2] ARM: OMAP: hwmod: revise deassert sequence
For a reset sequence to complete cleanly, a module needs its
associated clocks to be enabled, otherwise the timeout check
in prcm code can print a false failure (failed to hardreset)
that occurs because the clocks aren't powered ON and the status
bit checked can't transition without them.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eaedc33..b65e021 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1509,6 +1509,7 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
{
struct omap_hwmod_rst_info ohri;
int ret = -EINVAL;
+ int hwsup = 0;
if (!oh)
return -EINVAL;
@@ -1520,10 +1521,46 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
+ if (oh->clkdm) {
+ /*
+* A clockdomain must be in SW_SUP otherwise reset
+* might not be completed. The clockdomain can be set
+* in HW_AUTO only when the module become ready.
+*/
+ hwsup = clkdm_in_hwsup(oh->clkdm);
+ ret = clkdm_hwmod_enable(oh->clkdm, oh);
+ if (ret) {
+ WARN(1, "omap_hwmod: %s: could not enable clockdomain
%s: %d\n",
+oh->name, oh->clkdm->name, ret);
+ return ret;
+ }
+ }
+
+ _enable_clocks(oh);
+ if (soc_ops.enable_module)
+ soc_ops.enable_module(oh);
+
ret = soc_ops.deassert_hardreset(oh, &ohri);
+
+ if (soc_ops.disable_module)
+ soc_ops.disable_module(oh);
+ _disable_clocks(oh);
+
if (ret == -EBUSY)
pr_warning("omap_hwmod: %s: failed to hardreset\n", oh->name);
+ if (!ret) {
+ /*
+* Set the clockdomain to HW_AUTO, assuming that the
+* previous state was HW_AUTO.
+*/
+ if (oh->clkdm && hwsup)
+ clkdm_allow_idle(oh->clkdm);
+ } else {
+ if (oh->clkdm)
+ clkdm_hwmod_disable(oh->clkdm, oh);
+ }
+
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: hwmod: fix hardreset handling
From: Omar Ramirez Luna The patch to expose hwmod assert/deassert functions through omap_device has been accepted and queued for 3.7[1], however these two patches are needed to make the API functional. Hence a revised version is being sent according to previous comments: - ARM: OMAP: hwmod: revise deassert sequence Now it uses enable|disable_module to handle the configuration of the modulemode inside CLKCTRL. As part of the cleanup of leaf clocks, the one associated with ipu_mmu will be removed along with the iommu hwmod migration[2]. - ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled More infomation added in the patch description[3]. [1] http://patchwork.kernel.org/patch/1266731/ [2] http://patchwork.kernel.org/patch/1201791/ [3] http://patchwork.kernel.org/patch/1201801/ Omar Ramirez Luna (2): ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled ARM: OMAP: hwmod: revise deassert sequence arch/arm/mach-omap2/omap_hwmod.c | 74 ++ 1 file changed, 59 insertions(+), 15 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 06/10] ARM: OMAP2+: gpmc: remove cs# in sync clk div calc
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
> Divider value for a certain sync clk is determined solely
> based on gpmc fclk. CS# does not have any role here, thus
> remove presence of CS# in clock divider calculation API.
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/gpmc-onenand.c |3 +--
> arch/arm/mach-omap2/gpmc.c |4 ++--
> arch/arm/plat-omap/include/plat/gpmc.h |2 +-
> 3 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
> b/arch/arm/mach-omap2/gpmc-onenand.c
> index 8a301f3..e139e3f 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -182,7 +182,6 @@ omap2_onenand_calc_sync_timings(struct
> omap_onenand_platform_data *cfg,
> int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
> int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
> int ticks_cez;
> - int cs = cfg->cs;
>
> if (cfg->flags & ONENAND_SYNC_READ)
> onenand_flags = ONENAND_FLAG_SYNCREAD;
> @@ -229,7 +228,7 @@ omap2_onenand_calc_sync_timings(struct
> omap_onenand_platform_data *cfg,
> break;
> }
>
> - div = gpmc_cs_calc_divider(cs, min_gpmc_clk_period);
> + div = gpmc_calc_divider(min_gpmc_clk_period);
> gpmc_clk_ns = gpmc_ticks_to_ns(div);
> if (gpmc_clk_ns < 15) /* >66Mhz */
> onenand_flags |= ONENAND_FLAG_HF;
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 68123d0..d005b3a 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -313,7 +313,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int
> st_bit, int end_bit,
> return -1
> #endif
>
> -int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
> +int gpmc_calc_divider(unsigned int sync_clk)
> {
> int div;
> u32 l;
> @@ -333,7 +333,7 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
> *t)
> int div;
> u32 l;
>
> - div = gpmc_cs_calc_divider(cs, t->sync_clk);
> + div = gpmc_calc_divider(t->sync_clk);
> if (div < 0)
> return -1;
>
> diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
> b/arch/arm/plat-omap/include/plat/gpmc.h
> index b7c9ea6..1cafbfd 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc.h
> @@ -179,7 +179,7 @@ extern unsigned long gpmc_get_fclk_period(void);
>
> extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
> extern u32 gpmc_cs_read_reg(int cs, int idx);
> -extern int gpmc_cs_calc_divider(int cs, unsigned int sync_clk);
> +extern int gpmc_calc_divider(unsigned int sync_clk);
> extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
> extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
> extern void gpmc_cs_free(int cs);
>
Reviewed-by: Jon Hunter
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 v6 05/10] ARM: OMAP2+: gpmc: find features by ip rev check
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
> Newer IP's have wr_access and wr_data_mux_bus fields. Use
> IP revision values to determine availability of these
> fields and hence decide on whether to configure them.
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/gpmc.c | 12 ++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 070fac5..68123d0 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -85,6 +85,11 @@
> #define ENABLE_PREFETCH (0x1 << 7)
> #define DMA_MPU_MODE 2
>
> +#define GPMC_REVISION_MAJOR(l) ((l >> 4) & 0xf)
> +
> +#define GPMC_HAS_WR_ACCESS 0x1
> +#define GPMC_HAS_WR_DATA_MUX_BUS0x2
> +
> /* XXX: Only NAND irq has been considered,currently these are the only ones
> used
> */
> #define GPMC_NR_IRQ 2
> @@ -131,6 +136,7 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
> static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
> static int gpmc_ecc_used = -EINVAL; /* cs using ecc engine */
>
> +static unsigned gpmc_capability;
> static void __iomem *gpmc_base;
>
> static struct clk *gpmc_l3_clk;
> @@ -356,10 +362,10 @@ int gpmc_cs_set_timings(int cs, const struct
> gpmc_timings *t)
> GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
> GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
>
> - if (cpu_is_omap34xx()) {
> + if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
> GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
> + if (gpmc_capability & GPMC_HAS_WR_ACCESS)
> GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
> - }
>
> /* caller is expected to have initialized CONFIG1 to cover
>* at least sync vs async
> @@ -922,6 +928,8 @@ static int __init gpmc_init(void)
> clk_enable(gpmc_l3_clk);
>
> l = gpmc_read_reg(GPMC_REVISION);
> + if (GPMC_REVISION_MAJOR(l) > 0x4)
> + gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
> printk(KERN_INFO "GPMC revision %d.%d\n", (l >> 4) & 0x0f, l & 0x0f);
> /* Set smart idle mode and automatic L3 clock gating */
> l = gpmc_read_reg(GPMC_SYSCONFIG);
>
Reviewed-by: Jon Hunter
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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/21/2012 08:16 AM, Mark Brown wrote: On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote: On 08/21/2012 02:05 PM, Mark Brown wrote: - sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA. This is wrong. PulseAudio uses the new ctljack API. I started out with an implementation which used the input device API (sound/core/jack.c), but since some people did not like this API, the ctljack API was designed and implemented for PA to use, which it does (since PulseAudio 2.0 - the input device API implementation in PulseAudio was never merged upstream). ...and the only thing using this API to generate events is HDA which is what I was talking about here given that this is a question from a driver point of view. What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support. I don't know either why we have two different interfaces for jack detection (not counting extcon) for driver writers. I think we should merge jack and ctljack, as long as that does not mean you break anything I'm relying on in ctljack. Maybe something for discussion at Plumbers? We discussed this last time we all met and came to the above conclusion :/ Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific. I thought that when Takashi did the new ctljack interface, that would effectively deprecate the old input device interface, and that ctljack was the new recommendation. Android currently uses the out of tree version of the extcon ABI (like I say it's where the code originated), and some OSs do use the input ABI also but realistically if you've got to pick one Android is where the market is at. So, it seems that the way to go is extcon. I guess that ALSA will use extcon just like today snd_jack uses the input driver. is this correct? Is there any chance that ctrljack will propagate the events through extcon? Is there any early implementation that I could look at? I am asking to know how feasible is to use ctljack today and be compatible with extcon in the future. Thanks! Ricardo To my knowledge no embedded OS is using the control jacks, it's possible that there's something using them as a function of using PulseAudio but the ones I'm famililar with currently ignore PulseAudio routing and just use the mixing facilities. Given the dependency on alsa-lib it'd be an inconvenient ABI to adopt for most of them. -- 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] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)" In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. drm already supports generic edid parsing to check for audio support. This is a good example of how an audio driver could just use that functionality to probe audio support. Ricardo BR, -R If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb. Tomi -- 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/4] arm/dts: regulator: Add tps65910 device tree data
On Tue, Aug 21, 2012 at 12:05:15PM -0600, Stephen Warren wrote: > On 08/21/2012 10:38 AM, Mark Brown wrote: > > This isn't the general view for the regualtor API - we generally > > want all regulators to be registered in order to allow us to see > > what's going on with things even if we've not figured them out from > > software. > Oh, I said the above specifically because when I added the LDO > configuration for the regulators that weren't used to the Tegra .dts > files, you told me to remove it, based on the comment I put in there > that they weren't used on the board. The board shouldn't have to define the regulators, the regulator driver really ought to be able to figure out that they're there by itself if there's no configuration based purely on knowing which chip is there. From that point of view it's OK for the chip .dtsi to have them (though ideally the driver wouldn't *need* that either) which was what was happening here. signature.asc Description: Digital signature
Re: [PATCH v3 1/4] arm/dts: regulator: Add tps65910 device tree data
On 08/21/2012 10:38 AM, Mark Brown wrote: > On Tue, Aug 21, 2012 at 09:48:21AM -0600, Stephen Warren wrote: > >> This .dtsi file adds a node for every single regulator within >> the TPS65910, which in turn means that of_regulator_match() will >> find a node for every regulator, and in turn every regulator will >> be registered. On some boards, not all of those regulators will >> be used, and hence we don't want all of them to be registered. > > This isn't the general view for the regualtor API - we generally > want all regulators to be registered in order to allow us to see > what's going on with things even if we've not figured them out from > software. Oh, I said the above specifically because when I added the LDO configuration for the regulators that weren't used to the Tegra .dts files, you told me to remove it, based on the comment I put in there that they weren't used on the board. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
On 20 August 2012 09:49, Benoit Cousson wrote: > On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote: >> Some IP blocks might not be using/controlling more than one >> reset line, this check loosens the restriction to fully use >> hwmod framework for those drivers. >> >> E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. >> - cpu1 might not be used and hence (with previous check) >> won't be fully enabled by hwmod code. > > You mean that you might have some case where you need to enable the > mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the > cpu1 under reset? Looks like I didn't reply to this question. Yes, initially cpu1 might not be used and kept under reset. Or even the mmu can be taken out of reset and configured, and cpu0 after it, creating a small window where one is taken out and the other is under reset. > So the any_hardreset is indeed not appropriate in that case. > > In fact, since the hardreset cannot be handled at all by the hwmod fmwk, > I'm even wondering if we should take care of checking the state at all. > But as Paul stated, if was done due to the lack of understanding about > the diver usage, so maybe things will become clearer once we will have > that code available. I still think it can, in fact all the code I'm using comes from the hwmod fmwk. _deassert_reset is almost the same as _enable, I left it this way to avoid reintroducing the issues that caused reset code to be stripped out from _enable path. Regards, Omar -- 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/4] arm/dts: regulator: Add tps65910 device tree data
On Tue, Aug 21, 2012 at 09:48:21AM -0600, Stephen Warren wrote: > This .dtsi file adds a node for every single regulator within the > TPS65910, which in turn means that of_regulator_match() will find a node > for every regulator, and in turn every regulator will be registered. On > some boards, not all of those regulators will be used, and hence we > don't want all of them to be registered. This isn't the general view for the regualtor API - we generally want all regulators to be registered in order to allow us to see what's going on with things even if we've not figured them out from software. > If dtc allowed /include/ inside a node rather than just at the > top-level, that might solve this. Or, #defines to the board .dts could > define the label name, and the .dtsi reference that label name. I do constantly wish that more of the people churning out DT stuff would look at the tooling around it :/ signature.asc Description: Digital signature
Re: [PATCH v3 1/4] arm/dts: regulator: Add tps65910 device tree data
On 08/21/2012 05:17 AM, AnilKumar Ch wrote:
> Add device tree data for tps65910 regulator by adding all tps65910
> regulator nodes. Regulator is initialized based on compatiable
> name provided in tps65910 DT file.
>
> All tps65910 PMIC regulator device tree nodes are placed in a
> seperate device tree include file (tps65910.dtsi). This patch
> was tested on AM335x-EVM.
This .dtsi file adds a node for every single regulator within the
TPS65910, which in turn means that of_regulator_match() will find a node
for every regulator, and in turn every regulator will be registered. On
some boards, not all of those regulators will be used, and hence we
don't want all of them to be registered.
If we backport the /delete-node/ feature I implemented, perhaps we could
solve that; see:
http://comments.gmane.org/gmane.linux.drivers.devicetree/19170
> diff --git a/arch/arm/boot/dts/tps65910.dtsi b/arch/arm/boot/dts/tps65910.dtsi
I wonder if there shouldn't be some better common location for .dtsi
files that are ancilliary chips, rather than ARM-specific?
> +&tps {
> + compatible = "ti,tps65910";
Perhaps this file should expect some more unique label than just "tps".
Many boards have many power-related chips, all with model names that
start with "tps"; I foresee conflict here.
If dtc allowed /include/ inside a node rather than just at the
top-level, that might solve this. Or, #defines to the board .dts could
define the label name, and the .dtsi reference that label name.
--
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 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register
Hi Venkat,
Some doubts below.
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
> SYSCONFIG register of HSMMC IP is managed by the omap hwmod
> abstraction layer.
At init only right?
> Resetting the IP and configuring the correct
> SYSCONFIG mode is centrally managed by hwmod.
>
> Remove code which manipulates IP reset and SYSCONFIG directly in the
> driver.
I am not sure if mmc needs a reset.
However IMHO
In case it needs a reset
the hwmod way could be to use omap_hwmod_reset
However I fear it may be an issue with dt.
or
may be sysc could be restored something like [1]
if it doesnt need reset even the check for the SYSSTATUS could be
considered for removal.
[1] http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg12041.html
>
> Signed-off-by: Venkatraman S
> ---
> drivers/mmc/host/omap_hsmmc.c | 24 ++--
> 1 file changed, 2 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index da4f5a7..4bc55ac 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -44,7 +44,6 @@
> #include
>
> /* OMAP HSMMC Host Controller Registers */
> -#define OMAP_HSMMC_SYSCONFIG 0x0010
> #define OMAP_HSMMC_SYSSTATUS 0x0014
> #define OMAP_HSMMC_CON 0x002C
> #define OMAP_HSMMC_BLK 0x0104
> @@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct
> omap_hsmmc_host *host)
> if (host->context_loss == context_loss)
> return 1;
>
> - /* Wait for hardware reset */
> - timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
> - while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) !=
> RESETDONE
> - && time_before(jiffies, timeout))
> - ;
> -
> - /* Do software reset */
> - OMAP_HSMMC_WRITE(host->base, SYSCONFIG, SOFTRESET);
> - timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
> - while ((OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE) !=
> RESETDONE
> - && time_before(jiffies, timeout))
> - ;
> -
> - OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
> - OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
> + if (!OMAP_HSMMC_READ(host->base, SYSSTATUS) & RESETDONE)
> + return 1;
Should this check be removed.
>
> if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
> if (host->power_mode != MMC_POWER_OFF &&
> @@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct
> omap_hsmmc_host *host)
> value = OMAP_HSMMC_READ(host->base, CAPA);
> OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
>
> - /* Set the controller to AUTO IDLE mode */
> - value = OMAP_HSMMC_READ(host->base, SYSCONFIG);
> - OMAP_HSMMC_WRITE(host->base, SYSCONFIG, value | AUTOIDLE);
> -
> /* Set SD bus power bit */
> set_sd_bus_power(host);
> }
> @@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
> void *data)
>
> pm_runtime_get_sync(host->dev);
>
> - seq_printf(s, "SYSCONFIG:\t0x%08x\n",
> - OMAP_HSMMC_READ(host->base, SYSCONFIG));
> seq_printf(s, "CON:\t\t0x%08x\n",
> OMAP_HSMMC_READ(host->base, CON));
> seq_printf(s, "HCTL:\t\t0x%08x\n",
> --
> 1.7.11.1.25.g0e18bef
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S wrote:
> Flushing spurious IRQs from HSMMC IP is done twice in
> omap_hsmmc_irq and omap_hsmmc_do_irq.
spurious IRQ is flushed in start of omap_hsmmc_do_irq
and irq acked at the end of omap_hsmmc_do_irq
> Consolidate them to one location.
if you wanted to consolidated ...
>
> Signed-off-by: Venkatraman S
> ---
> drivers/mmc/host/omap_hsmmc.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 4bc55ac..20453c8 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -969,15 +969,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
> *host, int status)
> struct mmc_data *data;
> int end_cmd = 0, end_trans = 0;
>
> - if (!host->req_in_progress) {
just do a return from here
> - do {
> - OMAP_HSMMC_WRITE(host->base, STAT, status);
> - /* Flush posted write */
> - status = OMAP_HSMMC_READ(host->base, STAT);
> - } while (status & INT_EN_MASK);
> - return;
> - }
> -
> data = host->data;
> dev_vdbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
>
> @@ -1028,8 +1019,6 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
> *host, int status)
> }
> }
>
> - OMAP_HSMMC_WRITE(host->base, STAT, status);
> -
> if (end_cmd || ((status & CC) && host->cmd))
> omap_hsmmc_cmd_done(host, host->cmd);
> if ((end_trans || (status & TC)) && host->mrq)
> @@ -1045,11 +1034,13 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
> *dev_id)
> int status;
>
> status = OMAP_HSMMC_READ(host->base, STAT);
> - do {
> + while (status & INT_EN_MASK && host->req_in_progress) {
and remove the check for host->req_in_progress
I think do while loop can be retained as it will get executed once anyway.
> omap_hsmmc_do_irq(host, status);
> +
> /* Flush posted write */
comment is misplaced
> + OMAP_HSMMC_WRITE(host->base, STAT, status);
> status = OMAP_HSMMC_READ(host->base, STAT);
> - } while (status & INT_EN_MASK);
> + }
>
> return IRQ_HANDLED;
> }
> --
> 1.7.11.1.25.g0e18bef
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/13] OMAP Serial patches
Hi, On Tue, Aug 21, 2012 at 04:01:36PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Aug 21, 2012 at 03:15:58PM +0300, Felipe Balbi wrote: > > Hi guys, > > > > here's a series of cleanup patches to the OMAP serial > > driver. A later series could be made re-implementing > > DMA using the DMA Engine API. Note that for RX DMA > > we could be using RX Timeout IRQ as a hint that we better > > use PIO instead ;-) > > > > All patches were tested on my pandaboard, but I'd really > > like to receive Tested-by on other platforms. > > > > After this goes in, I'll probably try to get UART wakeup > > working again and only after that look at DMA. > > > > Changes since v1: > > > > . improved commit log on patch 9/13 (formerly 10/13) > > . removed patch 2/13 > > . added a new patch switching from spin_lock_irqsave() to spin_lock and > > spin_unlock_irqrestore to spin_unlock > > > > Retested with my pandaboard, UART continues to work: > > > > # grep -i uart /proc/interrupts > > 106:124 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:189 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:255 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:321 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:387 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:453 0 GIC OMAP UART2 > > # grep -i uart /proc/interrupts > > 106:519 0 GIC OMAP UART2 > > > > cheers > > > > ps: if anyone knows a better test for UART, let me know. > > > > for convenience of anyone testing, patches are available on my git tree [1] > > on > > branch uart > > > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart > > I have added one extra patch to this series: > > From 6921efdb13dda7af216b331bb35535d4b53f004a Mon Sep 17 00:00:00 2001 > From: Felipe Balbi > Date: Tue, 21 Aug 2012 15:48:35 +0300 > Subject: [PATCH] serial: omap: drop pm_runtime_irq_safe() usage > > pm_runtime_irq_safe() will essentially do an > unbalanced pm_runtime_get_sync() on our parent > device, which might cause problems when trying > to suspend. > > In order to prevent that we drop pm_runtime_irq_safe > usage in exchange for a little performance hit > when we enter our IRQ handler while still suspended. > > If that happens, what we will do is set the irq_pending > flag, do an asynchronous pm_runtime_get() call and > return IRQ_HANDLED. When our runtime_resume() callback > is executed, we check for that flag, and run our > IRQ handler so that we receive/transmit the pending > characters. > > Signed-off-by: Felipe Balbi > --- > > One extra patch to OMAP UART driver. This seems to be working > pretty well even after echo mem > /sys/power/state. I can > see that I can even wake my pandaboard up by sending a character > through serial: > > # echo mem > /sys/power/state > [ 1335.679260] PM: Syncing filesystems ... done. > [ 1335.684387] Freezing user space processes ... (elapsed 0.00 seconds) done. > [ 1335.691741] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) > done. > [ 1335.720886] Suspending console(s) (use no_console_suspend to debug) > > [ 1335.734405] PM: suspend of devices complete after 5.492 msecs > [ 1335.735534] PM: late suspend of devices complete after 1.128 msecs > [ 1335.737518] PM: noirq suspend of devices complete after 1.952 msecs > [ 1335.737518] Disabling non-boot CPUs ... > [ 1335.738525] CPU1: shutdown > [ 1338.543762] Successfully put all powerdomains to target state > [ 1338.543853] Enabling non-boot CPUs ... > [ 1338.545654] CPU1: Booted secondary processor > [ 1338.546020] CPU1 is up > [ 1338.547027] PM: noirq resume of devices complete after 0.976 msecs > [ 1338.548400] PM: early resume of devices complete after 0.762 msecs > [ 1339.827087] PM: resume of devices complete after 1278.686 msecs > [ 1339.890960] Restarting tasks ... done. > # # grep -i uart /proc/interrupts > 106: 3385 0 GIC OMAP UART2 > # echo mem > /sys/power/state > [ 1358.015624] PM: Syncing filesystems ... done. > [ 1358.020812] Freezing user space processes ... (elapsed 0.00 seconds) done. > [ 1358.028167] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) > done. > [ 1358.055084] Suspending console(s) (use no_console_suspend to debug) > > [ 1358.068847] PM: suspend of devices complete after 5.633 msecs > [ 1358.070007] PM: late suspend of devices complete after 1.126 msecs > [ 1358.072051] PM: noirq suspend of devices complete after 2.040 msecs > [ 1358.072051] Disabling non-boot CPUs ... > [ 1358.073211] CPU1: shutdown > [ 1359.104156] Successfully put all powerdomains to target state > [ 1359.104278] Enabling non-boot CPUs ... > [ 1359.106079] CPU1: Booted secondary processor > [ 1359.106475] CPU1 is up >
Re: [RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
On Tue, Aug 21, 2012 at 03:22:18PM +0300, Felipe Balbi wrote: > On Tue, Aug 21, 2012 at 05:50:28PM +0530, Poddar, Sourav wrote: > > If I am understanding correctly, if they both uses the same bit we cannot > > use both for a particular user. ? > we can, it's just a bit more complex. If a user request both LOW and > HIGH, then you start with HIGH, once it triggers, before calling the > nested IRQ handler, you need to change it LOW. When low triggers, before > calling the nested IRQ handler, you need to change it to HIGH again. And > so on. I'm just not sure if that's valid on linux IRQ subsystem. The given example was for keypress - usually a system would use edge triggered interrupts in combination with reading the GPIO state rather than level triggered interrupts. -- 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] ASoC: omap-mcbsp: Device tree binding documentation update
To reflect the final devicetree node structure of McBSPs.
Signed-off-by: Peter Ujfalusi
---
Hello,
the initial OMAP McBSP DT structure was not able to describe the IP (and it's
versions) correctly.
The main issue was the sidetone block of McBSP2/3 on OMAP3.
With this change in the DT description the OS can get the needed information
about the IP.
The sidetone is still not supported when the Linux kernel is booted with DT
since we still depend on hwmod to fill the resources.
This patch depend on the McBSP DT support series going via audio tree.
Regards,
Peter
.../devicetree/bindings/sound/omap-mcbsp.txt | 28 +++
1 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
index 447cb13..17cce44 100644
--- a/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
+++ b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt
@@ -8,38 +8,30 @@ Required properties:
- reg: Register location and size, for OMAP4+ as an array:
,
;
+- reg-names: Array of strings associated with the address space
- interrupts: Interrupt numbers for the McBSP port, as an array in case the
McBSP IP have more interrupt lines:
,
,
;
+- interrupt-names: Array of strings associated with the interrupt numbers
- interrupt-parent: The parent interrupt controller
- ti,buffer-size: Size of the FIFO on the port (OMAP2430 and newer SoC)
- ti,hwmods: Name of the hwmod associated to the McBSP port
-Sidetone support for OMAP3 McBSP2 and 3 ports:
-- sidetone { }: Within this section the following parameters are required:
-- reg: Register location and size for the ST block
-- interrupts: The interrupt number for the ST block
-- interrupt-parent: The parent interrupt controller for the ST block
-
Example:
mcbsp2: mcbsp@49022000 {
compatible = "ti,omap3-mcbsp";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x49022000 0xff>;
- interrupts = <0 17 0x4>, /* OCP compliant interrup */
-<0 62 0x4>, /* TX interrup */
-<0 63 0x4>; /* RX interrup */
+ reg = <0x49022000 0xff>,
+ <0x49028000 0xff>;
+ reg-names = "mpu", "sidetone";
+ interrupts = <0 17 0x4>, /* OCP compliant interrupt */
+<0 62 0x4>, /* TX interrupt */
+<0 63 0x4>, /* RX interrupt */
+<0 4 0x4>; /* Sidetone */
+ interrupt-names = "common", "tx", "rx", "sidetone";
interrupt-parent = <&intc>;
ti,buffer-size = <1280>;
ti,hwmods = "mcbsp2";
-
- sidetone {
- reg = <0x49028000 0xff>;
- interrupts = <0 4 0x4>;
- interrupt-parent = <&intc>;
- };
};
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
On 21/08/12 06:49 AM, Tomi Valkeinen wrote:
> On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
>
>>> +
>>> + /* ChiMei G121S1-L01 */
>>> + {
>>> + {
>>
>> ...
>>
>>> + .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
>>> + .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
>>> + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
>>> + .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
>>> + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
>>
>> Actually those 3 panels only use the DE signal. The hsync/vsync signals
>> are not used and on our system we mux them out to make sure they are
>> kept low as recommended in the panel datasheets.
>>
>> Since vsync/hsync are not used, I think the vsync_level, hsync_level and
>> sync_pclk_edge entries could be removed. Otherwise the updated patch
>> works fine as is.
>
> Okay. How do panels like that work? How can they know where a new frame
> starts?
By DE being inactive for a different number of pixel clock cycles during
the vertical and horizontal blanking periods.
> Actually, I now googled for those panels, and they are all LVDS panels,
> not DPI panels. So the patch doesn't look correct at all.
>
> Do you have a DPI-to-LVDS converter chip on your board?
Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84.
The reason for using this approach was that the panels covered by
this patch seemed not to be compatible with Flatlink 3G, which meant
driving them directly from the AM35xx SDI serial interface was not possible.
We unfortunately do not get to select which LVDS deserializer is
used at the panel side..
Best regards,
Raphaël Assénat
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 05:09:24PM +0300, Felipe Balbi wrote: > You can't possibly understand what that'll print. First of all, VEN_ID_H > and VEN_ID_L should be ORed together. Second, the user will see the same > message four times in a row, with different values, but see that driver > claims that all four values refer to the device id. What this should do, > is at least combine all four messages into a single one of the format: > dev_(dbg|info)(&i2c->dev, "SMSCxxx devid: %02x rev: %02x venid: %02x\n", > devid, rev, (venid_h << 8) | venid_l); > or something similar. Yes, I agree that the formatting here should also be improved - as I said in one of my earlier mails if any of these things are fixed things that should never change the driver should instead verify the value rather than log it. signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Tue, Aug 21, 2012 at 03:08:03PM +0100, Mark Brown wrote: > On Tue, Aug 21, 2012 at 04:52:41PM +0300, Felipe Balbi wrote: > > > Fair enough, we have "quiet", but I'm not sure that's enough argument to > > allow any simple driver to start poluting dmesg with whatever random > > messages. > > I think if the driver is just logging to say "I'm running" that's noise > and I do push back on that routinely myself; if the driver is providing > information it's discovered from the running system then that seems much > more useful and we should have a sensible way of getting that out in a > place where users are likely to find. fair enough. But look at the messages which that driver is printing: + regmap_read(smsc->regmap, SMSC_DEV_ID, &ret); + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret); + + regmap_read(smsc->regmap, SMSC_DEV_REV, &ret); + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret); + + regmap_read(smsc->regmap, SMSC_VEN_ID_L, &ret); + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret); + + regmap_read(smsc->regmap, SMSC_VEN_ID_H, &ret); + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret); You can't possibly understand what that'll print. First of all, VEN_ID_H and VEN_ID_L should be ORed together. Second, the user will see the same message four times in a row, with different values, but see that driver claims that all four values refer to the device id. What this should do, is at least combine all four messages into a single one of the format: dev_(dbg|info)(&i2c->dev, "SMSCxxx devid: %02x rev: %02x venid: %02x\n", devid, rev, (venid_h << 8) | venid_l); or something similar. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 04:52:41PM +0300, Felipe Balbi wrote: > Fair enough, we have "quiet", but I'm not sure that's enough argument to > allow any simple driver to start poluting dmesg with whatever random > messages. I think if the driver is just logging to say "I'm running" that's noise and I do push back on that routinely myself; if the driver is providing information it's discovered from the running system then that seems much more useful and we should have a sensible way of getting that out in a place where users are likely to find. signature.asc Description: Digital signature
Re: [PATCH v3 0/4] Add AM33XX regulators device tree data
On Tue, Aug 21, 2012 at 04:47:26PM +0530, AnilKumar Ch wrote: > This patch series add AM33XX regulators (tps65910/tps65217) device > tree data to am335x-evm and am335x-bone dts files. These patches > are based on Tony L "devel-dt" tree with these patches > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg73843.html > and these patches has been tested on AM335x EVM and Bone devices. Reviewed-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 02:49:37PM +0100, Mark Brown wrote: > On Tue, Aug 21, 2012 at 04:27:44PM +0300, Felipe Balbi wrote: > > > I still beg to differ. Even if it fails, dmesg will still contain the > > message (provided you have it enabled). I really don't think we want > > this to print to console on every boot. > > Only if it's enabled which is the trick... > > > If you're still testing your new batch of boards, you're not just a > > simple user and you will have debugging enabled anyway. dev_info() will > > be visible to anyone who's got a console running. Not sure how useful > > that would be to my neighbor. > > Also think about hobbyists and so on, and ideally at some point the > people using distros. We shouldn't be requiring kernel rebuilds for > this sort of diagnostic information. I guess sysfs is another option but we don't. We have dynamic printk for that, right ? > but frankly the overhead on boot just doesn't seem meaningful in the > context of the overall kernel boot style - I'd really expect people who > are bothered by this sort of output would be raising the minimum log > level appearing on the console. Well, if you consider a single driver then surely it doesn't make a difference. But when you add many drivers, each with its own dev_info() output, it can delay bootup rather significantly, actually. Fair enough, we have "quiet", but I'm not sure that's enough argument to allow any simple driver to start poluting dmesg with whatever random messages. my 2 cents -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 04:27:44PM +0300, Felipe Balbi wrote: > I still beg to differ. Even if it fails, dmesg will still contain the > message (provided you have it enabled). I really don't think we want > this to print to console on every boot. Only if it's enabled which is the trick... > If you're still testing your new batch of boards, you're not just a > simple user and you will have debugging enabled anyway. dev_info() will > be visible to anyone who's got a console running. Not sure how useful > that would be to my neighbor. Also think about hobbyists and so on, and ideally at some point the people using distros. We shouldn't be requiring kernel rebuilds for this sort of diagnostic information. I guess sysfs is another option but frankly the overhead on boot just doesn't seem meaningful in the context of the overall kernel boot style - I'd really expect people who are bothered by this sort of output would be raising the minimum log level appearing on the console. signature.asc Description: Digital signature
Re: receiving data from mcbsp1 in master mode
On 08/21/2012 08:42 AM, Andreas Kemnade wrote: > Hi, > > I tried a couple of times with different kernels to use mcbsp1 of dm3730 > in master mode (so that it sends out clocks). > The result always is that I can send data out. but arecord gets no input. It > waits for input but does not get anything, although clocks are generated, > checked that with a scope. > > I even took a driver which works in master mode on another mcbsp and just > changed > the mcbsp number. > What needs to be done to receive data from mcbsp1? You should check the PIN mux configuration of McBSP1 FSR/CLKR pins. McBSP1 on dm3730 have 6 pin configuration. I think the capture should work fine if you select the FSX as FSR source, and CLKX as CLKR source. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 02:22:22PM +0100, Mark Brown wrote:
> On Tue, Aug 21, 2012 at 03:42:45PM +0300, Felipe Balbi wrote:
> > On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote:
> > > > + regmap_read(smsc->regmap, SMSC_DEV_ID, &ret);
> > > > + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret);
>
> > > I'd make these log messages dev_info() or something.
>
> > dev_info() ? It'lll just make boot noisier for no good reason. Which
> > user wants to see this during boot up ? That's a debugging feature for
> > develop IMHO.
>
> Most of the registers appeared to be chip revision information which is
> most definitely useful to tell people about, though possibly with neater
> formatting ("why is this batch of boards failing... oh, right"). If
> they're fixed device IDs then the driver should instead be verifying
> that the registers contain the expected values and bombing out if they
> don't. Either way dev_dbg() isn't too helpful.
I still beg to differ. Even if it fails, dmesg will still contain the
message (provided you have it enabled). I really don't think we want
this to print to console on every boot.
If you're still testing your new batch of boards, you're not just a
simple user and you will have debugging enabled anyway. dev_info() will
be visible to anyone who's got a console running. Not sure how useful
that would be to my neighbor.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 03:42:45PM +0300, Felipe Balbi wrote:
> On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote:
> > > + regmap_read(smsc->regmap, SMSC_DEV_ID, &ret);
> > > + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret);
> > I'd make these log messages dev_info() or something.
> dev_info() ? It'lll just make boot noisier for no good reason. Which
> user wants to see this during boot up ? That's a debugging feature for
> develop IMHO.
Most of the registers appeared to be chip revision information which is
most definitely useful to tell people about, though possibly with neater
formatting ("why is this batch of boards failing... oh, right"). If
they're fixed device IDs then the driver should instead be verifying
that the registers contain the expected values and bombing out if they
don't. Either way dev_dbg() isn't too helpful.
signature.asc
Description: Digital signature
Re: [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 07:39:55AM -0500, Clark, Rob wrote: > Does ASoC support 'hotplug' of audio devices? If so, maybe it makes > some sense to have some support in drm core. At least all the edid > parsing stuff to determine if the display supports audio should be > generic and not driver specific. Not really (except on a card level), and it'd probably confuse most userspaces. What I'd expect to happen currently is that the current state of the connector would get reported via extcon. signature.asc Description: Digital signature
Re: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 02:30:51PM +0200, David Henningsson wrote: > On 08/21/2012 02:05 PM, Mark Brown wrote: > > - sound/core/ctljack.c which was added later and provides separate > >in-kernel and userspace APIs and is currently only used by HDA. > This is wrong. PulseAudio uses the new ctljack API. I started out > with an implementation which used the input device API > (sound/core/jack.c), but since some people did not like this API, > the ctljack API was designed and implemented for PA to use, which it > does (since PulseAudio 2.0 - the input device API implementation in > PulseAudio was never merged upstream). ...and the only thing using this API to generate events is HDA which is what I was talking about here given that this is a question from a driver point of view. > >What I'd like to see happening is that we merge ctljack into jack (since > >only HDA is going to be affected by that change it seems like the right > >direction to make the merge) and also add extcon support, I have looked > >at the extcon support. > I don't know either why we have two different interfaces for jack > detection (not counting extcon) for driver writers. I think we > should merge jack and ctljack, as long as that does not mean you > break anything I'm relying on in ctljack. > Maybe something for discussion at Plumbers? We discussed this last time we all met and came to the above conclusion :/ > >Short term for drivers used on embedded systems I'd have to recommend > >extcon rather than anything ALSA-specific. > I thought that when Takashi did the new ctljack interface, that > would effectively deprecate the old input device interface, and that > ctljack was the new recommendation. Android currently uses the out of tree version of the extcon ABI (like I say it's where the code originated), and some OSs do use the input ABI also but realistically if you've got to pick one Android is where the market is at. To my knowledge no embedded OS is using the control jacks, it's possible that there's something using them as a function of using PulseAudio but the ones I'm famililar with currently ignore PulseAudio routing and just use the mixing facilities. Given the dependency on alsa-lib it'd be an inconvenient ABI to adopt for most of them. signature.asc Description: Digital signature
Re: [PATCH v2 00/13] OMAP Serial patches
Hi, On Tue, Aug 21, 2012 at 03:15:58PM +0300, Felipe Balbi wrote: > Hi guys, > > here's a series of cleanup patches to the OMAP serial > driver. A later series could be made re-implementing > DMA using the DMA Engine API. Note that for RX DMA > we could be using RX Timeout IRQ as a hint that we better > use PIO instead ;-) > > All patches were tested on my pandaboard, but I'd really > like to receive Tested-by on other platforms. > > After this goes in, I'll probably try to get UART wakeup > working again and only after that look at DMA. > > Changes since v1: > > . improved commit log on patch 9/13 (formerly 10/13) > . removed patch 2/13 > . added a new patch switching from spin_lock_irqsave() to spin_lock and > spin_unlock_irqrestore to spin_unlock > > Retested with my pandaboard, UART continues to work: > > # grep -i uart /proc/interrupts > 106:124 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:189 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:255 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:321 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:387 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:453 0 GIC OMAP UART2 > # grep -i uart /proc/interrupts > 106:519 0 GIC OMAP UART2 > > cheers > > ps: if anyone knows a better test for UART, let me know. > > for convenience of anyone testing, patches are available on my git tree [1] on > branch uart > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart I have added one extra patch to this series: From 6921efdb13dda7af216b331bb35535d4b53f004a Mon Sep 17 00:00:00 2001 From: Felipe Balbi Date: Tue, 21 Aug 2012 15:48:35 +0300 Subject: [PATCH] serial: omap: drop pm_runtime_irq_safe() usage pm_runtime_irq_safe() will essentially do an unbalanced pm_runtime_get_sync() on our parent device, which might cause problems when trying to suspend. In order to prevent that we drop pm_runtime_irq_safe usage in exchange for a little performance hit when we enter our IRQ handler while still suspended. If that happens, what we will do is set the irq_pending flag, do an asynchronous pm_runtime_get() call and return IRQ_HANDLED. When our runtime_resume() callback is executed, we check for that flag, and run our IRQ handler so that we receive/transmit the pending characters. Signed-off-by: Felipe Balbi --- One extra patch to OMAP UART driver. This seems to be working pretty well even after echo mem > /sys/power/state. I can see that I can even wake my pandaboard up by sending a character through serial: # echo mem > /sys/power/state [ 1335.679260] PM: Syncing filesystems ... done. [ 1335.684387] Freezing user space processes ... (elapsed 0.00 seconds) done. [ 1335.691741] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1335.720886] Suspending console(s) (use no_console_suspend to debug) [ 1335.734405] PM: suspend of devices complete after 5.492 msecs [ 1335.735534] PM: late suspend of devices complete after 1.128 msecs [ 1335.737518] PM: noirq suspend of devices complete after 1.952 msecs [ 1335.737518] Disabling non-boot CPUs ... [ 1335.738525] CPU1: shutdown [ 1338.543762] Successfully put all powerdomains to target state [ 1338.543853] Enabling non-boot CPUs ... [ 1338.545654] CPU1: Booted secondary processor [ 1338.546020] CPU1 is up [ 1338.547027] PM: noirq resume of devices complete after 0.976 msecs [ 1338.548400] PM: early resume of devices complete after 0.762 msecs [ 1339.827087] PM: resume of devices complete after 1278.686 msecs [ 1339.890960] Restarting tasks ... done. # # grep -i uart /proc/interrupts 106: 3385 0 GIC OMAP UART2 # echo mem > /sys/power/state [ 1358.015624] PM: Syncing filesystems ... done. [ 1358.020812] Freezing user space processes ... (elapsed 0.00 seconds) done. [ 1358.028167] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 1358.055084] Suspending console(s) (use no_console_suspend to debug) [ 1358.068847] PM: suspend of devices complete after 5.633 msecs [ 1358.070007] PM: late suspend of devices complete after 1.126 msecs [ 1358.072051] PM: noirq suspend of devices complete after 2.040 msecs [ 1358.072051] Disabling non-boot CPUs ... [ 1358.073211] CPU1: shutdown [ 1359.104156] Successfully put all powerdomains to target state [ 1359.104278] Enabling non-boot CPUs ... [ 1359.106079] CPU1: Booted secondary processor [ 1359.106475] CPU1 is up [ 1359.107482] PM: noirq resume of devices complete after 1.004 msecs [ 1359.108886] PM: early resume of devices complete after 0.761 msecs [ 1360.414794] PM: resume of devices complete after 1305.836 msecs [ 1360.478668] Restarting tasks ... done. # # grep -i uart /proc/interrupts 106: 3511
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 01:41:46PM +0100, Mark Brown wrote: > > + regmap_read(smsc->regmap, SMSC_DEV_ID, &ret); > > + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret); > > I'd make these log messages dev_info() or something. dev_info() ? It'lll just make boot noisier for no good reason. Which user wants to see this during boot up ? That's a debugging feature for develop IMHO. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Tue, Aug 21, 2012 at 04:15:37PM +0530, Sourav Poddar wrote:
> +config MFD_SMSC
> + bool "Support for the SMSC ECE1099 series chips"
> + depends on I2C=y && MFD_CORE && REGMAP_I2C
This needs to select REGMAP_I2C not depend on it. REGMAP_I2C will only
be enabled by being selected.
> +int smsc_read(struct device *child, unsigned int reg,
> + unsigned int *dest)
> +{
> + struct smsc *smsc = dev_get_drvdata(child->parent);
> +
> + return regmap_read(smsc->regmap, reg, dest);
> +}
> +EXPORT_SYMBOL_GPL(smsc_read);
I'd suggest making these static inlines in the header given that they're
so trivial.
> +static struct regmap_config smsc_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .cache_type = REGCACHE_COMPRESSED,
> +};
Indentation is weird here. For the cache we should have at least
.max_register defined and given the functionality there must surely be
some volatile registers (I'm surprised this works at all as it is, the
cache should break things).
> + of_property_read_u32(node, "clock", &smsc->clk);
> +
This is all unconditional, there should be a dependency on this in
Kconfig.
> + regmap_read(smsc->regmap, SMSC_DEV_ID, &ret);
> + dev_dbg(&i2c->dev, "SMSC Device ID: %d\n", ret);
I'd make these log messages dev_info() or something.
> +err:
> + kfree(smsc);
Use devm_kzalloc() for this.
> +static const struct i2c_device_id smsc_i2c_id[] = {
> + { "smsc", 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, smsc_i2c_id);
This should probably list the part name rather than "smsc" - that seems
far too generic a name to use, obviously smsc produce more than one
part!
--
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] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: > On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: >> Hello! >> >> I have been working on prototypes for the ASoC OMAP HDMI audio driver to >> propagate events from the HDMI output (e.g., display getting >> enabled/disabled/suspended). This for the users of the driver to react >> to such events. For instance, if the display is disabled or disconected, >> audio could be stopped, rerouted or whatever other decision the user >> makes. This is needed because, if, for instance, the HDMI IP goes off, >> audio will stall and the audio users will only see a "playback write >> error (DMA or IRQ trouble?)" >> >> In my prototypes I have used snd_soc_jack for this purpose and I have >> some questions: >> >> *I see snd_soc_jack is used mostly for headsets and microphones with >> actual external mechanical connections. Strictly, in my case I propagate >> events originated by the OMAP display driver (changes in the power >> state), and not from external events. Some of these events are generated >> from an actual HDMI cable connection/disconnection, though. >> >> *Maybe the event should be propagated by omapdss/omapdrm/drm and the >> entity in charge of the audio policy should listen those events instead. >> >> *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is >> feasible for an audio driver to report events from an AV output. >> >> I was wondering about how much sense does it make to you guys use a >> snd_soc_jack in this case? > > How does DRM handle audio? I made a quick grep, but I see the drm > drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? >From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. BR, -R > If there's a common generic way to handle this, we should obviously use > that. But if we need to choose between doing something custom or doing > it in omapdrm driver, I think we should go for drm the only solution and > forget about audio with omapfb. > > Tomi > -- 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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/21/2012 02:05 PM, Mark Brown wrote: On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote: Ricardo Neri wrote: I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? HD-audio already uses the generic jack event for the HDMI/DP connection change notification as well, so I think it would make sense in general. The whole problem here is that we don't *have* a generic jack interface. We've got: - sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently. - sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA. This is wrong. PulseAudio uses the new ctljack API. I started out with an implementation which used the input device API (sound/core/jack.c), but since some people did not like this API, the ctljack API was designed and implemented for PA to use, which it does (since PulseAudio 2.0 - the input device API implementation in PulseAudio was never merged upstream). - extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too. This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts. What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support. I don't know either why we have two different interfaces for jack detection (not counting extcon) for driver writers. I think we should merge jack and ctljack, as long as that does not mean you break anything I'm relying on in ctljack. Maybe something for discussion at Plumbers? Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific. I thought that when Takashi did the new ctljack interface, that would effectively deprecate the old input device interface, and that ctljack was the new recommendation. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic -- 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/4] gpio: smscece: Add support for gpio IO expander feature
On Tue, Aug 21, 2012 at 05:50:28PM +0530, Poddar, Sourav wrote: > Hi, > > On Tue, Aug 21, 2012 at 5:30 PM, Felipe Balbi wrote: > > Hi, > > > > On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote: > >> >> + if (type & IRQ_TYPE_LEVEL_HIGH) > >> >> + sg->int_lvl[bank] |= bit; > >> >> + else if (type & IRQ_TYPE_LEVEL_LOW) > >> >> + sg->int_lvl[bank] &= ~bit; > >> >> + else > >> >> + return -EINVAL; > >> > > >> > this looks wrong. You could have a user who wants to trigger on both > >> > HIGH and LOW levels, no ? > >> > > >> Yes, I think there can be a scenario where gpio_keys are attached > >> to this driver and signals a "key press" at low and "key release" at > >> high. ? > >> Will figure out a way to add support to check for case where > >> both High and low levels are used. > > > > could probably be done on a separate patch, maybe... Just now I saw that > > HIGH and LOW levels use the same bit. > > > If I am understanding correctly, if they both uses the same bit we cannot > use both for a particular user. ? we can, it's just a bit more complex. If a user request both LOW and HIGH, then you start with HIGH, once it triggers, before calling the nested IRQ handler, you need to change it LOW. When low triggers, before calling the nested IRQ handler, you need to change it to HIGH again. And so on. I'm just not sure if that's valid on linux IRQ subsystem. Anyone ? -- balbi signature.asc Description: Digital signature
[PATCH v2 01/13] serial: omap: define and use to_uart_omap_port()
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized into
a cast anyway.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
arch/arm/plat-omap/include/plat/omap-serial.h | 2 ++
drivers/tty/serial/omap-serial.c | 36 +--
2 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..f3b35d9 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -137,4 +137,6 @@ struct uart_omap_port {
struct work_struct qos_work;
};
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port,
port)))
+
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d3cda0c..5c0d0bc 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -141,7 +141,7 @@ static void serial_omap_stop_rxdma(struct uart_omap_port
*up)
static void serial_omap_enable_ms(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
@@ -153,7 +153,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
if (up->use_dma &&
@@ -186,7 +186,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
static void serial_omap_stop_rx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
pm_runtime_get_sync(&up->pdev->dev);
if (up->use_dma)
@@ -307,7 +307,7 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
struct circ_buf *xmit;
unsigned int start;
@@ -449,7 +449,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
static unsigned int serial_omap_tx_empty(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
unsigned int ret = 0;
@@ -464,7 +464,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port
*port)
static unsigned int serial_omap_get_mctrl(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned int status;
unsigned int ret = 0;
@@ -487,7 +487,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port
*port)
static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned char mcr = 0;
dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
@@ -511,7 +511,7 @@ static void serial_omap_set_mctrl(struct uart_port *port,
unsigned int mctrl)
static void serial_omap_break_ctl(struct uart_port *port, int break_state)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
@@ -528,7 +528,7 @@ static void serial_omap_break_ctl(struct uart_port *port,
int break_state)
static int serial_omap_startup(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
int retval;
@@ -606,7 +606,7 @@ static int serial_omap_startup(struct uart_port *port)
static void serial_omap_shutdown(struct uart_port *port)
{
- struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct uart_omap_port *up = to_uart_omap_port(port);
unsigned long flags = 0;
dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
@@ -721,7 +721,7 @@ static void
serial_omap_set_termios(struct uart_p
[PATCH v2 03/13] serial: omap: don't access the platform_device
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct omap_device through
pdev->archdata field.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
arch/arm/mach-omap2/serial.c | 15 ++--
arch/arm/plat-omap/include/plat/omap-serial.h | 10 +--
drivers/tty/serial/omap-serial.c | 124 +-
3 files changed, 76 insertions(+), 73 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c1b93c7..8f07841 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -81,8 +81,9 @@ static struct omap_uart_port_info omap_serial_default_info[]
__initdata = {
};
#ifdef CONFIG_PM
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
if (!od)
@@ -99,15 +100,17 @@ static void omap_uart_enable_wakeup(struct platform_device
*pdev, bool enable)
* in Smartidle Mode When Configured for DMA Operations.
* WA: configure uart in force idle mode.
*/
-static void omap_uart_set_noidle(struct platform_device *pdev)
+static void omap_uart_set_noidle(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
omap_hwmod_set_slave_idlemode(od->hwmods[0], HWMOD_IDLEMODE_NO);
}
-static void omap_uart_set_smartidle(struct platform_device *pdev)
+static void omap_uart_set_smartidle(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
u8 idlemode;
@@ -120,10 +123,10 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev)
}
#else
-static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
+static void omap_uart_enable_wakeup(struct device *dev, bool enable)
{}
-static void omap_uart_set_noidle(struct platform_device *pdev) {}
-static void omap_uart_set_smartidle(struct platform_device *pdev) {}
+static void omap_uart_set_noidle(struct device *dev) {}
+static void omap_uart_set_smartidle(struct device *dev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index f3b35d9..743ac80 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -18,7 +18,7 @@
#define __OMAP_SERIAL_H__
#include
-#include
+#include
#include
#include
@@ -71,9 +71,9 @@ struct omap_uart_port_info {
unsigned intdma_rx_poll_rate;
int (*get_context_loss_count)(struct device *);
- void (*set_forceidle)(struct platform_device *);
- void (*set_noidle)(struct platform_device *);
- void (*enable_wakeup)(struct platform_device *, bool);
+ void (*set_forceidle)(struct device *);
+ void (*set_noidle)(struct device *);
+ void (*enable_wakeup)(struct device *, bool);
};
struct uart_omap_dma {
@@ -105,7 +105,7 @@ struct uart_omap_dma {
struct uart_omap_port {
struct uart_portport;
struct uart_omap_dmauart_dma;
- struct platform_device *pdev;
+ struct device *dev;
unsigned char ier;
unsigned char lcr;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6814a26..6ab3582 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -103,36 +103,36 @@ static inline void serial_omap_clear_fifos(struct
uart_omap_port *up)
static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
{
- struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+ struct omap_uart_port_info *pdata = up->dev->platform_data;
if (!pdata->get_context_loss_count)
return 0;
- return pdata->get_context_loss_count(&up->pdev->dev);
+ return pdata->get_context_loss_count(up->dev);
}
static void serial_omap_set_forceidle(struct uart_omap_port *up)
{
- struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+ struct omap_uart_port_info *pdata = up->dev->platform_data;
if (pdata->set_forceidle)
- pdata->set_forceidle(up->pdev);
+ pdata->set_forceidle(up->dev);
}
static void serial_omap_set_noidle(struct uart_omap_port *up)
{
- struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+ struct omap_uart_port_info *pdata = up->dev->platform_data;
if
[PATCH v2 04/13] serial: omap: drop DMA support
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file changed, 12 insertions(+), 318 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 6ab3582..16808b6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -33,14 +33,12 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
-#include
#include
#include
@@ -74,9 +72,6 @@
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
-static void uart_tx_dma_callback(int lch, u16 ch_status, void *data);
-static void serial_omap_rxdma_poll(unsigned long uart_no);
-static int serial_omap_start_rxdma(struct uart_omap_port *up);
static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1);
static struct workqueue_struct *serial_omap_uart_wq;
@@ -160,19 +155,6 @@ serial_omap_get_divisor(struct uart_port *port, unsigned
int baud)
return port->uartclk/(baud * divisor);
}
-static void serial_omap_stop_rxdma(struct uart_omap_port *up)
-{
- if (up->uart_dma.rx_dma_used) {
- del_timer(&up->uart_dma.rx_timer);
- omap_stop_dma(up->uart_dma.rx_dma_channel);
- omap_free_dma(up->uart_dma.rx_dma_channel);
- up->uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
- up->uart_dma.rx_dma_used = false;
- pm_runtime_mark_last_busy(up->dev);
- pm_runtime_put_autosuspend(up->dev);
- }
-}
-
static void serial_omap_enable_ms(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
@@ -188,22 +170,6 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct omap_uart_port_info *pdata = up->dev->platform_data;
-
- if (up->use_dma &&
- up->uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
- /*
-* Check if dma is still active. If yes do nothing,
-* return. Else stop dma
-*/
- if (omap_get_dma_active_status(up->uart_dma.tx_dma_channel))
- return;
- omap_stop_dma(up->uart_dma.tx_dma_channel);
- omap_free_dma(up->uart_dma.tx_dma_channel);
- up->uart_dma.tx_dma_channel = OMAP_UART_DMA_CH_FREE;
- pm_runtime_mark_last_busy(up->dev);
- pm_runtime_put_autosuspend(up->dev);
- }
pm_runtime_get_sync(up->dev);
if (up->ier & UART_IER_THRI) {
@@ -211,8 +177,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
- if (!up->use_dma && pdata)
- serial_omap_set_forceidle(up);
+ serial_omap_set_forceidle(up);
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
@@ -223,8 +188,6 @@ static void serial_omap_stop_rx(struct uart_port *port)
struct uart_omap_port *up = to_uart_omap_port(port);
pm_runtime_get_sync(up->dev);
- if (up->use_dma)
- serial_omap_stop_rxdma(up);
up->ier &= ~UART_IER_RLSI;
up->port.read_status_mask &= ~UART_LSR_DR;
serial_out(up, UART_IER, up->ier);
@@ -342,67 +305,12 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct circ_buf *xmit;
- unsigned int start;
- int ret = 0;
-
- if (!up->use_dma) {
- pm_runtime_get_sync(up->dev);
- serial_omap_enable_ier_thri(up);
- serial_omap_set_noidle(up);
- pm_runtime_mark_last_busy(up->dev);
- pm_runtime_put_autosuspend(up->dev);
- return;
- }
-
- if (up->uart_dma.tx_dma_used)
- return;
-
- xmit = &up->port.state->xmit;
-
- if (up->uart_dma.tx_dma_channel == OMAP_UART_DMA_CH_FREE) {
- pm_runtime_get_sync(up->dev);
- ret = omap_request_dma(up->uart_dma.uart_dma_tx,
- "UART Tx DMA",
- (void *)uart_tx_dma_callback, up,
- &(up->uart_dma.tx_dma_channel));
- if (ret < 0) {
- serial_omap_enable_ier_thri(up);
- return;
- }
- }
- spin_lock(&(up->uart_dma.tx_lock));
- up->uart_dma.tx_dma_used = true;
- spin_unlock(&(up->uart_dma.tx_lock));
-
- start = up->uart_dma.tx_buf_dma
Re: [RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
Hi, On Tue, Aug 21, 2012 at 5:30 PM, Felipe Balbi wrote: > Hi, > > On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote: >> >> + if (type & IRQ_TYPE_LEVEL_HIGH) >> >> + sg->int_lvl[bank] |= bit; >> >> + else if (type & IRQ_TYPE_LEVEL_LOW) >> >> + sg->int_lvl[bank] &= ~bit; >> >> + else >> >> + return -EINVAL; >> > >> > this looks wrong. You could have a user who wants to trigger on both >> > HIGH and LOW levels, no ? >> > >> Yes, I think there can be a scenario where gpio_keys are attached >> to this driver and signals a "key press" at low and "key release" at >> high. ? >> Will figure out a way to add support to check for case where >> both High and low levels are used. > > could probably be done on a separate patch, maybe... Just now I saw that > HIGH and LOW levels use the same bit. > If I am understanding correctly, if they both uses the same bit we cannot use both for a particular user. ? > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/13] serial: omap: refactor receive_chars() into rdi/rlsi handlers
receive_chars() was getting too big and too difficult
to follow. By splitting it into separate RDI and RSLI
handlers, we have smaller functions which are easy
to understand and only touch the pieces which they need
to touch.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 207 +++
1 file changed, 102 insertions(+), 105 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 2d3e64e..fe9852b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -195,74 +195,6 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(up->dev);
}
-static inline void receive_chars(struct uart_omap_port *up,
- unsigned int *status)
-{
- struct tty_struct *tty = up->port.state->port.tty;
- unsigned int flag, lsr = *status;
- unsigned char ch = 0;
- int max_count = 256;
-
- do {
- if (likely(lsr & UART_LSR_DR))
- ch = serial_in(up, UART_RX);
- flag = TTY_NORMAL;
- up->port.icount.rx++;
-
- if (unlikely(lsr & UART_LSR_BRK_ERROR_BITS)) {
- /*
-* For statistics only
-*/
- if (lsr & UART_LSR_BI) {
- lsr &= ~(UART_LSR_FE | UART_LSR_PE);
- up->port.icount.brk++;
- /*
-* We do the SysRQ and SAK checking
-* here because otherwise the break
-* may get masked by ignore_status_mask
-* or read_status_mask.
-*/
- if (uart_handle_break(&up->port))
- goto ignore_char;
- } else if (lsr & UART_LSR_PE) {
- up->port.icount.parity++;
- } else if (lsr & UART_LSR_FE) {
- up->port.icount.frame++;
- }
-
- if (lsr & UART_LSR_OE)
- up->port.icount.overrun++;
-
- /*
-* Mask off conditions which should be ignored.
-*/
- lsr &= up->port.read_status_mask;
-
-#ifdef CONFIG_SERIAL_OMAP_CONSOLE
- if (up->port.line == up->port.cons->index) {
- /* Recover the break flag from console xmit */
- lsr |= up->lsr_break_flag;
- }
-#endif
- if (lsr & UART_LSR_BI)
- flag = TTY_BREAK;
- else if (lsr & UART_LSR_PE)
- flag = TTY_PARITY;
- else if (lsr & UART_LSR_FE)
- flag = TTY_FRAME;
- }
-
- if (uart_handle_sysrq_char(&up->port, ch))
- goto ignore_char;
- uart_insert_char(&up->port, lsr, UART_LSR_OE, ch, flag);
-ignore_char:
- lsr = serial_in(up, UART_LSR);
- } while ((lsr & (UART_LSR_DR | UART_LSR_BI)) && (max_count-- > 0));
- spin_unlock(&up->port.lock);
- tty_flip_buffer_push(tty);
- spin_lock(&up->port.lock);
-}
-
static void transmit_chars(struct uart_omap_port *up)
{
struct circ_buf *xmit = &up->port.state->xmit;
@@ -341,6 +273,68 @@ static unsigned int check_modem_status(struct
uart_omap_port *up)
return status;
}
+static void serial_omap_rlsi(struct uart_omap_port *up, unsigned int lsr)
+{
+ unsigned int flag;
+
+ up->port.icount.rx++;
+ flag = TTY_NORMAL;
+
+ if (lsr & UART_LSR_BI) {
+ flag = TTY_BREAK;
+ lsr &= ~(UART_LSR_FE | UART_LSR_PE);
+ up->port.icount.brk++;
+ /*
+* We do the SysRQ and SAK checking
+* here because otherwise the break
+* may get masked by ignore_status_mask
+* or read_status_mask.
+*/
+ if (uart_handle_break(&up->port))
+ return;
+
+ }
+
+ if (lsr & UART_LSR_PE) {
+ flag = TTY_PARITY;
+ up->port.icount.parity++;
+ }
+
+ if (lsr & UART_LSR_FE) {
+ flag = TTY_FRAME;
+ up->port.icount.frame++;
+ }
+
+ if (lsr & UART_LSR_OE)
+ up->port.icount.overrun++;
+
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+ if (up->port.line == up->port.cons->index) {
+ /* Recover the break flag from console xmit */
+ lsr |= up->lsr_break_flag;
+ }
+#endif
+ uart_insert_ch
[PATCH v2 08/13] serial: omap: move THRE check to transmit_chars()
since all other IRQ types now do all necessary
checks inside their handlers, transmit_chars()
was the only one left expecting serial_omap_irq()
to check THRE for it. We can move THRE check to
transmit_chars() in order to make serial_omap_irq()
more uniform.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index fe9852b..bb63dc9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -195,11 +195,14 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(up->dev);
}
-static void transmit_chars(struct uart_omap_port *up)
+static void transmit_chars(struct uart_omap_port *up, unsigned int lsr)
{
struct circ_buf *xmit = &up->port.state->xmit;
int count;
+ if (!(lsr & UART_LSR_THRE))
+ return;
+
if (up->port.x_char) {
serial_out(up, UART_TX, up->port.x_char);
up->port.icount.tx++;
@@ -370,8 +373,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
check_modem_status(up);
break;
case UART_IIR_THRI:
- if (lsr & UART_LSR_THRE)
- transmit_chars(up);
+ transmit_chars(up, lsr);
break;
case UART_IIR_RX_TIMEOUT:
/* FALLTHROUGH */
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/13] serial: add OMAP-specific defines
OMAP has some extra Interrupt types which can be really useful for SW. Let's define them so we can later use those in OMAP's serial driver. Acked-by: Santosh Shilimkar Signed-off-by: Felipe Balbi --- include/linux/serial_reg.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 8ce70d7..5ed325e 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -40,6 +40,10 @@ #define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ +#define UART_IIR_RX_TIMEOUT0x0c /* OMAP RX Timeout interrupt */ +#define UART_IIR_XOFF 0x10 /* OMAP XOFF/Special Character */ +#define UART_IIR_CTS_RTS_DSR 0x20 /* OMAP CTS/RTS/DSR Change */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR0x02 /* Clear the RCVR FIFO */ -- 1.7.12.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/13] serial: omap: define helpers for pdata function pointers
this patch is in preparation to a few other changes
which will align on the prototype for function
pointers passed through pdata.
It also helps cleaning up the driver a little by
agregating checks for pdata in a single location.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 66
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 5c0d0bc..6814a26 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -101,6 +101,40 @@ static inline void serial_omap_clear_fifos(struct
uart_omap_port *up)
serial_out(up, UART_FCR, 0);
}
+static int serial_omap_get_context_loss_count(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+
+ if (!pdata->get_context_loss_count)
+ return 0;
+
+ return pdata->get_context_loss_count(&up->pdev->dev);
+}
+
+static void serial_omap_set_forceidle(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+
+ if (pdata->set_forceidle)
+ pdata->set_forceidle(up->pdev);
+}
+
+static void serial_omap_set_noidle(struct uart_omap_port *up)
+{
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+
+ if (pdata->set_noidle)
+ pdata->set_noidle(up->pdev);
+}
+
+static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
+{
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+
+ if (pdata->enable_wakeup)
+ pdata->enable_wakeup(up->pdev, enable);
+}
+
/*
* serial_omap_get_divisor - calculate divisor value
* @port: uart port info
@@ -177,8 +211,8 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up->ier);
}
- if (!up->use_dma && pdata && pdata->set_forceidle)
- pdata->set_forceidle(up->pdev);
+ if (!up->use_dma && pdata)
+ serial_omap_set_forceidle(up);
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
@@ -308,7 +342,6 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = to_uart_omap_port(port);
- struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
struct circ_buf *xmit;
unsigned int start;
int ret = 0;
@@ -316,8 +349,7 @@ static void serial_omap_start_tx(struct uart_port *port)
if (!up->use_dma) {
pm_runtime_get_sync(&up->pdev->dev);
serial_omap_enable_ier_thri(up);
- if (pdata && pdata->set_noidle)
- pdata->set_noidle(up->pdev);
+ serial_omap_set_noidle(up);
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
return;
@@ -1648,28 +1680,26 @@ static int serial_omap_runtime_suspend(struct device
*dev)
if (!up)
return -EINVAL;
- if (!pdata || !pdata->enable_wakeup)
+ if (!pdata)
return 0;
- if (pdata->get_context_loss_count)
- up->context_loss_cnt = pdata->get_context_loss_count(dev);
+ up->context_loss_cnt = serial_omap_get_context_loss_count(up);
if (device_may_wakeup(dev)) {
if (!up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, true);
+ serial_omap_enable_wakeup(up, true);
up->wakeups_enabled = true;
}
} else {
if (up->wakeups_enabled) {
- pdata->enable_wakeup(up->pdev, false);
+ serial_omap_enable_wakeup(up, false);
up->wakeups_enabled = false;
}
}
/* Errata i291 */
- if (up->use_dma && pdata->set_forceidle &&
- (up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
- pdata->set_forceidle(up->pdev);
+ if (up->use_dma && (up->errata & UART_ERRATA_i291_DMA_FORCEIDLE))
+ serial_omap_set_forceidle(up);
up->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
schedule_work(&up->qos_work);
@@ -1683,17 +1713,15 @@ static int serial_omap_runtime_resume(struct device
*dev)
struct omap_uart_port_info *pdata = dev->platform_data;
if (up && pdata) {
- if (pdata->get_context_loss_count) {
- u32 loss_cnt = pdata->get_context_loss_count(dev);
+ u32 loss_cnt = serial_omap_get_context_loss_count(up);
if (up->context_loss_cnt != loss_cnt)
serial_omap_restore
[PATCH v2 00/13] OMAP Serial patches
Hi guys, here's a series of cleanup patches to the OMAP serial driver. A later series could be made re-implementing DMA using the DMA Engine API. Note that for RX DMA we could be using RX Timeout IRQ as a hint that we better use PIO instead ;-) All patches were tested on my pandaboard, but I'd really like to receive Tested-by on other platforms. After this goes in, I'll probably try to get UART wakeup working again and only after that look at DMA. Changes since v1: . improved commit log on patch 9/13 (formerly 10/13) . removed patch 2/13 . added a new patch switching from spin_lock_irqsave() to spin_lock and spin_unlock_irqrestore to spin_unlock Retested with my pandaboard, UART continues to work: # grep -i uart /proc/interrupts 106:124 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:189 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:255 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:321 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:387 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:453 0 GIC OMAP UART2 # grep -i uart /proc/interrupts 106:519 0 GIC OMAP UART2 cheers ps: if anyone knows a better test for UART, let me know. for convenience of anyone testing, patches are available on my git tree [1] on branch uart [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart Felipe Balbi (13): serial: omap: define and use to_uart_omap_port() serial: omap: define helpers for pdata function pointers serial: omap: don't access the platform_device serial: omap: drop DMA support serial: add OMAP-specific defines serial: omap: simplify IRQ handling serial: omap: refactor receive_chars() into rdi/rlsi handlers serial: omap: move THRE check to transmit_chars() serial: omap: stick to put_autosuspend serial: omap: set dev->drvdata before enabling pm_runtime serial: omap: drop unnecessary check from remove serial: omap: make sure to suspend device before remove serial: omap: don't save IRQ flags on hardirq arch/arm/mach-omap2/serial.c | 15 +- arch/arm/plat-omap/include/plat/omap-serial.h | 12 +- drivers/tty/serial/omap-serial.c | 713 +- include/linux/serial_reg.h| 4 + 4 files changed, 254 insertions(+), 490 deletions(-) -- 1.7.12.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/13] serial: omap: set dev->drvdata before enabling pm_runtime
by the time we call our first pm_runtme_get_sync() after enable pm_runtime, our resume method might be called. To avoid problems, we must make sure that our dev->drvdata is set correctly before our resume method gets called. Acked-by: Santosh Shilimkar Signed-off-by: Felipe Balbi --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index c272ecc..1aaba77 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1301,6 +1301,7 @@ static int serial_omap_probe(struct platform_device *pdev) serial_omap_uart_wq = create_singlethread_workqueue(up->name); INIT_WORK(&up->qos_work, serial_omap_uart_qos_work); + platform_set_drvdata(pdev, up); pm_runtime_use_autosuspend(&pdev->dev); pm_runtime_set_autosuspend_delay(&pdev->dev, omap_up_info->autosuspend_timeout); @@ -1320,7 +1321,6 @@ static int serial_omap_probe(struct platform_device *pdev) pm_runtime_mark_last_busy(up->dev); pm_runtime_put_autosuspend(up->dev); - platform_set_drvdata(pdev, up); return 0; err_add_port: -- 1.7.12.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 11/13] serial: omap: drop unnecessary check from remove
if platform_get_drvdata() returns NULL, that's
quite a nasty bug on the driver which we want to
catch ASAP. Otherwise, that check is hugely
unneeded.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 1aaba77..2e1a33a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1337,13 +1337,10 @@ static int serial_omap_remove(struct platform_device
*dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
- if (up) {
- pm_runtime_disable(up->dev);
- uart_remove_one_port(&serial_omap_reg, &up->port);
- pm_qos_remove_request(&up->pm_qos_request);
- }
+ pm_runtime_disable(up->dev);
+ uart_remove_one_port(&serial_omap_reg, &up->port);
+ pm_qos_remove_request(&up->pm_qos_request);
- platform_set_drvdata(dev, NULL);
return 0;
}
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/13] serial: omap: stick to put_autosuspend
Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. The idea behind this patch is to make sure we will always reinitialize the pm timer so that we don't fall into a situation where pm_runtime_put() expires right away (if timer was already about to expire when we made the call to pm_runtime_put()). While suspending right away wouldn't cause any issues, reinitializing the pm timer can help us avoiding unnecessary context save & restore operations (which are somewhat expensive) if there's another read/write/set_termios request coming right after. IOW, we are trying to make sure UART is still powered up while it's still under heavy usage. Acked-by: Santosh Shilimkar Signed-off-by: Felipe Balbi --- drivers/tty/serial/omap-serial.c | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index bb63dc9..c272ecc 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port *port) pm_runtime_get_sync(up->dev); up->ier |= UART_IER_MSI; serial_out(up, UART_IER, up->ier); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static void serial_omap_stop_tx(struct uart_port *port) @@ -415,7 +416,8 @@ static unsigned int serial_omap_tx_empty(struct uart_port *port) spin_lock_irqsave(&up->port.lock, flags); ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0; spin_unlock_irqrestore(&up->port.lock, flags); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); return ret; } @@ -427,7 +429,8 @@ static unsigned int serial_omap_get_mctrl(struct uart_port *port) pm_runtime_get_sync(up->dev); status = check_modem_status(up); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line); @@ -463,7 +466,8 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl) up->mcr = serial_in(up, UART_MCR); up->mcr |= mcr; serial_out(up, UART_MCR, up->mcr); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static void serial_omap_break_ctl(struct uart_port *port, int break_state) @@ -480,7 +484,8 @@ static void serial_omap_break_ctl(struct uart_port *port, int break_state) up->lcr &= ~UART_LCR_SBC; serial_out(up, UART_LCR, up->lcr); spin_unlock_irqrestore(&up->port.lock, flags); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static int serial_omap_startup(struct uart_port *port) @@ -578,7 +583,8 @@ static void serial_omap_shutdown(struct uart_port *port) if (serial_in(up, UART_LSR) & UART_LSR_DR) (void) serial_in(up, UART_RX); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); free_irq(up->port.irq, up); } @@ -849,7 +855,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_omap_configure_xonxoff(up, termios); spin_unlock_irqrestore(&up->port.lock, flags); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line); } @@ -880,7 +887,8 @@ serial_omap_pm(struct uart_port *port, unsigned int state, pm_runtime_allow(up->dev); } - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static void serial_omap_release_port(struct uart_port *port) @@ -962,7 +970,8 @@ static void serial_omap_poll_put_char(struct uart_port *port, unsigned char ch) pm_runtime_get_sync(up->dev); wait_for_xmitr(up); serial_out(up, UART_TX, ch); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static int serial_omap_poll_get_char(struct uart_port *port) @@ -976,7 +985,8 @@ static int serial_omap_poll_get_char(struct uart_port *port) return NO_POLL_CHAR; status = serial_in(up, UART_RX); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); return status; } @@ -1308,7 +1318,8 @@ static int serial_omap_probe(struct platform_device *pdev)
[PATCH v2 12/13] serial: omap: make sure to suspend device before remove
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 2e1a33a..b79c4fa 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1337,6 +1337,7 @@ static int serial_omap_remove(struct platform_device *dev)
{
struct uart_omap_port *up = platform_get_drvdata(dev);
+ pm_runtime_put_sync(up->dev);
pm_runtime_disable(up->dev);
uart_remove_one_port(&serial_omap_reg, &up->port);
pm_qos_remove_request(&up->pm_qos_request);
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 13/13] serial: omap: don't save IRQ flags on hardirq
When we're running our hardirq handler, there's
not need to disable IRQs with spin_lock_irqsave()
because IRQs are already disabled. It also makes
no difference if we save or not IRQ flags.
Switch over to simple spin_lock/spin_unlock and
drop the "flags" variable.
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b79c4fa..a79658d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -350,11 +350,10 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
struct tty_struct *tty = up->port.state->port.tty;
unsigned int iir, lsr;
unsigned int type;
- unsigned long flags;
irqreturn_t ret = IRQ_HANDLED;
int max_count = 256;
- spin_lock_irqsave(&up->port.lock, flags);
+ spin_lock(&up->port.lock);
pm_runtime_get_sync(up->dev);
do {
@@ -394,7 +393,7 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
}
} while (!(iir & UART_IIR_NO_INT) && max_count--);
- spin_unlock_irqrestore(&up->port.lock, flags);
+ spin_unlock(&up->port.lock);
tty_flip_buffer_push(tty);
--
1.7.12.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/13] serial: omap: simplify IRQ handling
quite a few changes here, though they are
pretty obvious. In summary we're making sure
to detect which interrupt type we need to
handle before calling the underlying interrupt
handling procedure.
Acked-by: Santosh Shilimkar
Signed-off-by: Felipe Balbi
---
drivers/tty/serial/omap-serial.c | 48 +++-
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 16808b6..2d3e64e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -350,33 +350,59 @@ static inline irqreturn_t serial_omap_irq(int irq, void
*dev_id)
{
struct uart_omap_port *up = dev_id;
unsigned int iir, lsr;
+ unsigned int type;
unsigned long flags;
+ irqreturn_t ret = IRQ_HANDLED;
+ spin_lock_irqsave(&up->port.lock, flags);
pm_runtime_get_sync(up->dev);
iir = serial_in(up, UART_IIR);
+again:
if (iir & UART_IIR_NO_INT) {
- pm_runtime_mark_last_busy(up->dev);
- pm_runtime_put_autosuspend(up->dev);
- return IRQ_NONE;
+ ret = IRQ_NONE;
+ goto out;
}
- spin_lock_irqsave(&up->port.lock, flags);
lsr = serial_in(up, UART_LSR);
- if (iir & UART_IIR_RLSI) {
+
+ /* extract IRQ type from IIR register */
+ type = iir & 0x3e;
+
+ switch (type) {
+ case UART_IIR_MSI:
+ check_modem_status(up);
+ break;
+ case UART_IIR_THRI:
+ if (lsr & UART_LSR_THRE)
+ transmit_chars(up);
+ break;
+ case UART_IIR_RDI:
if (lsr & UART_LSR_DR)
receive_chars(up, &lsr);
+ break;
+ case UART_IIR_RLSI:
+ if (lsr & UART_LSR_BRK_ERROR_BITS)
+ receive_chars(up, &lsr);
+ break;
+ case UART_IIR_RX_TIMEOUT:
+ receive_chars(up, &lsr);
+ break;
+ case UART_IIR_CTS_RTS_DSR:
+ iir = serial_in(up, UART_IIR);
+ goto again;
+ case UART_IIR_XOFF:
+ /* FALLTHROUGH */
+ default:
+ break;
}
- check_modem_status(up);
- if ((lsr & UART_LSR_THRE) && (iir & UART_IIR_THRI))
- transmit_chars(up);
-
+out:
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_mark_last_busy(up->dev);
pm_runtime_put_autosuspend(up->dev);
-
up->port_activity = jiffies;
- return IRQ_HANDLED;
+
+ return ret;
}
static unsigned int serial_omap_tx_empty(struct uart_port *port)
--
1.7.12.rc3
--
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: [alsa-devel] [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 07:28:34AM +0200, Takashi Iwai wrote: > Ricardo Neri wrote: > > I was wondering about how much sense does it make to you guys use a > > snd_soc_jack in this case? > HD-audio already uses the generic jack event for the HDMI/DP > connection change notification as well, so I think it would make sense > in general. The whole problem here is that we don't *have* a generic jack interface. We've got: - sound/core/jack.c which was written to be a generic API and is used by everything that does jack support currently. - sound/core/ctljack.c which was added later and provides separate in-kernel and userspace APIs and is currently only used by HDA. - extcon which does have a good reason to be a separate API since that it's not audio specific (and is likely to be picked up by Android as the code was originally taken from there); it's currently not supported by the frameworks in ALSA. I'd suggest Pulse should be using it too. This is a complete shambles for both driver authors and userspace, the ABI varies randomly with drivers and in theory driver authors have to implement everything three times which is just nuts. What I'd like to see happening is that we merge ctljack into jack (since only HDA is going to be affected by that change it seems like the right direction to make the merge) and also add extcon support, I have looked at the extcon support. Short term for drivers used on embedded systems I'd have to recommend extcon rather than anything ALSA-specific. signature.asc Description: Digital signature
Re: [RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
Hi, On Tue, Aug 21, 2012 at 05:17:37PM +0530, Poddar, Sourav wrote: > >> + if (type & IRQ_TYPE_LEVEL_HIGH) > >> + sg->int_lvl[bank] |= bit; > >> + else if (type & IRQ_TYPE_LEVEL_LOW) > >> + sg->int_lvl[bank] &= ~bit; > >> + else > >> + return -EINVAL; > > > > this looks wrong. You could have a user who wants to trigger on both > > HIGH and LOW levels, no ? > > > Yes, I think there can be a scenario where gpio_keys are attached > to this driver and signals a "key press" at low and "key release" at > high. ? > Will figure out a way to add support to check for case where > both High and low levels are used. could probably be done on a separate patch, maybe... Just now I saw that HIGH and LOW levels use the same bit. -- balbi signature.asc Description: Digital signature
Re: [RFC/PATCH 02/13] serial: omap: always return IRQ_HANDLED
On Tue, Aug 21, 2012 at 12:50:05PM +0100, Alan Cox wrote: > On Tue, 21 Aug 2012 12:15:44 +0300 > Felipe Balbi wrote: > > > Even if we enter our IRQ handler just to notice > > that the our device didn't generate the IRQ, > > that still means "handling" and IRQ, so let's > > return IRQ_HANDLED. > > That looks wrong - you'll defeat the stuck IRQ protection. If we didn't > cause the IRQ then we are IRQ_NONE ? that's true. I'll drop this patch from the list. My bad. -- balbi signature.asc Description: Digital signature
Re: [RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
Hi,
On Tue, Aug 21, 2012 at 4:23 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 21, 2012 at 04:15:40PM +0530, Sourav Poddar wrote:
>> smsc can be used as an gpio io expander device also. So adding
>> support for configuring smsc pins as a gpio.
>>
>> Cc: Benoit Cousson
>> Cc: Felipe Balbi
>> Cc: Santosh Shilimkar
>> Signed-off-by: Sourav Poddar
>> ---
>> drivers/gpio/Kconfig|7 +
>> drivers/gpio/Makefile |1 +
>> drivers/gpio/gpio-smscece.c | 373
>> +++
>> 3 files changed, 381 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/gpio/gpio-smscece.c
>>
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index b16c8a7..e883929 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
>> Say yes here to enable the adp5588 to be used as an interrupt
>> controller. It requires the driver to be built in the kernel.
>>
>> +config GPIO_SMSCECE
>> + tristate "SMSCECE 1099 I2C GPIO expander"
>> + depends on I2C
>> + help
>> + This option enables support for 18 GPIOs found
>> + on SMSC ECE 1099 GPIO Expanders.
>> +
>> comment "PCI GPIO expanders:"
>>
>> config GPIO_CS5535
>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
>> index 153cace..7c803c5 100644
>> --- a/drivers/gpio/Makefile
>> +++ b/drivers/gpio/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
>> obj-$(CONFIG_GPIO_AB8500)+= gpio-ab8500.o
>> obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
>> obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
>> +obj-$(CONFIG_GPIO_SMSCECE) += gpio-smscece.o
>> obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
>> obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
>> obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
>> diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
>> new file mode 100644
>> index 000..0cb0959
>> --- /dev/null
>> +++ b/drivers/gpio/gpio-smscece.c
>> @@ -0,0 +1,373 @@
>> +/*
>> + * GPIO Chip driver for smsc
>> + * SMSC I/O Expander and QWERTY Keypad Controller
>> + *
>> + * Copyright 2012 Texas Instruments Inc.
>> + *
>> + * Licensed under the GPL-2 or later.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +struct smsc_gpio {
>> + struct device *dev;
>> + struct smsc *smsc;
>> + struct gpio_chip gpio_chip;
>> + struct mutex lock; /* protect cached dir, dat_out */
>> + /* protect serialized access to the interrupt controller bus */
>> + struct mutex irq_lock;
>> + unsigned gpio_start;
>> + int type;
>> + int flags;
>> + int irq;
>> + int irq_base;
>> + unsigned int gpio_base;
>> + unsigned int dat_out[5];
>> + unsigned int dir[5];
>> + unsigned int int_lvl[5];
>> + unsigned int int_en[5];
>> + unsigned int irq_mask[5];
>> + unsigned int irq_stat[5];
>> +};
>> +
>> +static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
>> +{
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> + unsigned int get;
>> + return !!(smsc_read(sg->dev,
>> + (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off)) & SMSC_BIT(off),
>> + &get));
>> +}
>> +
>> +static void smsc_gpio_set_value(struct gpio_chip *chip,
>> + unsigned off, int val)
>> +{
>> + unsigned bank, bit;
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> +
>> + bank = SMSC_BANK(off);
>> + bit = SMSC_BIT(off);
>> +
>> + mutex_lock(&sg->lock);
>> + if (val)
>> + sg->dat_out[bank] |= bit;
>> + else
>> + sg->dat_out[bank] &= ~bit;
>> +
>> + smsc_write(sg->dev, SMSC_GPIO_DATA_OUT_START + bank,
>> +sg->dat_out[bank]);
>> + mutex_unlock(&sg->lock);
>> +}
>> +
>> +static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
>> +{
>> + unsigned int reg;
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> + int reg_dir;
>> +
>> + mutex_lock(&sg->lock);
>> + reg_dir = SMSC_CFG_START + off;
>> + smsc_read(sg->dev, reg_dir, ®);
>> + reg |= SMSC_GPIO_INPUT_LOW;
>> + mutex_unlock(&sg->lock);
>> +
>> + return smsc_write(sg->dev, reg_dir, reg);
>> +}
>> +
>> +static int smsc_gpio_direction_output(struct gpio_chip *chip,
>> + unsigned off, int val)
>> +{
>> + unsigned int reg;
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> + int reg_dir;
>> +
>> + mutex_lock(&sg->lock);
>> + reg_dir = SMSC_CFG_START + off;
>> + smsc_read(sg->dev, reg_dir, ®);
>> + reg |= SMSC_GPIO_OUTPUT_PP;
>> + mutex_un
Re: [PATCH v6 01/10] ARM: OMAP2+: nand: unify init functions
Hi Afzal, Thanks for the patches! On 08/21/12 13:45, Afzal Mohammed wrote: > Helper function for updating nand platform data has been > added the capability to take timing structure arguement. > Usage of omap_nand_flash_init() has been replaced by modifed > one, omap_nand_flash_init was doing things similar to > board_nand_init except that NAND CS# were being acquired > based on bootloader setting. As CS# is hardwired for a given > board, acquiring gpmc CS# has been removed, and updated with > the value on board. > > NAND CS# used in beagle board & omap3evm was found to be CS0. > Thomas Weber reported > that value of devkit8000 to be CS0. Overo board was found > to be using CS0 based on u-boot, while google grep says > omap3touchbook too has CS0. > > Signed-off-by: Afzal Mohammed > Reviewed-by: Jon Hunter Acked-by: Igor Grinberg -- Regards, Igor. -- 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 02/13] serial: omap: always return IRQ_HANDLED
On Tue, 21 Aug 2012 12:15:44 +0300 Felipe Balbi wrote: > Even if we enter our IRQ handler just to notice > that the our device didn't generate the IRQ, > that still means "handling" and IRQ, so let's > return IRQ_HANDLED. That looks wrong - you'll defeat the stuck IRQ protection. If we didn't cause the IRQ then we are IRQ_NONE ? -- 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 2/4] Input: keypad: Add smsc ece1099 keypad driver
Hi,
On Tue, Aug 21, 2012 at 4:16 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
>> +static struct platform_driver smsc_driver = {
>> + .driver = {
>> + .name = "smsc-keypad",
>> + .of_match_table = of_match_ptr(smsc_keypad_dt_match),
>> + .owner = THIS_MODULE,
>> + },
>> + .probe = smsc_probe,
>> + .remove = smsc_remove,
>
> one extra comment which I forgot. You probably should put your remove on
> __devexit and add __devexit_p(smsc_remove) here.
>
yes, Will do it.
> --
> balbi
--
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 2/4] Input: keypad: Add smsc ece1099 keypad driver
Hi,
On Tue, Aug 21, 2012 at 4:15 PM, Felipe Balbi wrote:
> On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
>> From: G, Manjunath Kondaiah
>>
>> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
>> supports a keypad scan matrix of 23*8.This driver uses this
>> device as a keypad driver.
>>
>> Cc: Dmitry Torokhov
>> Cc: Benoit Cousson
>> Cc: Felipe Balbi
>> Cc: Santosh Shilimkar
>> Signed-off-by: G, Manjunath Kondaiah
>> Signed-off-by: Sourav Poddar
>
> looks good. If you just fix my comment on free_irq() below, you can add:
>
> Acked-by: Felipe Balbi
>
>> +static int __devinit
>> +smsc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct smsc *smsc = dev_get_drvdata(pdev->dev.parent);
>> + struct input_dev *input;
>> + struct smsc_keypad *kp;
>> + int ret = 0, error;
>> + int col, i, max_keys, row_shift;
>> + int irq;
>> + int addr_start, addr;
>> +
>> + kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
>> +
>> + input = input_allocate_device();
>> + if (!kp || !input) {
>> + error = -ENOMEM;
>> + goto err1;
>> + }
>> +
>> + error = smsc_keypad_parse_dt(&pdev->dev, kp);
>> + if (error)
>> + return error;
>> +
>> + /* Get the debug Device */
>> + kp->input = input;
>> + kp->smsc = smsc;
>> + kp->irq = platform_get_irq(pdev, 0);
>> + kp->dev = dev;
>> +
>> + for (col = 0; col < 16; col++) {
>> + kp->last_key_state[col] = 0;
>> + kp->last_key_ms[col] = 0;
>> + }
>> +
>> + /* setup input device */
>> + __set_bit(EV_KEY, input->evbit);
>> +
>> + /* Enable auto repeat feature of Linux input subsystem */
>> + if (!(kp->no_autorepeat))
>> + __set_bit(EV_REP, input->evbit);
>> +
>> + input_set_capability(input, EV_MSC, MSC_SCAN);
>> + input->name = "SMSC Keypad";
>> + input->phys = "smsc_keypad/input0";
>> + input->dev.parent = &pdev->dev;
>> + input->id.bustype = BUS_HOST;
>> + input->id.vendor= 0x0001;
>> + input->id.product = 0x0001;
>> + input->id.version = 0x0003;
>> +
>> + error = input_register_device(input);
>> + if (error) {
>> + dev_err(kp->dev,
>> + "Unable to register twl4030 keypad device\n");
>> + goto err1;
>> + }
>> +
>> + /* Mask all GPIO interrupts (0x37-0x3B) */
>> + for (addr = 0x37; addr < 0x3B; addr++)
>> + smsc_write(dev, addr, 0);
>> +
>> + /* Set all outputs high (0x05-0x09) */
>> + for (addr = 0x05; addr < 0x09; addr++)
>> + smsc_write(dev, addr, 0xff);
>> +
>> + /* Clear all GPIO interrupts (0x32-0x36) */
>> + for (addr = 0x32; addr < 0x36; addr++)
>> + smsc_write(dev, addr, 0xff);
>> +
>> + addr_start = 0x12;
>> + for (i = 0; i <= kp->rows; i++) {
>> + addr = 0x12 + i;
>> + smsc_write(dev, addr, SMSC_KP_KSI);
>> + }
>> +
>> + addr_start = 0x1A;
>> + for (i = 0; i <= kp->cols; i++) {
>> + addr = 0x1A + i;
>> + smsc_write(dev, addr, SMSC_KP_KSO);
>> + }
>> +
>> + addr = SMSC_KP_INT_STAT;
>> + smsc_write(dev, addr, SMSC_KP_SET_HIGH);
>> +
>> + addr = SMSC_WKUP_CTRL;
>> + smsc_write(dev, addr, SMSC_KP_SET_LOW_PWR);
>> +
>> + addr = SMSC_KP_OUT;
>> + smsc_write(dev, addr, SMSC_KSO_ALL_LOW);
>> +
>> + row_shift = get_count_order(kp->cols);
>> + max_keys = kp->rows << row_shift;
>> +
>> + kp->row_shift = row_shift;
>> + kp->keymap = kzalloc(max_keys * sizeof(kp->keymap[0]),
>> + GFP_KERNEL);
>> + if (!kp->keymap) {
>> + dev_err(&pdev->dev, "Not enough memory for keymap\n");
>> + error = -ENOMEM;
>> + }
>> +
>> + matrix_keypad_build_keymap(NULL, NULL, kp->rows,
>> + kp->cols, kp->keymap, input);
>> +
>> + /*
>> + * This ISR will always execute in kernel thread context because of
>> + * the need to access the SMSC over the I2C bus.
>> + */
>> + ret = devm_request_threaded_irq(dev, kp->irq, NULL, do_kp_irq,
>> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev->name, kp);
>> + if (ret) {
>> + dev_dbg(&pdev->dev, "request_irq failed for irq no=%d\n",
>> + irq);
>> + goto err2;
>> + }
>> +
>> + /* Enable smsc keypad interrupts */
>> + ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
>> + if (ret < 0)
>> + goto err2;
>> +
>> + return 0;
>> +
>> +err2:
>> + input_unregister_device(input);
>> + free_irq(kp->irq, NULL);
>
> you're using devm_request_threaded_irq, this is unnecessary
>
True. Will remove "free_irq" from the code.
>> +err1:
>> + input_free_device(input);
>> + return ret;
>> +}
>> +
>> +static int smsc_remove(struct
Re: [PATCH 3/4] arm/dts: omap5-evm: Add keypad support
Hi,
On Tue, Aug 21, 2012 at 4:17 PM, Felipe Balbi wrote:
> On Tue, Aug 21, 2012 at 04:15:39PM +0530, Sourav Poddar wrote:
>> Add keypad data node in omap5-evm.
>>
>> Based on I2C support patch for omap5, which has been
>> already posted as a different series.
>>
>> Cc: Benoit Cousson
>> Cc: Felipe Balbi
>> Cc: Santosh Shilimkar
>> Tested on omap5430 sdp with 3.5 custom kernel.
>>
>> Signed-off-by: Sourav Poddar
>
> after fixing my only comment below, you can add my:
>
> Acked-by: Felipe Balbi
>
>> ---
>> arch/arm/boot/dts/omap5-evm.dts | 95
>> +++
>> 1 files changed, 95 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap5-evm.dts
>> b/arch/arm/boot/dts/omap5-evm.dts
>> index 200c39a..6473983 100644
>> --- a/arch/arm/boot/dts/omap5-evm.dts
>> +++ b/arch/arm/boot/dts/omap5-evm.dts
>> @@ -18,3 +18,98 @@
>> reg = <0x8000 0x4000>; /* 1 GB */
>> };
>> };
>> +
>> +&i2c5 {
>> + clock-frequency = <40>;
>> +
>> + smsc@38 {
>> + compatible = "smsc";
>> + reg = <0x38>;
>> + clock = <0x13>;
>> + keypad {
>> + compatible = "smsc,keypad";
>> + interrupt-parent = <&gpio5>;
>> + interrupts = <23>; /* gpio line 151 */
>> + keypad,num-rows = <8>;
>> + keypad,num-columns = <16>;
>> + linux,keymap = < 0x20041 /*KEY_F7*/
>
> please add spaces around /* and */ so it's easier to read. Ditto to all
> others.
>
Yes, will add spaces in the new version.
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
On Tue, 2012-08-21 at 16:36 +0530, Mahapatra, Chandrabhanu wrote:
> On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen wrote:
> > On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
> >> All the cpu_is checks have been moved to dss_init_features function
> >> providing a
> >> much more generic and cleaner interface. The OMAP version and revision
> >> specific
> >> initializations in various functions are cleaned and the necessary data are
> >> moved to dss_features structure which is local to dss.c.
> >>
> >> Signed-off-by: Chandrabhanu Mahapatra
> >> ---
> >> drivers/video/omap2/dss/dss.c | 117
> >> ++---
> >> 1 file changed, 76 insertions(+), 41 deletions(-)
> >>
> >> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> >> index 10566ae..f6d3d0a 100644
> >> --- a/drivers/video/omap2/dss/dss.c
> >> +++ b/drivers/video/omap2/dss/dss.c
> >> @@ -31,6 +31,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >>
> >> @@ -65,6 +66,12 @@ struct dss_reg {
> >> static int dss_runtime_get(void);
> >> static void dss_runtime_put(void);
> >>
> >> +struct dss_features {
> >> + u16 fck_div_max;
> >> + int dss_fck_multiplier;
> >> + char *clk_name;
> >
> > const char *
> >
> > Tomi
> >
>
> All the values are const. So we have a const pointer dss.feat to hold
> this structure. Is a separate
> const char *clk_name required?
Yes, the values are const, so the pointer itself is const. However, the
chars where the pointer points are not const. So:
feat.clk_name = 1234; // this is rejected by the compiler
feat.clk_name[0] = 0; // this would be accepted
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH V5 1/6] OMAPDSS: DISPC: cleanup cpu_is_xxxx checks
On Tue, Aug 21, 2012 at 4:01 PM, Tomi Valkeinen wrote:
> On Mon, 2012-08-20 at 18:52 +0530, Chandrabhanu Mahapatra wrote:
>> All the cpu_is checks have been moved to dispc_init_features function
>> providing
>> a much more generic and cleaner interface. The OMAP version and revision
>> specific functions and data are initialized by dispc_features structure
>> which is
>> local to dispc.c.
>>
>> Signed-off-by: Chandrabhanu Mahapatra
>> ---
>> drivers/video/omap2/dss/dispc.c | 433
>> +--
>> 1 file changed, 278 insertions(+), 155 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dispc.c
>> b/drivers/video/omap2/dss/dispc.c
>> index ff52702..3fad33a 100644
>> --- a/drivers/video/omap2/dss/dispc.c
>> +++ b/drivers/video/omap2/dss/dispc.c
>> @@ -81,6 +81,23 @@ struct dispc_irq_stats {
>> unsigned irqs[32];
>> };
>>
>> +struct dispc_features {
>> + int hp_max;
>> + int vp_max;
>> + int sw_max;
>> + int sw_start;
>> + int fp_start;
>> + int bp_start;
>
> Here you could use a bit smaller datatype. u16 should probably be more
> than enough.
>
After looking at the values that these variables take I think hp_max,
vp_max and sw_max can be u16 and the rest three sw_start, fp_start and
bp_start can be u8.
>> +static int __init dispc_init_features(struct device *dev)
>> +{
>> + struct dispc_features *feat = devm_kzalloc(dev, sizeof(*feat),
>> + GFP_KERNEL);
>> + if (!feat) {
>> + dev_err(dev, "Failed to allocate DISPC Features\n");
>> + return -ENOMEM;
>> + }
>> +
>> + if (cpu_is_omap24xx()) {
>> + memcpy(feat, &omap24xx_dispc_feats, sizeof(*feat));
>> + } else if (cpu_is_omap34xx()) {
>> + if (omap_rev() < OMAP3430_REV_ES3_0)
>> + memcpy(feat, &omap34xx_rev1_0_dispc_feats,
>> + sizeof(*feat));
>> + else
>> + memcpy(feat, &omap34xx_rev3_0_dispc_feats,
>> + sizeof(*feat));
>> + } else if (cpu_is_omap44xx()) {
>> + memcpy(feat, &omap44xx_dispc_feats, sizeof(*feat));
>> + } else {
>> + return -ENODEV;
>> + }
>> +
>> + dispc.feat = feat;
>> +
>> + return 0;
>> +}
>
> This becomes much cleaner with something like the following (same could
> be used in dss.c also):
>
> const struct dispc_features *src;
> struct dispc_features *dst;
>
> dst = devm_kzalloc(dev, sizeof(*dst), GFP_KERNEL);
> if (!dsst) {
> dev_err(dev, "Failed to allocate DISPC Features\n");
> return -ENOMEM;
> }
>
> if (cpu_is_omap24xx()) {
> src = &omap24xx_dispc_feats;
> } else if (cpu_is_omap34xx()) {
> if (omap_rev() < OMAP3430_REV_ES3_0)
> src = &omap34xx_rev1_0_dispc_feats;
> else
> src = &omap34xx_rev3_0_dispc_feats;
> } else if (cpu_is_omap44xx()) {
> src = &omap44xx_dispc_feats;
> } else {
> return -ENODEV;
> }
>
> memcpy(dst, src, sizeof(*dst));
>
> dispc.feat = dst;
>
> Tomi
>
ok, looks cleaner.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. 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
[PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts
Add tps65217 regulator device tree data to AM335x-Bone by adding
regulator consumers with tightened constraints and regulator-name.
TPS65217 regulator handle can be obtained by using this regulator
name.
This patch also add I2C node with I2C frequency and tps65217 PMIC
I2C slave address.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-bone.dts | 54 +
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 58f5042..f1c2772 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -36,5 +36,59 @@
uart1: serial@44E09000 {
status = "okay";
};
+
+ i2c1: i2c@44E0B000 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ tps: tps@24 {
+ reg = <0x24>;
+ };
+
+ };
+ };
+};
+
+/include/ "tps65217.dtsi"
+
+&tps {
+ regulators {
+ dcdc1_reg: regulator@0 {
+ regulator-always-on;
+ };
+
+ dcdc2_reg: regulator@1 {
+ /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%
tolerance */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1325000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3_reg: regulator@2 {
+ /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4%
tolerance */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <115>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: regulator@3 {
+ regulator-always-on;
+ };
+
+ ldo2_reg: regulator@4 {
+ regulator-always-on;
+ };
+
+ ldo3_reg: regulator@5 {
+ regulator-always-on;
+ };
+
+ ldo4_reg: regulator@6 {
+ regulator-always-on;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
Add tps65910 regulator device tree data to AM335x-EVM by adding
regulator consumers with tightened constraints and regulator-name.
TPS65910 regulator handle can be obtained by using this regulator
name.
This patch also add I2C node with I2C frequency and tps65910 PMIC
I2C slave address.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/am335x-evm.dts | 94 ++
1 file changed, 94 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1e1fc15..f9c28a5 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -38,5 +38,99 @@
dcan1: d_can@481D {
status = "okay";
};
+
+ i2c1: i2c@44E0B000 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ tps: tps@2D {
+ reg = <0x2D>;
+ };
+ };
+ };
+
+ vbat: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-boot-on;
+ };
+};
+
+/include/ "tps65910.dtsi"
+
+&tps {
+ vcc1-supply = <&vbat>;
+ vcc2-supply = <&vbat>;
+ vcc3-supply = <&vbat>;
+ vcc4-supply = <&vbat>;
+ vcc5-supply = <&vbat>;
+ vcc6-supply = <&vbat>;
+ vcc7-supply = <&vbat>;
+ vccio-supply = <&vbat>;
+
+ regulators {
+ vrtc_reg: regulator@0 {
+ regulator-always-on;
+ };
+
+ vio_reg: regulator@1 {
+ regulator-always-on;
+ };
+
+ vdd1_reg: regulator@2 {
+ /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%
tolerance */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912500>;
+ regulator-max-microvolt = <1312500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd2_reg: regulator@3 {
+ /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4%
tolerance */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912500>;
+ regulator-max-microvolt = <115>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdd3_reg: regulator@4 {
+ regulator-always-on;
+ };
+
+ vdig1_reg: regulator@5 {
+ regulator-always-on;
+ };
+
+ vdig2_reg: regulator@6 {
+ regulator-always-on;
+ };
+
+ vpll_reg: regulator@7 {
+ regulator-always-on;
+ };
+
+ vdac_reg: regulator@8 {
+ regulator-always-on;
+ };
+
+ vaux1_reg: regulator@9 {
+ regulator-always-on;
+ };
+
+ vaux2_reg: regulator@10 {
+ regulator-always-on;
+ };
+
+ vaux33_reg: regulator@11 {
+ regulator-always-on;
+ };
+
+ vmmc_reg: regulator@12 {
+ regulator-always-on;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] arm/dts: regulator: Add tps65910 device tree data
Add device tree data for tps65910 regulator by adding all tps65910
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65910 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree include file (tps65910.dtsi). This patch
was tested on AM335x-EVM.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/tps65910.dtsi | 86 +++
1 file changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/tps65910.dtsi
diff --git a/arch/arm/boot/dts/tps65910.dtsi b/arch/arm/boot/dts/tps65910.dtsi
new file mode 100644
index 000..92693a8
--- /dev/null
+++ b/arch/arm/boot/dts/tps65910.dtsi
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65910.pdf
+ */
+
+&tps {
+ compatible = "ti,tps65910";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vrtc_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "vrtc";
+ };
+
+ vio_reg: regulator@1 {
+ reg = <1>;
+ regulator-compatible = "vio";
+ };
+
+ vdd1_reg: regulator@2 {
+ reg = <2>;
+ regulator-compatible = "vdd1";
+ };
+
+ vdd2_reg: regulator@3 {
+ reg = <3>;
+ regulator-compatible = "vdd2";
+ };
+
+ vdd3_reg: regulator@4 {
+ reg = <4>;
+ regulator-compatible = "vdd3";
+ };
+
+ vdig1_reg: regulator@5 {
+ reg = <5>;
+ regulator-compatible = "vdig1";
+ };
+
+ vdig2_reg: regulator@6 {
+ reg = <6>;
+ regulator-compatible = "vdig2";
+ };
+
+ vpll_reg: regulator@7 {
+ reg = <7>;
+ regulator-compatible = "vpll";
+ };
+
+ vdac_reg: regulator@8 {
+ reg = <8>;
+ regulator-compatible = "vdac";
+ };
+
+ vaux1_reg: regulator@9 {
+ reg = <9>;
+ regulator-compatible = "vaux1";
+ };
+
+ vaux2_reg: regulator@10 {
+ reg = <10>;
+ regulator-compatible = "vaux2";
+ };
+
+ vaux33_reg: regulator@11 {
+ reg = <11>;
+ regulator-compatible = "vaux33";
+ };
+
+ vmmc_reg: regulator@12 {
+ reg = <12>;
+ regulator-compatible = "vmmc";
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] arm/dts: regulator: Add tps65217 device tree data
Add device tree data for tps65217 regulator by adding all tps65217
regulator nodes. Regulator is initialized based on compatiable
name provided in tps65217 DT file.
All tps65910 PMIC regulator device tree nodes are placed in a
seperate device tree include file (tps65217.dtsi). This patch
was tested on AM335x-Bone.
Signed-off-by: AnilKumar Ch
---
arch/arm/boot/dts/tps65217.dtsi | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 arch/arm/boot/dts/tps65217.dtsi
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
new file mode 100644
index 000..a632724
--- /dev/null
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65217.pdf
+ */
+
+&tps {
+ compatible = "ti,tps65217";
+
+ regulators {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dcdc1_reg: regulator@0 {
+ reg = <0>;
+ regulator-compatible = "dcdc1";
+ };
+
+ dcdc2_reg: regulator@1 {
+ reg = <1>;
+ regulator-compatible = "dcdc2";
+ };
+
+ dcdc3_reg: regulator@2 {
+ reg = <2>;
+ regulator-compatible = "dcdc3";
+ };
+
+ ldo1_reg: regulator@3 {
+ reg = <3>;
+ regulator-compatible = "ldo1";
+ };
+
+ ldo2_reg: regulator@4 {
+ reg = <4>;
+ regulator-compatible = "ldo2";
+ };
+
+ ldo3_reg: regulator@5 {
+ reg = <5>;
+ regulator-compatible = "ldo3";
+ };
+
+ ldo4_reg: regulator@6 {
+ reg = <6>;
+ regulator-compatible = "ldo4";
+ };
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] Add AM33XX regulators device tree data
This patch series add AM33XX regulators (tps65910/tps65217) device tree data to am335x-evm and am335x-bone dts files. These patches are based on Tony L "devel-dt" tree with these patches http://www.mail-archive.com/linux-omap@vger.kernel.org/msg73843.html and these patches has been tested on AM335x EVM and Bone devices. Changes from v2: - Added remaining regulator nodes with always on flag. With out this flag regulator core calls for disable regulators after init, which make device hang. - Modified tps65910 DTS entires with respect to tps65910 input supply. Changes from v1: - Incorporated all Mark Brown's review comments on v1 by * moving all the regulator constraints to corresponding DTS file * Regulator constraints are added according to board. - regulator name is added. AnilKumar Ch (4): arm/dts: regulator: Add tps65910 device tree data arm/dts: regulator: Add tps65217 device tree data arm/dts: Add tps65910 regulator DT data to am335x-evm.dts arm/dts: Add tps65217 regulator DT data to am335x-bone.dts arch/arm/boot/dts/am335x-bone.dts | 54 + arch/arm/boot/dts/am335x-evm.dts | 94 + arch/arm/boot/dts/tps65217.dtsi | 56 ++ arch/arm/boot/dts/tps65910.dtsi | 86 + 4 files changed, 290 insertions(+) create mode 100644 arch/arm/boot/dts/tps65217.dtsi create mode 100644 arch/arm/boot/dts/tps65910.dtsi -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: gpmc generic retime function (subject was RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration)
Hi Jon, On Fri, Aug 17, 2012 at 20:32:34, Hunter, Jon wrote: > > And we have been able to create such a function. Below is an implementation > > that has been made for handling asynchronous timings. It has been tested for > > OneNAND & SMSC on OMAP3EVM (rev G & C) with [1-4]. OneNAND was tested using > > [5] (OMAP3EVM OneNAND works in async mode) & SMSC using [6] (mainline does > > not have a timing calculation for smsc911x) > > Are you able to verify that the timing calculated by this function are > identical? May be some more details on exactly how you tested this would > be good. Yes, it was verified. A new driver preparation series has been posted, http://marc.info/?l=linux-omap&m=134554573104116&w=2 that includes generic timing calculation method. The new series mentions how timing values were validated. There are a couple of timing parameters that would vary as mentioned in the above mentioned mail, but these I don't expect to create problems as this is more inline with gpmc peripheral timings. And both of the these has been verified that it would not create problem with peripheral functionality. One was tested directly (we_on related for OneNAND) and other indirectly (adv_rd(wr)_off on SMSC 9220 for SMSC 91C96). Reason for doing so was that quirks required to handle these specific cases could be avoided, otherwise new peripheral timing data would be required and it would be difficult to achieve DT bindings (when DT happens) for these kind of fixup timings. But if this causes any problems (which I don't expect), then we will have to fallback to the quirks that I wanted to avoid. > Do you think that there is any value in making the tusb member a "u32 > dev_type" and then set it too GPMC_DEVICE_TUSB then this could be used > for other devices in the future too if needed? > Would it be possible to create a sub-function called > gpmc_calc_timings_tusb() and put all these "if (tusb)" statements in > there? Or maybe a generic function called gpmc_calc_timings_prepare(). Usage of a "tusb" check was something that I really wanted to avoid as that was making generic timing calculation function peripheral Gnostic. With the newly posted series, "tusb" field has been removed. Regards Afzal -- 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 10/13] serial: omap: stick to put_autosuspend
Hi, On Tue, Aug 21, 2012 at 02:02:46PM +0300, Felipe Balbi wrote: > On Tue, Aug 21, 2012 at 04:35:26PM +0530, Shilimkar, Santosh wrote: > > On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi wrote: > > > On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote: > > >> On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi wrote: > > >> > Everytime we're done using our TTY, we want > > >> > the pm timer to be reinitilized. By sticking > > >> > to pm_runtime_pm_autosuspend() we make sure > > >> > that this will always be the case. > > >> > > > >> > Signed-off-by: Felipe Balbi > > >> > --- > > >> > drivers/tty/serial/omap-serial.c | 33 > > >> > ++--- > > >> > 1 file changed, 22 insertions(+), 11 deletions(-) > > >> > > > >> > diff --git a/drivers/tty/serial/omap-serial.c > > >> > b/drivers/tty/serial/omap-serial.c > > >> > index 6ea24c5..458d77c 100644 > > >> > --- a/drivers/tty/serial/omap-serial.c > > >> > +++ b/drivers/tty/serial/omap-serial.c > > >> > @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port > > >> > *port) > > >> > pm_runtime_get_sync(up->dev); > > >> > up->ier |= UART_IER_MSI; > > >> > serial_out(up, UART_IER, up->ier); > > >> > - pm_runtime_put(up->dev); > > >> > + pm_runtime_mark_last_busy(up->dev); > > >> > + pm_runtime_put_autosuspend(up->dev); > > >> > } > > >> > > > >> Can you please expand the change-log a bit ? > > >> Didn't follow the time re-init part completely. > > > > > > It's really just a micro-optimization. The thing is: > > > > > > if I call pm_runtime_put(), I will not reinitialize the pm timer to > > > whatever timeout value I used. This means that pm_runtime_put() could > > > actually execute right away (if timer was about to expire when I called > > > pm_runtime_put()). While this wouldn't cause any issues, it's better to > > > reinitialize the timer and make sure if there's another > > > read/write/set_termios/whatever coming right after this, UART is still > > > powered up. > > > > > > I mean, it's really just trying to avoid context save & restore when > > > UART is still under heavy usage. > > > > > > Does it make sense ? > > > > It does. Would be good to add the above description in the change-log. > > Thanks for clarification. > > will do, cheers I have updated my branch like below. Will wait for any other comments before sending another version. commit 8ff7ab777d2bf8619328ddd43ddf2f8660dd011f Author: Felipe Balbi Date: Tue Aug 21 11:45:47 2012 +0300 serial: omap: stick to put_autosuspend Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. The idea behind this patch is to make sure we will always reinitialize the pm timer so that we don't fall into a situation where pm_runtime_put() expires right away (if timer was already about to expire when we made the call to pm_runtime_put()). While suspending right away wouldn't cause any issues, reinitializing the pm timer can help us avoiding unnecessary context save & restore operations (which are somewhat expensive) if there's another read/write/set_termios request coming right after. IOW, we are trying to make sure UART is still powered up while it's still under heavy usage. Acked-by: Santosh Shilimkar Signed-off-by: Felipe Balbi diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6ea24c5..458d77c 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port *port) pm_runtime_get_sync(up->dev); up->ier |= UART_IER_MSI; serial_out(up, UART_IER, up->ier); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); } static void serial_omap_stop_tx(struct uart_port *port) @@ -412,7 +413,8 @@ static unsigned int serial_omap_tx_empty(struct uart_port *port) spin_lock_irqsave(&up->port.lock, flags); ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0; spin_unlock_irqrestore(&up->port.lock, flags); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); return ret; } @@ -424,7 +426,8 @@ static unsigned int serial_omap_get_mctrl(struct uart_port *port) pm_runtime_get_sync(up->dev); status = check_modem_status(up); - pm_runtime_put(up->dev); + pm_runtime_mark_last_busy(up->dev); + pm_runtime_put_autosuspend(up->dev); dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line); @@ -460,7 +463,8 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl) up->mcr = serial_in(up, UART_MCR); up->mcr |= m
Re: [PATCH V5 5/6] ARM: OMAP: Disable venc for OMAP4
On Tue, Aug 21, 2012 at 4:02 PM, Tomi Valkeinen wrote:
> On Mon, 2012-08-20 at 18:54 +0530, Chandrabhanu Mahapatra wrote:
>> This is a alternative to "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
>> prevent crash" (ba02fa37de) by Tomi Valkeinen to
>> prevent
>> VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial
>> registration
>> of a device for VENC on OMAP4.
>>
>> Signed-off-by: Chandrabhanu Mahapatra
>> ---
>> arch/arm/mach-omap2/display.c |1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
>> index af1ed7d..ee40739 100644
>> --- a/arch/arm/mach-omap2/display.c
>> +++ b/arch/arm/mach-omap2/display.c
>> @@ -95,7 +95,6 @@ static const struct omap_dss_hwmod_data
>> omap4_dss_hwmod_data[] __initdata = {
>> { "dss_core", "omapdss_dss", -1 },
>> { "dss_dispc", "omapdss_dispc", -1 },
>> { "dss_rfbi", "omapdss_rfbi", -1 },
>> - { "dss_venc", "omapdss_venc", -1 },
>> { "dss_dsi1", "omapdss_dsi", 0 },
>> { "dss_dsi2", "omapdss_dsi", 1 },
>> { "dss_hdmi", "omapdss_hdmi", -1 },
>
> You need to reorder this and the previous patch. If you first remove the
> workaround from the previous patch, the kernel will crash if after that
> patch. So this one should be before the previous patch.
>
> Tomi
>
Ok.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. 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: [RFC/PATCH 10/13] serial: omap: stick to put_autosuspend
On Tue, Aug 21, 2012 at 04:35:26PM +0530, Shilimkar, Santosh wrote: > On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi wrote: > > On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote: > >> On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi wrote: > >> > Everytime we're done using our TTY, we want > >> > the pm timer to be reinitilized. By sticking > >> > to pm_runtime_pm_autosuspend() we make sure > >> > that this will always be the case. > >> > > >> > Signed-off-by: Felipe Balbi > >> > --- > >> > drivers/tty/serial/omap-serial.c | 33 ++--- > >> > 1 file changed, 22 insertions(+), 11 deletions(-) > >> > > >> > diff --git a/drivers/tty/serial/omap-serial.c > >> > b/drivers/tty/serial/omap-serial.c > >> > index 6ea24c5..458d77c 100644 > >> > --- a/drivers/tty/serial/omap-serial.c > >> > +++ b/drivers/tty/serial/omap-serial.c > >> > @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port > >> > *port) > >> > pm_runtime_get_sync(up->dev); > >> > up->ier |= UART_IER_MSI; > >> > serial_out(up, UART_IER, up->ier); > >> > - pm_runtime_put(up->dev); > >> > + pm_runtime_mark_last_busy(up->dev); > >> > + pm_runtime_put_autosuspend(up->dev); > >> > } > >> > > >> Can you please expand the change-log a bit ? > >> Didn't follow the time re-init part completely. > > > > It's really just a micro-optimization. The thing is: > > > > if I call pm_runtime_put(), I will not reinitialize the pm timer to > > whatever timeout value I used. This means that pm_runtime_put() could > > actually execute right away (if timer was about to expire when I called > > pm_runtime_put()). While this wouldn't cause any issues, it's better to > > reinitialize the timer and make sure if there's another > > read/write/set_termios/whatever coming right after this, UART is still > > powered up. > > > > I mean, it's really just trying to avoid context save & restore when > > UART is still under heavy usage. > > > > Does it make sense ? > > It does. Would be good to add the above description in the change-log. > Thanks for clarification. will do, cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH V5 3/6] OMAPDSS: DSS: Cleanup cpu_is_xxxx checks
On Tue, Aug 21, 2012 at 4:05 PM, Tomi Valkeinen wrote:
> On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
>> All the cpu_is checks have been moved to dss_init_features function
>> providing a
>> much more generic and cleaner interface. The OMAP version and revision
>> specific
>> initializations in various functions are cleaned and the necessary data are
>> moved to dss_features structure which is local to dss.c.
>>
>> Signed-off-by: Chandrabhanu Mahapatra
>> ---
>> drivers/video/omap2/dss/dss.c | 117
>> ++---
>> 1 file changed, 76 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 10566ae..f6d3d0a 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
>> @@ -31,6 +31,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -65,6 +66,12 @@ struct dss_reg {
>> static int dss_runtime_get(void);
>> static void dss_runtime_put(void);
>>
>> +struct dss_features {
>> + u16 fck_div_max;
>> + int dss_fck_multiplier;
>> + char *clk_name;
>
> const char *
>
> Tomi
>
All the values are const. So we have a const pointer dss.feat to hold
this structure. Is a separate
const char *clk_name required?
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. 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: [RFC/PATCH 10/13] serial: omap: stick to put_autosuspend
On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi wrote: > On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote: >> On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi wrote: >> > Everytime we're done using our TTY, we want >> > the pm timer to be reinitilized. By sticking >> > to pm_runtime_pm_autosuspend() we make sure >> > that this will always be the case. >> > >> > Signed-off-by: Felipe Balbi >> > --- >> > drivers/tty/serial/omap-serial.c | 33 ++--- >> > 1 file changed, 22 insertions(+), 11 deletions(-) >> > >> > diff --git a/drivers/tty/serial/omap-serial.c >> > b/drivers/tty/serial/omap-serial.c >> > index 6ea24c5..458d77c 100644 >> > --- a/drivers/tty/serial/omap-serial.c >> > +++ b/drivers/tty/serial/omap-serial.c >> > @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port >> > *port) >> > pm_runtime_get_sync(up->dev); >> > up->ier |= UART_IER_MSI; >> > serial_out(up, UART_IER, up->ier); >> > - pm_runtime_put(up->dev); >> > + pm_runtime_mark_last_busy(up->dev); >> > + pm_runtime_put_autosuspend(up->dev); >> > } >> > >> Can you please expand the change-log a bit ? >> Didn't follow the time re-init part completely. > > It's really just a micro-optimization. The thing is: > > if I call pm_runtime_put(), I will not reinitialize the pm timer to > whatever timeout value I used. This means that pm_runtime_put() could > actually execute right away (if timer was about to expire when I called > pm_runtime_put()). While this wouldn't cause any issues, it's better to > reinitialize the timer and make sure if there's another > read/write/set_termios/whatever coming right after this, UART is still > powered up. > > I mean, it's really just trying to avoid context save & restore when > UART is still under heavy usage. > > Does it make sense ? It does. Would be good to add the above description in the change-log. Thanks for clarification. Regars Santosh -- 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 10/13] serial: omap: stick to put_autosuspend
On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote: > On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi wrote: > > Everytime we're done using our TTY, we want > > the pm timer to be reinitilized. By sticking > > to pm_runtime_pm_autosuspend() we make sure > > that this will always be the case. > > > > Signed-off-by: Felipe Balbi > > --- > > drivers/tty/serial/omap-serial.c | 33 ++--- > > 1 file changed, 22 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/tty/serial/omap-serial.c > > b/drivers/tty/serial/omap-serial.c > > index 6ea24c5..458d77c 100644 > > --- a/drivers/tty/serial/omap-serial.c > > +++ b/drivers/tty/serial/omap-serial.c > > @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port > > *port) > > pm_runtime_get_sync(up->dev); > > up->ier |= UART_IER_MSI; > > serial_out(up, UART_IER, up->ier); > > - pm_runtime_put(up->dev); > > + pm_runtime_mark_last_busy(up->dev); > > + pm_runtime_put_autosuspend(up->dev); > > } > > > Can you please expand the change-log a bit ? > Didn't follow the time re-init part completely. It's really just a micro-optimization. The thing is: if I call pm_runtime_put(), I will not reinitialize the pm timer to whatever timeout value I used. This means that pm_runtime_put() could actually execute right away (if timer was about to expire when I called pm_runtime_put()). While this wouldn't cause any issues, it's better to reinitialize the timer and make sure if there's another read/write/set_termios/whatever coming right after this, UART is still powered up. I mean, it's really just trying to avoid context save & restore when UART is still under heavy usage. Does it make sense ? -- balbi signature.asc Description: Digital signature
Re: [RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
Hi,
On Tue, Aug 21, 2012 at 04:15:40PM +0530, Sourav Poddar wrote:
> smsc can be used as an gpio io expander device also. So adding
> support for configuring smsc pins as a gpio.
>
> Cc: Benoit Cousson
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
> Signed-off-by: Sourav Poddar
> ---
> drivers/gpio/Kconfig|7 +
> drivers/gpio/Makefile |1 +
> drivers/gpio/gpio-smscece.c | 373
> +++
> 3 files changed, 381 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpio/gpio-smscece.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index b16c8a7..e883929 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
> Say yes here to enable the adp5588 to be used as an interrupt
> controller. It requires the driver to be built in the kernel.
>
> +config GPIO_SMSCECE
> + tristate "SMSCECE 1099 I2C GPIO expander"
> + depends on I2C
> + help
> + This option enables support for 18 GPIOs found
> + on SMSC ECE 1099 GPIO Expanders.
> +
> comment "PCI GPIO expanders:"
>
> config GPIO_CS5535
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 153cace..7c803c5 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
> obj-$(CONFIG_GPIO_AB8500)+= gpio-ab8500.o
> obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
> obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
> +obj-$(CONFIG_GPIO_SMSCECE) += gpio-smscece.o
> obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
> obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
> obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
> diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
> new file mode 100644
> index 000..0cb0959
> --- /dev/null
> +++ b/drivers/gpio/gpio-smscece.c
> @@ -0,0 +1,373 @@
> +/*
> + * GPIO Chip driver for smsc
> + * SMSC I/O Expander and QWERTY Keypad Controller
> + *
> + * Copyright 2012 Texas Instruments Inc.
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct smsc_gpio {
> + struct device *dev;
> + struct smsc *smsc;
> + struct gpio_chip gpio_chip;
> + struct mutex lock; /* protect cached dir, dat_out */
> + /* protect serialized access to the interrupt controller bus */
> + struct mutex irq_lock;
> + unsigned gpio_start;
> + int type;
> + int flags;
> + int irq;
> + int irq_base;
> + unsigned int gpio_base;
> + unsigned int dat_out[5];
> + unsigned int dir[5];
> + unsigned int int_lvl[5];
> + unsigned int int_en[5];
> + unsigned int irq_mask[5];
> + unsigned int irq_stat[5];
> +};
> +
> +static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
> +{
> + struct smsc_gpio *sg =
> + container_of(chip, struct smsc_gpio, gpio_chip);
> + unsigned int get;
> + return !!(smsc_read(sg->dev,
> + (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off)) & SMSC_BIT(off),
> + &get));
> +}
> +
> +static void smsc_gpio_set_value(struct gpio_chip *chip,
> + unsigned off, int val)
> +{
> + unsigned bank, bit;
> + struct smsc_gpio *sg =
> + container_of(chip, struct smsc_gpio, gpio_chip);
> +
> + bank = SMSC_BANK(off);
> + bit = SMSC_BIT(off);
> +
> + mutex_lock(&sg->lock);
> + if (val)
> + sg->dat_out[bank] |= bit;
> + else
> + sg->dat_out[bank] &= ~bit;
> +
> + smsc_write(sg->dev, SMSC_GPIO_DATA_OUT_START + bank,
> +sg->dat_out[bank]);
> + mutex_unlock(&sg->lock);
> +}
> +
> +static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
> +{
> + unsigned int reg;
> + struct smsc_gpio *sg =
> + container_of(chip, struct smsc_gpio, gpio_chip);
> + int reg_dir;
> +
> + mutex_lock(&sg->lock);
> + reg_dir = SMSC_CFG_START + off;
> + smsc_read(sg->dev, reg_dir, ®);
> + reg |= SMSC_GPIO_INPUT_LOW;
> + mutex_unlock(&sg->lock);
> +
> + return smsc_write(sg->dev, reg_dir, reg);
> +}
> +
> +static int smsc_gpio_direction_output(struct gpio_chip *chip,
> + unsigned off, int val)
> +{
> + unsigned int reg;
> + struct smsc_gpio *sg =
> + container_of(chip, struct smsc_gpio, gpio_chip);
> + int reg_dir;
> +
> + mutex_lock(&sg->lock);
> + reg_dir = SMSC_CFG_START + off;
> + smsc_read(sg->dev, reg_dir, ®);
> + reg |= SMSC_GPIO_OUTPUT_PP;
> + mutex_unlock(&sg->lock);
> +
> + return smsc_write(sg->dev, reg_dir, reg);
> +}
> +
> +static int smsc_gpio_to_irq(struct gpio_chip *chip, unsigned off)
> +{
> + struct smsc_gpio *sg =
> + container_
RE: [PATCH v2 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
Hi Mark,
On Tue, Aug 21, 2012 at 01:37:15, Mark Brown wrote:
> On Mon, Aug 20, 2012 at 06:27:01AM +, AnilKumar, Chimata wrote:
> > On Thu, Aug 16, 2012 at 19:30:56, Mark Brown wrote:
>
> > > Why does this mean you need multiple regulators? A single regulator can
> > > of course supply multiple devices.
>
> > I got your point but tps65910 driver is failing if we add single fixed
> > regulator. Solution is driver needs to change or add multiple fixed
> > regulators.
>
> No, really. One regulator can supply many things, not being a.
>
> > vrtc:
> > tps65910 0-002d: Failed to find supply vcc7
> > tps65910 0-002d: failed to register tps65910-pmic regulator
>
> So you've specified a whole bunch of supplies and this one individual
> supply is not matching (and it's not the first...). You should
> investigate what's gone wrong there rather than bodging around the
> problem. I can't immediately say anything much based on the information
> you've given.
>
Sorry for the noise in this issue, I found the root cause. I
was defining the supply names like this which is wrong.
&tps {
regulators {
vcc1-supply = <&vcc5v_supply>;
vcc2-supply = <&vcc5v_supply>;
vcc3-supply = <&vcc5v_supply>;
vcc4-supply = <&vcc5v_supply>;
vcc5-supply = <&vcc5v_supply>;
vcc6-supply = <&vcc5v_supply>;
vcc7-supply = <&vcc5v_supply>;
vccio-supply = <&vcc5v_supply>;
vrtc_reg: regulator@0 { /* vrtc input is vcc7 */
regulator-always-on;
};
...
...
};
};
This was suppose to be
&tps {
vcc1-supply = <&vcc5v_supply>;
vcc2-supply = <&vcc5v_supply>;
vcc3-supply = <&vcc5v_supply>;
vcc4-supply = <&vcc5v_supply>;
vcc5-supply = <&vcc5v_supply>;
vcc6-supply = <&vcc5v_supply>;
vcc7-supply = <&vcc5v_supply>;
vccio-supply = <&vcc5v_supply>;
regulators {
vrtc_reg: regulator@0 { /* vrtc input is vcc7 */
regulator-always-on;
};
...
...
};
};
Thanks for your continuous feedback.
Thanks
AnilKumar
--
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 3/4] arm/dts: omap5-evm: Add keypad support
On Tue, Aug 21, 2012 at 04:15:39PM +0530, Sourav Poddar wrote:
> Add keypad data node in omap5-evm.
>
> Based on I2C support patch for omap5, which has been
> already posted as a different series.
>
> Cc: Benoit Cousson
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
> Tested on omap5430 sdp with 3.5 custom kernel.
>
> Signed-off-by: Sourav Poddar
after fixing my only comment below, you can add my:
Acked-by: Felipe Balbi
> ---
> arch/arm/boot/dts/omap5-evm.dts | 95
> +++
> 1 files changed, 95 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
> index 200c39a..6473983 100644
> --- a/arch/arm/boot/dts/omap5-evm.dts
> +++ b/arch/arm/boot/dts/omap5-evm.dts
> @@ -18,3 +18,98 @@
> reg = <0x8000 0x4000>; /* 1 GB */
> };
> };
> +
> +&i2c5 {
> + clock-frequency = <40>;
> +
> + smsc@38 {
> + compatible = "smsc";
> + reg = <0x38>;
> + clock = <0x13>;
> + keypad {
> + compatible = "smsc,keypad";
> + interrupt-parent = <&gpio5>;
> + interrupts = <23>; /* gpio line 151 */
> + keypad,num-rows = <8>;
> + keypad,num-columns = <16>;
> + linux,keymap = < 0x20041 /*KEY_F7*/
please add spaces around /* and */ so it's easier to read. Ditto to all
others.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] Input: keypad: Add smsc ece1099 keypad driver
Hi,
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
> +static struct platform_driver smsc_driver = {
> + .driver = {
> + .name = "smsc-keypad",
> + .of_match_table = of_match_ptr(smsc_keypad_dt_match),
> + .owner = THIS_MODULE,
> + },
> + .probe = smsc_probe,
> + .remove = smsc_remove,
one extra comment which I forgot. You probably should put your remove on
__devexit and add __devexit_p(smsc_remove) here.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
> > +
> > + /* ChiMei G121S1-L01 */
> > + {
> > + {
>
> ...
>
> > + .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
> > + .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
> > + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
> > + .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
> > + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
>
> Actually those 3 panels only use the DE signal. The hsync/vsync signals
> are not used and on our system we mux them out to make sure they are
> kept low as recommended in the panel datasheets.
>
> Since vsync/hsync are not used, I think the vsync_level, hsync_level and
> sync_pclk_edge entries could be removed. Otherwise the updated patch
> works fine as is.
Okay. How do panels like that work? How can they know where a new frame
starts?
Actually, I now googled for those panels, and they are all LVDS panels,
not DPI panels. So the patch doesn't look correct at all.
Do you have a DPI-to-LVDS converter chip on your board?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 2/4] Input: keypad: Add smsc ece1099 keypad driver
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
> supports a keypad scan matrix of 23*8.This driver uses this
> device as a keypad driver.
>
> Cc: Dmitry Torokhov
> Cc: Benoit Cousson
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
> Signed-off-by: G, Manjunath Kondaiah
> Signed-off-by: Sourav Poddar
looks good. If you just fix my comment on free_irq() below, you can add:
Acked-by: Felipe Balbi
> +static int __devinit
> +smsc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct smsc *smsc = dev_get_drvdata(pdev->dev.parent);
> + struct input_dev *input;
> + struct smsc_keypad *kp;
> + int ret = 0, error;
> + int col, i, max_keys, row_shift;
> + int irq;
> + int addr_start, addr;
> +
> + kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
> +
> + input = input_allocate_device();
> + if (!kp || !input) {
> + error = -ENOMEM;
> + goto err1;
> + }
> +
> + error = smsc_keypad_parse_dt(&pdev->dev, kp);
> + if (error)
> + return error;
> +
> + /* Get the debug Device */
> + kp->input = input;
> + kp->smsc = smsc;
> + kp->irq = platform_get_irq(pdev, 0);
> + kp->dev = dev;
> +
> + for (col = 0; col < 16; col++) {
> + kp->last_key_state[col] = 0;
> + kp->last_key_ms[col] = 0;
> + }
> +
> + /* setup input device */
> + __set_bit(EV_KEY, input->evbit);
> +
> + /* Enable auto repeat feature of Linux input subsystem */
> + if (!(kp->no_autorepeat))
> + __set_bit(EV_REP, input->evbit);
> +
> + input_set_capability(input, EV_MSC, MSC_SCAN);
> + input->name = "SMSC Keypad";
> + input->phys = "smsc_keypad/input0";
> + input->dev.parent = &pdev->dev;
> + input->id.bustype = BUS_HOST;
> + input->id.vendor= 0x0001;
> + input->id.product = 0x0001;
> + input->id.version = 0x0003;
> +
> + error = input_register_device(input);
> + if (error) {
> + dev_err(kp->dev,
> + "Unable to register twl4030 keypad device\n");
> + goto err1;
> + }
> +
> + /* Mask all GPIO interrupts (0x37-0x3B) */
> + for (addr = 0x37; addr < 0x3B; addr++)
> + smsc_write(dev, addr, 0);
> +
> + /* Set all outputs high (0x05-0x09) */
> + for (addr = 0x05; addr < 0x09; addr++)
> + smsc_write(dev, addr, 0xff);
> +
> + /* Clear all GPIO interrupts (0x32-0x36) */
> + for (addr = 0x32; addr < 0x36; addr++)
> + smsc_write(dev, addr, 0xff);
> +
> + addr_start = 0x12;
> + for (i = 0; i <= kp->rows; i++) {
> + addr = 0x12 + i;
> + smsc_write(dev, addr, SMSC_KP_KSI);
> + }
> +
> + addr_start = 0x1A;
> + for (i = 0; i <= kp->cols; i++) {
> + addr = 0x1A + i;
> + smsc_write(dev, addr, SMSC_KP_KSO);
> + }
> +
> + addr = SMSC_KP_INT_STAT;
> + smsc_write(dev, addr, SMSC_KP_SET_HIGH);
> +
> + addr = SMSC_WKUP_CTRL;
> + smsc_write(dev, addr, SMSC_KP_SET_LOW_PWR);
> +
> + addr = SMSC_KP_OUT;
> + smsc_write(dev, addr, SMSC_KSO_ALL_LOW);
> +
> + row_shift = get_count_order(kp->cols);
> + max_keys = kp->rows << row_shift;
> +
> + kp->row_shift = row_shift;
> + kp->keymap = kzalloc(max_keys * sizeof(kp->keymap[0]),
> + GFP_KERNEL);
> + if (!kp->keymap) {
> + dev_err(&pdev->dev, "Not enough memory for keymap\n");
> + error = -ENOMEM;
> + }
> +
> + matrix_keypad_build_keymap(NULL, NULL, kp->rows,
> + kp->cols, kp->keymap, input);
> +
> + /*
> + * This ISR will always execute in kernel thread context because of
> + * the need to access the SMSC over the I2C bus.
> + */
> + ret = devm_request_threaded_irq(dev, kp->irq, NULL, do_kp_irq,
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev->name, kp);
> + if (ret) {
> + dev_dbg(&pdev->dev, "request_irq failed for irq no=%d\n",
> + irq);
> + goto err2;
> + }
> +
> + /* Enable smsc keypad interrupts */
> + ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
> + if (ret < 0)
> + goto err2;
> +
> + return 0;
> +
> +err2:
> + input_unregister_device(input);
> + free_irq(kp->irq, NULL);
you're using devm_request_threaded_irq, this is unnecessary
> +err1:
> + input_free_device(input);
> + return ret;
> +}
> +
> +static int smsc_remove(struct platform_device *pdev)
> +{
> + struct smsc_keypad *kp = platform_get_drvdata(pdev);
> + free_irq(kp->irq, kp);
ditto.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 00/10] Assorted MMC / OMAP HSMMC patches
Hi, On Sat, Aug 18, 2012 at 12:22:20AM +0530, Venkatraman S wrote: > Essentially, a lot of cleanups leading up to adding a new > feature for OMAP HSMMC. The idea is to convert to the use > of software timer instead of IP timer for timekeeping, due > to the limitations of the counting range of the IP timer. > > Also added myself as OMAP HSMMC maintainer. > > Patch 9/10 is in draft state and needs more testing. > > These patches are also available at > git://github.com/svenkatr/linux.git my/mmc/3.6/hrtimer_updates other than the small comments I had to patch 9, this series looks very good: Acked-by: Felipe Balbi > > Venkatraman S (10): > mmc: core: Add TRANsfer state to non-HPI state > mmc: debugfs: Print ext_csd in ascending order > mmc: omap: remove unused variables and includes > mmc: omap: fix mmc_omap_report_irq to use dev_dbg macros > mmc: omap_hsmmc: remove unused vars and includes > mmc: omap_hsmmc: remove access to SYSCONFIG register > mmc: omap_hsmmc: consolidate flush posted writes for HSMMC IRQs > mmc: omap_hsmmc: consolidate error report handling of HSMMC IRQ > mmc: omap_hsmmc: convert from IP timer to hrtimer > mmc: omap_hsmmc: Move to Maintained state in MAINTAINERS > > MAINTAINERS | 4 +- > drivers/mmc/core/core.c | 3 +- > drivers/mmc/core/debugfs.c| 2 +- > drivers/mmc/host/omap.c | 39 > drivers/mmc/host/omap_hsmmc.c | 212 > -- > 5 files changed, 103 insertions(+), 157 deletions(-) > > -- > 1.7.11.1.25.g0e18bef > > -- > 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 -- balbi signature.asc Description: Digital signature
[PATCH v6 08/10] ARM: OMAP2+: onenand: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-onenand.c | 124
1 files changed, 41 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index e139e3f..700f9a6 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -49,6 +49,7 @@ static struct platform_device gpmc_onenand_device = {
static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
@@ -58,35 +59,22 @@ static struct gpmc_timings
omap2_onenand_calc_async_timings(void)
const int t_aa = 76;
const int t_oe = 20;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
- memset(&t, 0, sizeof(t));
- t.sync_clk = 0;
- t.cs_on = 0;
- t.adv_on = 0;
-
- /* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
- t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
- t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
- t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
-
- /* Write */
- t.adv_wr_off = t.adv_rd_off;
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = t.we_on;
- t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
- }
- t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
- t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
- t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ memset(&dev_t, 0, sizeof(dev_t));
+
+ dev_t.mux = true;
+ dev_t.t_avdp_r = dev_t.t_avdp_w = max_t(int, t_avdp, t_cer) * 1000;
+ dev_t.t_aavdh = t_aavdh * 1000;
+ dev_t.t_aa = t_aa * 1000;
+ dev_t.t_ce = t_ce * 1000;
+ dev_t.t_oe = t_oe * 1000;
+ dev_t.t_cez_r = dev_t.t_cez_w = t_cez * 1000;
+ dev_t.t_wpl = t_wpl * 1000;
+ dev_t.t_wph = t_wph * 1000;
+
+ gpmc_calc_timings(&t, &dev_t);
return t;
}
@@ -172,16 +160,15 @@ static struct gpmc_timings
omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
int freq)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
- int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
- int ticks_cez;
+ int div, gpmc_clk_ns;
if (cfg->flags & ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -248,62 +235,33 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
latency = 4;
/* Set synchronous read timings */
- memset(&t, 0, sizeof(t));
+ memset(&dev_t, 0, sizeof(dev_t));
- if (div == 1) {
- t.bool_timings.cs_extra_delay = true;
- t.bool_timings.adv_extra_delay = true;
- t.bool_timings.oe_extra_delay = true;
- t.bool_timings.we_extra_delay = true;
- }
-
- t.sync_clk = min_gpmc_clk_period;
- t.cs_on = 0;
- t.adv_on = 0;
- fclk_offset_ns = gpmc_round_ns_to_ticks(max_t(int, t_ces, t_avds));
- fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);
- t.page_burst_access = gpmc_clk_ns;
-
- /* Read */
- t.adv_rd_off = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_avdh));
- t.oe_on = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_ach));
- /* Force at least 1 clk between AVD High to OE Low */
- if (t.oe_on <= t.adv_rd_off)
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
- t.access = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div);
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- ticks_cez = ((gpmc_ns_to_ticks(t_cez) + div - 1) / div) * div;
- t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
-ticks_cez);
-
- t.clk_activation = fclk_offset_ns;
-
- /* Write */
- if (onenand_flags & ONENAND_FLAG_SYNCWRITE) {
- t.adv_wr_off = t.adv_rd_off;
- t.we_on = 0;
- t.we_off = t.cs_rd
[PATCH v6 07/10] ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.
There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.
Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.
Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc.c | 302
arch/arm/plat-omap/include/plat/gpmc.h | 61 +++
2 files changed, 363 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d005b3a..d8e5b08 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -233,6 +233,18 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+unsigned int gpmc_ticks_to_ps(unsigned int ticks)
+{
+ return ticks * gpmc_get_fclk_period();
+}
+
+unsigned int gpmc_round_ps_to_ticks(unsigned int time_ps)
+{
+ unsigned long ticks = gpmc_ps_to_ticks(time_ps);
+
+ return ticks * gpmc_get_fclk_period();
+}
+
static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
{
u32 l;
@@ -884,6 +896,296 @@ static void __init gpmc_mem_init(void)
}
}
+static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32 sync_clk)
+{
+ u32 temp;
+ int div;
+
+ div = gpmc_calc_divider(sync_clk);
+ temp = gpmc_ps_to_ticks(time_ps);
+ temp = (temp + div - 1) / div;
+ return gpmc_ticks_to_ps(temp * div);
+}
+
+/* can the cycles be avoided ? */
+static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
+ struct gpmc_device_timings *dev_t)
+{
+ bool mux = dev_t->mux;
+ u32 temp;
+
+ /* adv_rd_off */
+ temp = dev_t->t_avdp_r;
+ /* mux check required ? */
+ if (mux) {
+ /* t_avdp not to be required for sync, only added for tusb this
+* indirectly necessitates requirement of t_avdp_r & t_avdp_w
+* instead of having a single t_avdp
+*/
+ temp = max_t(u32, temp, gpmc_t->clk_activation * 1000 +
+ dev_t->t_avdh);
+ temp = max_t(u32,
+ (gpmc_t->adv_on + gpmc_ticks_to_ns(1)) * 1000, temp);
+ }
+ gpmc_t->adv_rd_off = gpmc_round_ps_to_ticks(temp) / 1000;
+
+ /* oe_on */
+ temp = dev_t->t_oeasu; /* remove this ? */
+ if (mux) {
+ temp = max_t(u32, temp,
+ gpmc_t->clk_activation * 1000 + dev_t->t_ach);
+ temp = max_t(u32, temp, (gpmc_t->adv_rd_off +
+ gpmc_ticks_to_ns(dev_t->cyc_aavdh_oe)) * 1000);
+ }
+ gpmc_t->oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
+
+ /* access */
+ /* any scope for improvement ?, by combining oe_on & clk_activation,
+* need to check whether access = clk_activation + round to sync clk ?
+*/
+ temp = max_t(u32, dev_t->t_iaa, dev_t->cyc_iaa * gpmc_t->sync_clk);
+ temp += gpmc_t->clk_activation * 1000;
+ if (dev_t->cyc_oe)
+ temp = max_t(u32, temp, (gpmc_t->oe_on +
+ gpmc_ticks_to_ns(dev_t->cyc_oe)) * 1000);
+ gpmc_t->access = gpmc_round_ps_to_ticks(temp) / 1000;
+
+ gpmc_t->oe_off = gpmc_t->access + gpmc_ticks_to_ns(1);
+ gpmc_t->cs_rd_off = gpmc_t->oe_off;
+
[PATCH 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Cc: Samuel Ortiz Cc: Benoit Cousson Cc: Felipe Balbi Cc: Santosh Shilimkar Signed-off-by: Sourav Poddar --- Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 10 +++ drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 139 include/linux/mfd/smsc.h | 89 + 5 files changed, 295 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt new file mode 100644 index 000..6b492e8 --- /dev/null +++ b/Documentation/smsc_ece1099.txt @@ -0,0 +1,56 @@ +What is smsc-ece1099? +-- + +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion +or GPIO Expansion device. The device supports a keyboard +scan matrix of 23x8. The device is connected to a Master +via the SMSC BC-Link interface or via the SMBus. +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals +are multiplexed with GPIOs. + +Interrupt generation + + +Interrupts can be generated by an edge detection on a GPIO +pin or an edge detection on one of the bus interface pins. +Interrupts can also be detected on the keyboard scan interface. +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if +any bit in one of the Interrupt Status registers is 1 and +the corresponding Interrupt Mask bit is also 1. + +In order for software to determine which device is the source +of an interrupt, it should first read the Group Interrupt Status Register +to determine which Status register group is a source for the interrupt. +Software should read both the Status register and the associated Mask register, +then AND the two values together. Bits that are 1 in the result of the AND +are active interrupts. Software clears an interrupt by writing a 1 to the +corresponding bit in the Status register. + +Communication Protocol +-- + +- SMbus slave Interface + The host processor communicates with the ECE1099 device + through a series of read/write registers via the SMBus + interface. SMBus is a serial communication protocol between + a computer host and its peripheral devices. The SMBus data + rate is 10KHz minimum to 400 KHz maximum + +- Slave Bus Interface + The ECE1099 device SMBus implementation is a subset of the + SMBus interface to the host. The device is a slave-only SMBus device. + The implementation in the device is a subset of SMBus since it + only supports four protocols. + + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the + only valid SMBus protocols for the device. + +- BC-LinkTM Interface + The BC-Link is a proprietary bus that allows communication + between a Master device and a Companion device. The Master + device uses this serial bus to read and write registers + located on the Companion device. The bus comprises three signals, + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the + clock, BC_CLK, and the Companion device is the source for an + independent asynchronous interrupt signal, BC_INT#. The ECE1099 + supports BC-Link speeds up to 24MHz. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d1facef..3b81c17 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -385,6 +385,16 @@ config MFD_T7L66XB help Support for Toshiba Mobile IO Controller T7L66XB +config MFD_SMSC + bool "Support for the SMSC ECE1099 series chips" + depends on I2C=y && MFD_CORE && REGMAP_I2C + help +If you say yes here you get support for the +ece1099 chips from SMSC. + +To compile this driver as a module, choose M here: the +module will be called smsc. + config MFD_TC6387XB bool "Support Toshiba TC6387XB" depends on ARM && HAVE_CLK diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 79dd22d..f587d91 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -77,6 +77,7 @@ obj-$(CONFIG_EZX_PCAP)+= ezx-pcap.o obj-$(CONFIG_MCP) += mcp-core.o obj-$(CONFIG_MCP_SA11X0) += mcp-sa11x0.o obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o +obj-$(CONFIG_MFD_SMSC)+= smsc.o obj-$(CONFIG_MCP_UCB1200_TS) += ucb1x00-ts.o ifeq ($(CONFIG_SA1100_ASSABET),y) diff --git a/drivers/mfd/smsc-ece1099.c b/drivers/mfd/smsc-ece1099.c new file mode 100644 index 000..6ba06b8 --- /dev/null +++ b/drivers/mfd/smsc-ece1099.c @@ -0,0 +1,139 @@ +/* + * TI SMSC MFD Driver + * + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com + * + * Author: Sourav P
[RFC/PATCH 4/4] gpio: smscece: Add support for gpio IO expander feature
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.
Cc: Benoit Cousson
Cc: Felipe Balbi
Cc: Santosh Shilimkar
Signed-off-by: Sourav Poddar
---
drivers/gpio/Kconfig|7 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-smscece.c | 373 +++
3 files changed, 381 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-smscece.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b16c8a7..e883929 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
Say yes here to enable the adp5588 to be used as an interrupt
controller. It requires the driver to be built in the kernel.
+config GPIO_SMSCECE
+ tristate "SMSCECE 1099 I2C GPIO expander"
+ depends on I2C
+ help
+ This option enables support for 18 GPIOs found
+ on SMSC ECE 1099 GPIO Expanders.
+
comment "PCI GPIO expanders:"
config GPIO_CS5535
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 153cace..7c803c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_AB8500) += gpio-ab8500.o
obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
+obj-$(CONFIG_GPIO_SMSCECE) += gpio-smscece.o
obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
new file mode 100644
index 000..0cb0959
--- /dev/null
+++ b/drivers/gpio/gpio-smscece.c
@@ -0,0 +1,373 @@
+/*
+ * GPIO Chip driver for smsc
+ * SMSC I/O Expander and QWERTY Keypad Controller
+ *
+ * Copyright 2012 Texas Instruments Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smsc_gpio {
+ struct device *dev;
+ struct smsc *smsc;
+ struct gpio_chip gpio_chip;
+ struct mutex lock; /* protect cached dir, dat_out */
+ /* protect serialized access to the interrupt controller bus */
+ struct mutex irq_lock;
+ unsigned gpio_start;
+ int type;
+ int flags;
+ int irq;
+ int irq_base;
+ unsigned int gpio_base;
+ unsigned int dat_out[5];
+ unsigned int dir[5];
+ unsigned int int_lvl[5];
+ unsigned int int_en[5];
+ unsigned int irq_mask[5];
+ unsigned int irq_stat[5];
+};
+
+static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
+{
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ unsigned int get;
+ return !!(smsc_read(sg->dev,
+ (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off)) & SMSC_BIT(off),
+ &get));
+}
+
+static void smsc_gpio_set_value(struct gpio_chip *chip,
+ unsigned off, int val)
+{
+ unsigned bank, bit;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+
+ bank = SMSC_BANK(off);
+ bit = SMSC_BIT(off);
+
+ mutex_lock(&sg->lock);
+ if (val)
+ sg->dat_out[bank] |= bit;
+ else
+ sg->dat_out[bank] &= ~bit;
+
+ smsc_write(sg->dev, SMSC_GPIO_DATA_OUT_START + bank,
+ sg->dat_out[bank]);
+ mutex_unlock(&sg->lock);
+}
+
+static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
+{
+ unsigned int reg;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ int reg_dir;
+
+ mutex_lock(&sg->lock);
+ reg_dir = SMSC_CFG_START + off;
+ smsc_read(sg->dev, reg_dir, ®);
+ reg |= SMSC_GPIO_INPUT_LOW;
+ mutex_unlock(&sg->lock);
+
+ return smsc_write(sg->dev, reg_dir, reg);
+}
+
+static int smsc_gpio_direction_output(struct gpio_chip *chip,
+unsigned off, int val)
+{
+ unsigned int reg;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ int reg_dir;
+
+ mutex_lock(&sg->lock);
+ reg_dir = SMSC_CFG_START + off;
+ smsc_read(sg->dev, reg_dir, ®);
+ reg |= SMSC_GPIO_OUTPUT_PP;
+ mutex_unlock(&sg->lock);
+
+ return smsc_write(sg->dev, reg_dir, reg);
+}
+
+static int smsc_gpio_to_irq(struct gpio_chip *chip, unsigned off)
+{
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ return sg->irq_base + off;
+}
+
+static void smsc_irq_bus_lock(struct irq_data *d)
+{
+ struct smsc_gpio *sg = irq_data_get_irq_chip_data(d);
+
+ mutex_lock(&sg->irq_lock);
+}
+
+sta
Re: [PATCH 09/10] mmc: omap_hsmmc: convert from IP timer to hrtimer
On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
> omap hsmmc controller IP has an inbuilt timer that can be programmed to
^^^
built-in
> guard against unresponsive operations. But it's range is very narrow,
its
> and it's maximum countable time is a few seconds.
its
> Card maintenance operations like BKOPS and SECURE DISCARD and long
> stream writes like packed command require timers of order of
> several minutes.
> So get rid of using the IP timer entirely and use kernel's hrtimer
> functionality for guarding the device operations.
> As part of this change, a workaround that disabled timeouts for
> MMC_ERASE commands is removed, and the arbitary timing of 100ms
> is used only when the timeout is not explicitly specified by core.
>
> Signed-off-by: Venkatraman S
> ---
> drivers/mmc/host/omap_hsmmc.c | 96
> ++-
> 1 file changed, 50 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 9afdd20..8f7cebc 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -79,7 +79,7 @@
> #define CLKD_SHIFT 6
> #define DTO_MASK 0x000F
> #define DTO_SHIFT16
> -#define INT_EN_MASK 0x307F0033
> +#define INT_EN_MASK 0x306E0033
not related to this patch in particular, but it would be nice if this
was converted to something more meaningfull, like ORing a bunch of bit
defines.
> #define BWR_ENABLE (1 << 4)
> #define BRR_ENABLE (1 << 5)
> #define DTO_ENABLE (1 << 20)
> @@ -160,6 +160,7 @@ struct omap_hsmmc_host {
> unsigned intdma_sg_idx;
> unsigned char bus_mode;
> unsigned char power_mode;
> + unsigned intns_per_clk_cycle;
> int suspended;
> int irq;
> int use_dma, dma_ch;
> @@ -172,6 +173,7 @@ struct omap_hsmmc_host {
> int reqs_blocked;
> int use_reg;
> int req_in_progress;
> + struct hrtimer guard_timer;
> struct omap_hsmmc_next next_data;
>
> struct omap_mmc_platform_data *pdata;
> @@ -455,10 +457,6 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
> *host,
> else
> irq_mask = INT_EN_MASK;
>
> - /* Disable timeout for erases */
> - if (cmd->opcode == MMC_ERASE)
> - irq_mask &= ~DTO_ENABLE;
> -
> OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
> OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
> @@ -508,6 +506,9 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
> *host)
> && time_before(jiffies, timeout))
> cpu_relax();
>
> + if (ios->clock)
> + host->ns_per_clk_cycle = DIV_ROUND_UP(NSEC_PER_SEC, ios->clock);
> +
> omap_hsmmc_start_clock(host);
> }
>
> @@ -824,7 +825,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
> mmc_data *data)
> omap_hsmmc_request_done(host, mrq);
> return;
> }
> -
> + hrtimer_cancel(&host->guard_timer);
> host->data = NULL;
>
> if (!data->error)
> @@ -859,8 +860,11 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct
> mmc_command *cmd)
> cmd->resp[0] = OMAP_HSMMC_READ(host->base, RSP10);
> }
> }
> - if ((host->data == NULL && !host->response_busy) || cmd->error)
> + if ((host->data == NULL && !host->response_busy) || cmd->error) {
could just go ahead and make this check uniform by:
if ((!host->data && !host->response_busy)) || cmd->error)
> + if (cmd->error != -ETIMEDOUT)
> + hrtimer_cancel(&host->guard_timer);
> omap_hsmmc_request_done(host, cmd->mrq);
> + }
> }
>
> /*
> @@ -992,7 +996,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
> *host, int status)
> hsmmc_command_incomplete(host, -EILSEQ);
>
> end_cmd = 1;
> - if (host->data || host->response_busy) {
> + if (data || host->response_busy) {
This doesn't seem like it belongs to $SUBJECT...
> end_trans = 1;
> host->response_busy = 0;
> }
> @@ -1292,41 +1296,35 @@ static int omap_hsmmc_start_dma_transfer(struct
> omap_hsmmc_host *host,
> return 0;
> }
>
> -static void set_data_timeout(struct omap_hsmmc_host *host,
> - unsigned int timeout_ns,
> - unsigned int timeout_clks)
> +static void set_guard_timer(struct omap_hsmmc_host *host,
> +
Re: [PATCH 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
On Tue, Aug 21, 2012 at 4:14 PM, Benoit Cousson wrote: > Hi Santosh, > [...] From 91d6cb4f999061c8cfc844a3916ee3384f2e488a Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Wed, 4 Jul 2012 17:57:34 +0530 Subject: [PATCH 1/2 v2] ARM: OMAP4: Add L2 Cache Controller in Device Tree This provides PL310 Level 2 Cache Controller Device Tree support for OMAP4 based devices. Cc: Benoit Cousson Signed-off-by: Santosh Shilimkar >>> >>> nice work :-) >>> >>> FWIW this looks good to me: >>> >>> Acked-by: Felipe Balbi >>> >> Thanks. >> >>> just one thing, will a similar patch for omap3 be sent ? >>> >> OMAP3 has an integrated L2 cache controller so there >> won't any additional DT node for L2. >> >> OMAP3 CPU DT node can be updated with l1/l2 cache >> size etc related information though. > > That's not needed if the information is available from the HW. > DT is only there to provide information that cannot be extracted from HW. > Good to know. > If CP15 registers already contains the details about caches, then there > is no need to add them in the DT file. > True. In that case as you said, there is no need to add that information in DT. Regards Santosh -- 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 v6 09/10] ARM: OMAP2+: smc91x: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++--
1 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index ba10c24..43900f9 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -57,6 +57,7 @@ static struct platform_device gpmc_smc91x_device = {
static int smc91c96_gpmc_retime(void)
{
struct gpmc_timings t;
+ struct gpmc_device_timings dev_t;
const int t3 = 10; /* Figure 12.2 read and 12.4 write */
const int t4_r = 20;/* Figure 12.2 read */
const int t4_w = 5; /* Figure 12.4 write */
@@ -67,32 +68,6 @@ static int smc91c96_gpmc_retime(void)
const int t20 = 185;/* Figure 12.2 read and 12.4 write */
u32 l;
- memset(&t, 0, sizeof(t));
-
- /* Read timings */
- t.cs_on = 0;
- t.adv_on = t.cs_on;
- t.oe_on = t.adv_on + t3;
- t.access = t.oe_on + t5;
- t.oe_off = t.access;
- t.adv_rd_off = t.oe_off + max(t4_r, t6);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t20 - t.oe_on;
-
- /* Write timings */
- t.we_on = t.adv_on + t3;
-
- if (cpu_is_omap34xx() && (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)) {
- t.wr_data_mux_bus = t.we_on;
- t.we_off = t.wr_data_mux_bus + t7;
- } else
- t.we_off = t.we_on + t7;
- if (cpu_is_omap34xx())
- t.wr_access = t.we_off;
- t.adv_wr_off = t.we_off + max(t4_w, t8);
- t.cs_wr_off = t.we_off + t4_w;
- t.wr_cycle = t20 - t.we_on;
-
l = GPMC_CONFIG1_DEVICESIZE_16;
if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
l |= GPMC_CONFIG1_MUXADDDATA;
@@ -114,6 +89,22 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
return 0;
+ memset(&dev_t, 0, sizeof(dev_t));
+
+ dev_t.t_oeasu = t3 * 1000;
+ dev_t.t_oe = t5 * 1000;
+ dev_t.t_cez_r = t4_r * 1000;
+ dev_t.t_oez = t6 * 1000;
+ dev_t.t_rd_cycle = (t20 - t3) * 1000;
+
+ dev_t.t_weasu = t3 * 1000;
+ dev_t.t_wpl = t7 * 1000;
+ dev_t.t_wph = t8 * 1000;
+ dev_t.t_cez_w = t4_w * 1000;
+ dev_t.t_wr_cycle = (t20 - t3) * 1000;
+
+ gpmc_calc_timings(&t, &dev_t);
+
return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
}
--
1.7.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
