[PATCH] dspbridge: Simplify Atoi() method (v2)
From: Andy Shevchenko ext-andriy.shevche...@nokia.com
Try to use simple_strtoul() kernel native method instead.
However, there are opened questions:
- why type of Atoi() is s32 if the sign is used only to detect base?
- should we really to check hex integers like DEAD0123h?
- how many spaces could lead token?
Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
drivers/dsp/bridge/rmgr/dbdcd.c | 42 +-
1 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/dbdcd.c b/drivers/dsp/bridge/rmgr/dbdcd.c
index 9efb7dc..a460d1a 100644
--- a/drivers/dsp/bridge/rmgr/dbdcd.c
+++ b/drivers/dsp/bridge/rmgr/dbdcd.c
@@ -1001,50 +1001,20 @@ DSP_STATUS DCD_UnregisterObject(IN struct DSP_UUID
*pUuid,
*/
static s32 Atoi(char *pszBuf)
{
- s32 result = 0;
char *pch = pszBuf;
- char c;
- char first;
- s32 base = 10;
- s32 len;
+ s32 base = 0;
while (isspace(*pch))
pch++;
- first = *pch;
- if (first == '-' || first == '+') {
+ if (*pch == '-' || *pch == '+') {
+ base = 10;
pch++;
- } else {
- /* Determine if base 10 or base 16 */
- len = strlen(pch);
- if (len 1) {
- c = pch[1];
- if ((*pch == '0' (c == 'x' || c == 'X'))) {
- base = 16;
- pch += 2;
- }
- c = pch[len - 1];
- if (c == 'h' || c == 'H')
- base = 16;
-
- }
- }
-
- while (isdigit(c = *pch) || ((base == 16) isxdigit(c))) {
- result *= base;
- if ('A' = c c = 'F') {
- c = c - 'A' + 10;
- } else {
- if ('a' = c c = 'f')
- c = c - 'a' + 10;
- else
- c -= '0';
- }
- result += c;
- ++pch;
+ } else if (*pch tolower(pch[strlen(pch) - 1]) == 'h') {
+ base = 16;
}
- return result;
+ return simple_strtoul(pch, NULL, base);
}
/*
--
1.5.6.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
[PATCHV6 0/3] OMAP3630 Clock changes
THis patch series has Clock changes related to OMAP3630. The major Clock releated changes are 1. DPLL4 type has changed to j type. 2. CLKSEL field width is increased for DPLL4 M2, M3, M4, M5 and M6 3. DPLL4 M2 o/p can be either 96MHz or 192 Mhz (to support s...@192). All the patches have been tested on OMAP3630 ZOOM3 and OMAP3430 ZOOM2 platforms. Comments adressed in V4: 1. Remove sd_div_mask and dco_sel_mask 2. Remove reference to FREQSEL for 3630 3. Avoid dynamically overwriting Fields in Clock nodes Comments Addressed in V5: 1. Comments from Eduardo Valentin, cosmetic changes and splitting of the patch for freqsel changes 2. Comments from Paul regarding updation of Clock nodes Comments Addressed in V6: 1. Cosmetic changes based on Comments from Alex and Paul 2. Added DPLL MULT Mask for 3630 based on Paul's comments Richard Woodruff (1): OMAP3: introduce DPLL4 Jtype Vishwanath BS (3): OMAP3: Introduce 3630 DPLL4 HSDivider changes OMAP3: add support for 192Mhz DPLL4M2 output arch/arm/mach-omap2/clock.h |4 + arch/arm/mach-omap2/clock34xx_data.c| 240 --- arch/arm/mach-omap2/clock44xx_data.c|1 + arch/arm/mach-omap2/cm-regbits-34xx.h | 12 ++ arch/arm/mach-omap2/dpll3xxx.c | 47 ++- arch/arm/mach-omap2/id.c|3 + arch/arm/plat-omap/include/plat/clock.h | 10 +- arch/arm/plat-omap/include/plat/cpu.h |2 + 8 files changed, 299 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHV6 2/3] OMAP3: Introduce 3630 DPLL4 HSDivider changes
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if cpu type is 3630.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx_data.c| 140 +--
arch/arm/mach-omap2/cm-regbits-34xx.h |5 +
arch/arm/plat-omap/include/plat/clock.h |5 +-
3 files changed, 141 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index a6ef778..d75152c 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -237,6 +237,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll4_rates_3630[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_36XX },
+ { .div = 3, .val = 3, .flags = RATE_IN_36XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_36XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_36XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_36XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_36XX },
+ { .div = 8, .val = 8, .flags = RATE_IN_36XX },
+ { .div = 9, .val = 9, .flags = RATE_IN_36XX },
+ { .div = 10, .val = 10, .flags = RATE_IN_36XX },
+ { .div = 11, .val = 11, .flags = RATE_IN_36XX },
+ { .div = 12, .val = 12, .flags = RATE_IN_36XX },
+ { .div = 13, .val = 13, .flags = RATE_IN_36XX },
+ { .div = 14, .val = 14, .flags = RATE_IN_36XX },
+ { .div = 15, .val = 15, .flags = RATE_IN_36XX },
+ { .div = 16, .val = 16, .flags = RATE_IN_36XX },
+ { .div = 17, .val = 17, .flags = RATE_IN_36XX },
+ { .div = 18, .val = 18, .flags = RATE_IN_36XX },
+ { .div = 19, .val = 19, .flags = RATE_IN_36XX },
+ { .div = 20, .val = 20, .flags = RATE_IN_36XX },
+ { .div = 21, .val = 21, .flags = RATE_IN_36XX },
+ { .div = 22, .val = 22, .flags = RATE_IN_36XX },
+ { .div = 23, .val = 23, .flags = RATE_IN_36XX },
+ { .div = 24, .val = 24, .flags = RATE_IN_36XX },
+ { .div = 25, .val = 25, .flags = RATE_IN_36XX },
+ { .div = 26, .val = 26, .flags = RATE_IN_36XX },
+ { .div = 27, .val = 27, .flags = RATE_IN_36XX },
+ { .div = 28, .val = 28, .flags = RATE_IN_36XX },
+ { .div = 29, .val = 29, .flags = RATE_IN_36XX },
+ { .div = 30, .val = 30, .flags = RATE_IN_36XX },
+ { .div = 31, .val = 31, .flags = RATE_IN_36XX },
+ { .div = 32, .val = 32, .flags = RATE_IN_36XX },
+ { .div = 0 }
+};
+
/* DPLL1 */
/* MPU clock source */
/* Type: DPLL */
@@ -606,8 +642,15 @@ static const struct clksel div16_dpll4_clksel[] = {
{ .parent = NULL }
};
+static const struct clksel div32_dpll4_clksel[] = {
+ { .parent = dpll4_ck, .rates = div32_dpll4_rates_3630 },
+ { .parent = NULL }
+};
+
/* This virtual clock is the source for dpll4_m2x2_ck */
-static struct clk dpll4_m2_ck = {
+static struct clk dpll4_m2_ck;
+
+static struct clk dpll4_m2_ck_34xx __initdata = {
.name = dpll4_m2_ck,
.ops= clkops_null,
.parent = dpll4_ck,
@@ -619,6 +662,18 @@ static struct clk dpll4_m2_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll4_m2_ck_3630 __initdata = {
+ .name = dpll4_m2_ck,
+ .ops= clkops_null,
+ .parent = dpll4_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(PLL_MOD, OMAP3430_CM_CLKSEL3),
+ .clksel_mask= OMAP3630_DIV_96M_MASK,
+ .clksel = div32_dpll4_clksel,
+ .clkdm_name = dpll4_clkdm,
+ .recalc = omap2_clksel_recalc,
+};
+
/* The PWRDN bit is apparently only available on 3430ES2 and above */
static struct clk dpll4_m2x2_ck = {
.name = dpll4_m2x2_ck,
@@ -679,7 +734,9 @@ static struct clk omap_96m_fck = {
};
/* This virtual clock is the source for dpll4_m3x2_ck */
-static struct clk dpll4_m3_ck = {
+static struct clk dpll4_m3_ck;
+
+static struct clk dpll4_m3_ck_34xx __initdata = {
.name = dpll4_m3_ck,
.ops= clkops_null,
.parent = dpll4_ck,
@@ -691,6 +748,18 @@ static struct clk dpll4_m3_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll4_m3_ck_3630 __initdata = {
+ .name = dpll4_m3_ck,
+ .ops= clkops_null,
+ .parent = dpll4_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_CLKSEL),
+ .clksel_mask= OMAP3630_CLKSEL_TV_MASK,
+ .clksel = div32_dpll4_clksel,
+
[PATCHV6 3/3] OMAP3: add support for 192Mhz DPLL4M2 output
In 3630, DPLL4M2 o/p can be 96MH or 192MHz (for SGX to run at 192). This
patch has changes to support this feature. 96MHz clock is generated by
dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register.
SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's
functional clock. In summary changes done are 1. Added a feature called
omap3_has_192mhz_clk and enabled for 3630 2. Added a new clock node
called omap_192m_alwon_ck 3. Made omap_96m_alwon_fck to derive it's
clock from omap_192m_alwon_ck
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx_data.c | 72 -
arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
arch/arm/mach-omap2/id.c |3 +
arch/arm/plat-omap/include/plat/cpu.h |2 +
4 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index d75152c..2882722 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -692,18 +692,24 @@ static struct clk dpll4_m2x2_ck = {
* 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and
* CM_96K_(F)CLK.
*/
-static struct clk omap_96m_alwon_fck = {
- .name = omap_96m_alwon_fck,
- .ops= clkops_null,
- .parent = dpll4_m2x2_ck,
- .recalc = followparent_recalc,
+
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_fck = {
+ .name = omap_192m_alwon_fck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
};
-static struct clk cm_96m_fck = {
- .name = cm_96m_fck,
- .ops= clkops_null,
- .parent = omap_96m_alwon_fck,
- .recalc = followparent_recalc,
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_36XX },
+ { .div = 2, .val = 2, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = omap_192m_alwon_fck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
};
static const struct clksel_rate omap_96m_dpll_rates[] = {
@@ -716,6 +722,31 @@ static const struct clksel_rate omap_96m_sys_rates[] = {
{ .div = 0 }
};
+static struct clk omap_96m_alwon_fck = {
+ .name = omap_96m_alwon_fck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
+};
+
+static struct clk omap_96m_alwon_fck_3630 = {
+ .name = omap_96m_alwon_fck,
+ .parent = omap_192m_alwon_fck,
+ .init = omap2_init_clksel_parent,
+ .ops= clkops_null,
+ .recalc = omap2_clksel_recalc,
+ .clksel_reg = OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ .clksel_mask= OMAP3630_CLKSEL_96M_MASK,
+ .clksel = omap_96m_alwon_fck_clksel
+};
+
+static struct clk cm_96m_fck = {
+ .name = cm_96m_fck,
+ .ops= clkops_null,
+ .parent = omap_96m_alwon_fck,
+ .recalc = followparent_recalc,
+};
+
static const struct clksel omap_96m_fck_clksel[] = {
{ .parent = cm_96m_fck, .rates = omap_96m_dpll_rates },
{ .parent = sys_ck, .rates = omap_96m_sys_rates },
@@ -1304,12 +1335,24 @@ static struct clk gfx_cg2_ck = {
/* SGX power domain - 3430ES2 only */
static const struct clksel_rate sgx_core_rates[] = {
+ { .div = 2, .val = 5, .flags = RATE_IN_36XX },
{ .div = 3, .val = 0, .flags = RATE_IN_343X | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_343X },
{ .div = 6, .val = 2, .flags = RATE_IN_343X },
{ .div = 0 },
};
+static const struct clksel_rate sgx_192m_rates[] = {
+ { .div = 1, .val = 4, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 0 },
+};
+
+static const struct clksel_rate sgx_corex2_rates[] = {
+ { .div = 3, .val = 6, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 5, .val = 7, .flags = RATE_IN_36XX },
+ { .div = 0 },
+};
+
static const struct clksel_rate sgx_96m_rates[] = {
{ .div = 1, .val = 3, .flags = RATE_IN_343X | DEFAULT_RATE },
{ .div = 0 },
@@ -1318,7 +1361,9 @@ static const struct clksel_rate sgx_96m_rates[] = {
static const struct clksel sgx_clksel[] = {
{ .parent = core_ck,.rates = sgx_core_rates },
{ .parent = cm_96m_fck, .rates = sgx_96m_rates },
- { .parent = NULL },
+ { .parent = omap_192m_alwon_fck, .rates = sgx_192m_rates },
+ { .parent = corex2_fck, .rates = sgx_corex2_rates },
+ { .parent = NULL }
};
static struct clk sgx_fck = {
@@ -1332,6 +1377,8 @@ static struct clk sgx_fck = {
.clksel = sgx_clksel,
[PATCHV6 1/3] OMAP3: introduce DPLL4 Jtype
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h |4 ++
arch/arm/mach-omap2/clock34xx_data.c| 32 -
arch/arm/mach-omap2/clock44xx_data.c|1 +
arch/arm/mach-omap2/cm-regbits-34xx.h |5 +++
arch/arm/mach-omap2/dpll3xxx.c | 47 ++-
arch/arm/plat-omap/include/plat/clock.h |5 +++
6 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index fb17833..6f6b110 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,10 @@
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+/* DPLL Type and DCO Selection Flags */
+#define DPLL_J_TYPE0x1
+#define DPLL_NO_DCO_SEL0x2
+
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
long omap2_clk_round_rate(struct clk *clk, unsigned long rate);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8728f1f..a6ef778
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -38,6 +38,7 @@
/* Maximum DPLL multiplier, divider values for OMAP3 */
#define OMAP3_MAX_DPLL_MULT2048
+#define OMAP3630_MAX_JTYPE_DPLL_MULT 4095
#define OMAP3_MAX_DPLL_DIV 128
/*
@@ -529,7 +530,8 @@ static struct clk emu_core_alwon_ck = {
/* DPLL4 */
/* Supplies 96MHz, 54Mhz TV DAC, DSS fclk, CAM sensor clock, emul trace clk */
/* Type: DPLL */
-static struct dpll_data dpll4_dd = {
+static struct dpll_data dpll4_dd;
+static struct dpll_data dpll4_dd_34xx __initdata = {
.mult_div1_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL2),
.mult_mask = OMAP3430_PERIPH_DPLL_MULT_MASK,
.div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
@@ -552,6 +554,29 @@ static struct dpll_data dpll4_dd = {
.rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE
};
+static struct dpll_data dpll4_dd_3630 __initdata = {
+ .mult_div1_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL2),
+ .mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK,
+ .div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
+ .clk_bypass = sys_ck,
+ .clk_ref= sys_ck,
+ .control_reg= OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
+ .enable_mask= OMAP3430_EN_PERIPH_DPLL_MASK,
+ .modes = (1 DPLL_LOW_POWER_STOP) | (1 DPLL_LOCKED),
+ .auto_recal_bit = OMAP3430_EN_PERIPH_DPLL_DRIFTGUARD_SHIFT,
+ .recal_en_bit = OMAP3430_PERIPH_DPLL_RECAL_EN_SHIFT,
+ .recal_st_bit = OMAP3430_PERIPH_DPLL_ST_SHIFT,
+ .autoidle_reg = OMAP_CM_REGADDR(PLL_MOD, CM_AUTOIDLE),
+ .autoidle_mask = OMAP3430_AUTO_PERIPH_DPLL_MASK,
+ .idlest_reg = OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST),
+ .idlest_mask= OMAP3430_ST_PERIPH_CLK_MASK,
+ .max_multiplier = OMAP3630_MAX_JTYPE_DPLL_MULT,
+ .min_divider= 1,
+ .max_divider= OMAP3_MAX_DPLL_DIV,
+ .rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE,
+ .flags = DPLL_J_TYPE
+};
+
static struct clk dpll4_ck = {
.name = dpll4_ck,
.ops= omap3_clkops_noncore_dpll_ops,
@@ -3240,6 +3265,11 @@ int __init omap3xxx_clk_init(void)
}
}
+ if (cpu_is_omap3630())
+ dpll4_dd = dpll4_dd_3630;
+ else
+ dpll4_dd = dpll4_dd_34xx;
+
clk_init(omap2_clk_functions);
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 86af31d..8d8b573 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -980,6 +980,7 @@ static struct dpll_data dpll_usb_dd = {
.max_multiplier = OMAP4430_MAX_DPLL_MULT,
.max_divider= OMAP4430_MAX_DPLL_DIV,
.min_divider= 1,
+ .flags = DPLL_J_TYPE | DPLL_NO_DCO_SEL
};
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..ab9b909
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -517,8 +517,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3630_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define
[PATCH] ARM: OMAP4 clock domain: Add check for avoiding dependency related update.
A check is added for avoiding the sleep/wakeup dependency updates for OMAP4 as the structures for the dependencies are currently absent. Signed-off-by: Abhijit Pagare abhijitpag...@ti.com Cc: Paul Walmsley p...@pwsan.com --- Re-submitting Compiled and Boot Tested on OMAP4430 simulator, ES1 Chip OMAP3430 SDP. And also Compiled for OMAP2430 and OMAP2420 This patch has a dependency on the earlier set of OMAP4 clock-domain patches. arch/arm/mach-omap2/clockdomain.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index 8c9e78c..6ec25ee 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -507,8 +507,9 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm) pr_debug(clockdomain: enabling automatic idle transitions for %s\n, clkdm-name); - if (atomic_read(clkdm-usecount) 0) - _clkdm_add_autodeps(clkdm); + if (!cpu_is_omap44xx()) + if (atomic_read(clkdm-usecount) 0) + _clkdm_add_autodeps(clkdm); _omap2_clkdm_set_hwsup(clkdm, 1); @@ -540,8 +541,9 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm) _omap2_clkdm_set_hwsup(clkdm, 0); - if (atomic_read(clkdm-usecount) 0) - _clkdm_del_autodeps(clkdm); + if (!cpu_is_omap44xx()) + if (atomic_read(clkdm-usecount) 0) + _clkdm_del_autodeps(clkdm); } -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the omap_dss2 tree with the omap tree
On Tue, 2010-02-09 at 17:52 +0100, ext Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@nokia.com [100208 01:23]: On Mon, 2010-02-08 at 07:25 +0100, ext Stephen Rothwell wrote: Hi Tomi, Today's linux-next merge of the omap_dss2 tree got a conflict in arch/arm/mach-omap2/board-am3517evm.c between commit 13560d875d67c06239c82a6148c1b87075701fe9 (AM3517: Enable basic I2C Support) from the omap tree and commit 56a3d0235cd50d14d7bd4d45e55d192aa0e78cac (OMAP: AM3517: Enable DSS2 for AM3517EVM board) from the omap_dss2 tree. Juts overlapping additions. I fixed it up (see below) and can carry the fix as necessary. Thanks. I guess we can't properly fix this until the patch from omap tree goes into mainline. Let's move the AM3517 DSS2 board patch from Tomi's tree to omap for-next tree. Tony, do you think this current way, in which we have board file changes in both linux-omap and the dss tree, is best we can do? Or should all the board file changes go through linux-omap? I fear that we will have conflicts with every new board. Yeah we should just move the conflicting files into omap for-next. The board file changes conflict easily when new platform device init code is being added. Tomi, how about you ack and let me know about the patches (or git branch) you want me to add into omap for-next? Otherwise I'll assume anything DSS2 related is yours. This sounds good. However, we need to be careful that there are no dependencies from the board file patches to the DSS patches (like panel drivers). But this is getting out of topic for this mail thread, let's deal with this separately =). 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
[PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
From bf2ca8fc8f02b94119efd69c0a4eb9621120f064 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 10 Feb 2010 02:26:13 -0600
Subject: [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
This patch protects the Resorce cleanup lists from
concurrent access
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/pmgr/wcd.c | 16 ++-
drivers/dsp/bridge/rmgr/drv.c | 71 ++-
drivers/dsp/bridge/rmgr/drv_interface.c |8 +++-
3 files changed, 80 insertions(+), 15 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index b086c0f..bd2bfa3 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1121,17 +1121,23 @@ bool validate_node_handle(struct NODE_OBJECT *hNode,
void *pr_ctxt)
{
bool retVal = false;
struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
- struct NODE_RES_OBJECT *pNode = pCtxt-pNodeList;
+ struct NODE_RES_OBJECT *pNode;
if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
retVal = true;
+ if (mutex_lock_interruptible(pCtxt-node_mutex))
+ return DSP_EFAIL;
+
+ pNode = pCtxt-pNodeList;
while (pNode !retVal) {
if (hNode == pNode-hNode)
retVal = true;
pNode = pNode-next;
}
+ mutex_unlock(pCtxt-node_mutex);
+
return retVal;
}
@@ -1570,14 +1576,20 @@ bool validate_strm_handle(struct STRM_OBJECT *hStrm,
void *pr_ctxt)
{
bool retVal = false;
struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
- struct STRM_RES_OBJECT *pStrm = pCtxt-pSTRMList;
+ struct STRM_RES_OBJECT *pStrm;
+ if (mutex_lock_interruptible(pCtxt-strm_mutex))
+ return DSP_EFAIL;
+
+pStrm = pCtxt-pSTRMList;
while (pStrm !retVal) {
if (hStrm == pStrm-hStream)
retVal = true;
pStrm = pStrm-next;
}
+ mutex_unlock(pCtxt-strm_mutex);
+
return retVal;
}
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 36bab9f..3def337 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -97,6 +97,10 @@ DSP_STATUS DRV_InsertNodeResElement(HANDLE hNode, HANDLE
hNodeRes,
status = DSP_EHANDLE;
}
if (DSP_SUCCEEDED(status)) {
+ if (mutex_lock_interruptible(pCtxt-node_mutex)) {
+ MEM_Free(*pNodeRes);
+ return DSP_EFAIL;
+ }
(*pNodeRes)-hNode = hNode;
if (pCtxt-pNodeList != NULL) {
pTempNodeRes = pCtxt-pNodeList;
@@ -111,6 +115,7 @@ DSP_STATUS DRV_InsertNodeResElement(HANDLE hNode, HANDLE
hNodeRes,
GT_0trace(curTrace, GT_ENTER,
DRV_InsertNodeResElement: 3);
}
+ mutex_unlock(pCtxt-node_mutex);
}
GT_0trace(curTrace, GT_ENTER, DRV_InsertNodeResElement: 4);
return status;
@@ -123,7 +128,10 @@ DSP_STATUS DRV_RemoveNodeResElement(HANDLE hNodeRes,
HANDLE hPCtxt)
struct NODE_RES_OBJECT *pNodeRes = (struct NODE_RES_OBJECT *)hNodeRes;
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
struct NODE_RES_OBJECT *pTempNode;
+ DSP_STATUS status = DSP_SOK;
+ if (mutex_lock_interruptible(pCtxt-node_mutex))
+ return DSP_EFAIL;
pTempNode = pCtxt-pNodeList;
if (pTempNode == pNodeRes) {
pCtxt-pNodeList = pNodeRes-next;
@@ -131,11 +139,13 @@ DSP_STATUS DRV_RemoveNodeResElement(HANDLE hNodeRes,
HANDLE hPCtxt)
while (pTempNode pTempNode-next != pNodeRes)
pTempNode = pTempNode-next;
if (!pTempNode)
- return DSP_ENOTFOUND;
- pTempNode-next = pNodeRes-next;
+ status = DSP_ENOTFOUND;
+ else
+ pTempNode-next = pNodeRes-next;
}
+ mutex_unlock(pCtxt-node_mutex);
kfree(pNodeRes);
- return DSP_SOK;
+ return status;
}
/* Actual Node De-Allocation */
@@ -200,6 +210,11 @@ DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE
hPCtxt)
status = DSP_EHANDLE;
}
if (DSP_SUCCEEDED(status)) {
+ if (mutex_lock_interruptible(pCtxt-dmm_mutex)) {
+ MEM_Free(*pDMMRes);
+ return DSP_EFAIL;
+ }
+
if (pCtxt-pDMMList != NULL) {
GT_0trace(curTrace, GT_5CLASS,
DRV_InsertDMMResElement: 3);
@@ -213,6 +228,7 @@ DSP_STATUS DRV_InsertDMMResElement(HANDLE hDMMRes, HANDLE
hPCtxt)
GT_0trace(curTrace, GT_5CLASS,
[RESEND] [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
Please discard previous one.
Regards,
Fernando.
From 6bcdc02f6265246e385194433775e75db7ad44cf Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Wed, 10 Feb 2010 02:31:40 -0600
Subject: [PATCH] DSPBRIDGE: Adding protection Resource cleanup linked lists
This patch protects the Resorce cleanup lists from
concurrent access
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/drv.h |3 +
drivers/dsp/bridge/pmgr/wcd.c | 16 ++-
drivers/dsp/bridge/rmgr/drv.c | 71 +++
drivers/dsp/bridge/rmgr/drv_interface.c|8 ++-
4 files changed, 83 insertions(+), 15 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index b6a5fd2..b044291 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -137,15 +137,18 @@ struct PROCESS_CONTEXT{
/* DSP Node resources */
struct NODE_RES_OBJECT *pNodeList;
+ struct mutex node_mutex;
/* DMM resources */
struct DMM_RES_OBJECT *pDMMList;
+ struct mutex dmm_mutex;
/* DSP Heap resources */
struct DSPHEAP_RES_OBJECT *pDSPHEAPList;
/* Stream resources */
struct STRM_RES_OBJECT *pSTRMList;
+ struct mutex strm_mutex;
} ;
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index b086c0f..bd2bfa3 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -1121,17 +1121,23 @@ bool validate_node_handle(struct NODE_OBJECT *hNode,
void *pr_ctxt)
{
bool retVal = false;
struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
- struct NODE_RES_OBJECT *pNode = pCtxt-pNodeList;
+ struct NODE_RES_OBJECT *pNode;
if (hNode == (struct NODE_OBJECT *) DSP_HGPPNODE)
retVal = true;
+ if (mutex_lock_interruptible(pCtxt-node_mutex))
+ return DSP_EFAIL;
+
+ pNode = pCtxt-pNodeList;
while (pNode !retVal) {
if (hNode == pNode-hNode)
retVal = true;
pNode = pNode-next;
}
+ mutex_unlock(pCtxt-node_mutex);
+
return retVal;
}
@@ -1570,14 +1576,20 @@ bool validate_strm_handle(struct STRM_OBJECT *hStrm,
void *pr_ctxt)
{
bool retVal = false;
struct PROCESS_CONTEXT *pCtxt = pr_ctxt;
- struct STRM_RES_OBJECT *pStrm = pCtxt-pSTRMList;
+ struct STRM_RES_OBJECT *pStrm;
+ if (mutex_lock_interruptible(pCtxt-strm_mutex))
+ return DSP_EFAIL;
+
+pStrm = pCtxt-pSTRMList;
while (pStrm !retVal) {
if (hStrm == pStrm-hStream)
retVal = true;
pStrm = pStrm-next;
}
+ mutex_unlock(pCtxt-strm_mutex);
+
return retVal;
}
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 36bab9f..e8b2c58 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -97,6 +97,10 @@ DSP_STATUS DRV_InsertNodeResElement(HANDLE hNode, HANDLE
hNodeRes,
status = DSP_EHANDLE;
}
if (DSP_SUCCEEDED(status)) {
+ if (mutex_lock_interruptible(pCtxt-node_mutex)) {
+ kfree(*pNodeRes);
+ return DSP_EFAIL;
+ }
(*pNodeRes)-hNode = hNode;
if (pCtxt-pNodeList != NULL) {
pTempNodeRes = pCtxt-pNodeList;
@@ -111,6 +115,7 @@ DSP_STATUS DRV_InsertNodeResElement(HANDLE hNode, HANDLE
hNodeRes,
GT_0trace(curTrace, GT_ENTER,
DRV_InsertNodeResElement: 3);
}
+ mutex_unlock(pCtxt-node_mutex);
}
GT_0trace(curTrace, GT_ENTER, DRV_InsertNodeResElement: 4);
return status;
@@ -123,7 +128,10 @@ DSP_STATUS DRV_RemoveNodeResElement(HANDLE hNodeRes,
HANDLE hPCtxt)
struct NODE_RES_OBJECT *pNodeRes = (struct NODE_RES_OBJECT *)hNodeRes;
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
struct NODE_RES_OBJECT *pTempNode;
+ DSP_STATUS status = DSP_SOK;
+ if (mutex_lock_interruptible(pCtxt-node_mutex))
+ return DSP_EFAIL;
pTempNode = pCtxt-pNodeList;
if (pTempNode == pNodeRes) {
pCtxt-pNodeList = pNodeRes-next;
@@ -131,11 +139,13 @@ DSP_STATUS DRV_RemoveNodeResElement(HANDLE hNodeRes,
HANDLE hPCtxt)
while (pTempNode pTempNode-next != pNodeRes)
pTempNode = pTempNode-next;
if (!pTempNode)
- return DSP_ENOTFOUND;
- pTempNode-next = pNodeRes-next;
+ status = DSP_ENOTFOUND;
+ else
+ pTempNode-next = pNodeRes-next;
}
+
RE: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 05, 2010 10:09 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM * Hiremath, Vaibhav hvaib...@ti.com [100204 21:31]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, February 05, 2010 6:35 AM To: linux-omap@vger.kernel.org Subject: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM This patch has been applied to the linux-omap by youw fwiendly patch wobot. [Hiremath, Vaibhav] Tony, Please revert this single commit. Actually I had a discussion with Dmitry Torokhov and the conclusion is, as of now for TSC2004 we can reuse TSC2007, and once they start diverging we can split them. I will be submitting patches for this support shortly. So please revert hits commit. Yeah noticed that as they did not compile with omap3_defconfig. Reverted all of them except patch AM3517: Enable basic I2C Support. [Hiremath, Vaibhav] Tony, The issue was only with TSC2004 support patch, all other patches should go in, since the driver is already being supported in Linux kernel, it was just hookup part. So can you please merge all other patches expect TSC2004 support? Thanks, Vaibhav Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-next: manual merge of the omap_dss2 tree with the omap tree
Thanks,
Vaibhav Hiremath
Platform Support Products
Texas Instruments Inc
Ph: +91-80-25099927
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Monday, February 08, 2010 11:55 AM
To: Tomi Valkeinen
Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org;
Hiremath, Vaibhav; Tony Lindgren; linux-omap@vger.kernel.org
Subject: linux-next: manual merge of the omap_dss2 tree with the
omap tree
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-am3517evm.c between commit
13560d875d67c06239c82a6148c1b87075701fe9 (AM3517: Enable basic I2C
Support) from the omap tree and commit
56a3d0235cd50d14d7bd4d45e55d192aa0e78cac (OMAP: AM3517: Enable DSS2
for
AM3517EVM board) from the omap_dss2 tree.
Juts overlapping additions. I fixed it up (see below) and can
carry the
fix as necessary.
P.S. Tomi, this omap_dss2 commit only has your Acked-by not Signed-
off-by.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-am3517evm.c
index a166bcc,54af5f8..000
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@@ -33,15 -33,147 +34,156 @@@
#include mux.h
[Hiremath, Vaibhav] I don't see display.h being added here, but when I looked
into linux-next repo, I could see that. I think the following commit only shows
for the conflicted part, so should be ok.
Thanks,
Vaibhav
+ #define LCD_PANEL_PWR 176
+ #define LCD_PANEL_BKLIGHT_PWR 182
+ #define LCD_PANEL_PWM 181
+
+ static int lcd_enabled;
+ static int dvi_enabled;
+
+ static void __init am3517_evm_display_init(void)
+ {
+ int r;
+
+ omap_mux_init_gpio(LCD_PANEL_PWR, OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_gpio(LCD_PANEL_BKLIGHT_PWR,
OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_gpio(LCD_PANEL_PWM, OMAP_PIN_INPUT_PULLDOWN);
+ /*
+ * Enable GPIO 182 = LCD Backlight Power
+ */
+ r = gpio_request(LCD_PANEL_BKLIGHT_PWR, lcd_backlight_pwr);
+ if (r) {
+ printk(KERN_ERR failed to get lcd_backlight_pwr\n);
+ return;
+ }
+ gpio_direction_output(LCD_PANEL_BKLIGHT_PWR, 1);
+ /*
+ * Enable GPIO 181 = LCD Panel PWM
+ */
+ r = gpio_request(LCD_PANEL_PWM, lcd_pwm);
+ if (r) {
+ printk(KERN_ERR failed to get lcd_pwm\n);
+ goto err_1;
+ }
+ gpio_direction_output(LCD_PANEL_PWM, 1);
+ /*
+ * Enable GPIO 176 = LCD Panel Power enable pin
+ */
+ r = gpio_request(LCD_PANEL_PWR, lcd_panel_pwr);
+ if (r) {
+ printk(KERN_ERR failed to get lcd_panel_pwr\n);
+ goto err_2;
+ }
+ gpio_direction_output(LCD_PANEL_PWR, 1);
+
+ printk(KERN_INFO Display initialized successfully\n);
+ return;
+
+ err_2:
+ gpio_free(LCD_PANEL_PWM);
+ err_1:
+ gpio_free(LCD_PANEL_BKLIGHT_PWR);
+ }
+
+ static int am3517_evm_panel_enable_lcd(struct omap_dss_device
*dssdev)
+ {
+ if (dvi_enabled) {
+ printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
+ return -EINVAL;
+ }
+ gpio_set_value(LCD_PANEL_PWR, 1);
+ lcd_enabled = 1;
+
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_lcd(struct omap_dss_device
*dssdev)
+ {
+ gpio_set_value(LCD_PANEL_PWR, 0);
+ lcd_enabled = 0;
+ }
+
+ static struct omap_dss_device am3517_evm_lcd_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = lcd,
+ .driver_name= sharp_lq_panel,
+ .phy.dpi.data_lines = 16,
+ .platform_enable= am3517_evm_panel_enable_lcd,
+ .platform_disable = am3517_evm_panel_disable_lcd,
+ };
+
+ static int am3517_evm_panel_enable_tv(struct omap_dss_device
*dssdev)
+ {
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_tv(struct omap_dss_device
*dssdev)
+ {
+ }
+
+ static struct omap_dss_device am3517_evm_tv_device = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = tv,
+ .driver_name= venc,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable= am3517_evm_panel_enable_tv,
+ .platform_disable = am3517_evm_panel_disable_tv,
+ };
+
+ static int am3517_evm_panel_enable_dvi(struct omap_dss_device
*dssdev)
+ {
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+ dvi_enabled = 1;
+
+ return 0;
+ }
+
+ static void am3517_evm_panel_disable_dvi(struct omap_dss_device
*dssdev)
+ {
+ dvi_enabled = 0;
+ }
+
+ static struct omap_dss_device am3517_evm_dvi_device = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = dvi,
+ .driver_name
Re: PATCH[V2 1/3]: Update Platform files for SPI
On Tue, Feb 9, 2010 at 4:07 PM, Tony Lindgren t...@atomide.com wrote: * Grant Likely grant.lik...@secretlab.ca [100209 14:38]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. git bisect breakage is breakage enough. :-) You're right. I should pick this one up. I can see that now that I've had my tea and I'm no longer grumpy. I guess eventually this header should not live under plat. Any reason the header cannot be moved to include/linux/spi/ now? Quite a few board files use this header file, which would also require changes. Tony, are you ok with accepting changes to board files. Thanks Hemanth g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
These patches add support for SDIO cards to the omap_hsmmc driver. Less restrictions on the sizes of transfers, power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. David Vrabel (3): mmc: omap_hsmmc: use packet sync'd DMA mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts drivers/mmc/host/omap_hsmmc.c | 123 ++--- 1 files changed, 78 insertions(+), 45 deletions(-) -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA
Use packet sync'd DMA in the omap_hsmmc driver to avoid the
restriction that transfers must be a multiple of the block size. This
is required for byte-mode transfers to SDIO cards.
Signed-off-by: David Vrabel david.vra...@csr.com
---
drivers/mmc/host/omap_hsmmc.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..e7142a2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK 9600
+#define OMAP_HSMMC_FIFO_WORDS (512/4)
#define DRIVER_NAMEmmci-omap-hs
/* Timeouts for entering power saving states on inactivity, msec */
@@ -887,12 +888,12 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
dma_ch = host-dma_ch;
if (data-flags MMC_DATA_WRITE) {
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0,
OMAP_HSMMC_FIFO_WORDS);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
} else {
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0,
OMAP_HSMMC_FIFO_WORDS);
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
}
@@ -901,7 +902,7 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
nblk = sg_dma_len(sgl) / blksz;
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S32,
- blksz / 4, nblk, OMAP_DMA_SYNC_FRAME,
+ blksz / 4, nblk, OMAP_DMA_SYNC_PACKET,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data-flags MMC_DATA_WRITE));
@@ -944,17 +945,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, void
*data)
static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
struct mmc_request *req)
{
- int dma_ch = 0, ret = 0, err = 1, i;
+ int dma_ch = 0, ret = 0, err = 1;
struct mmc_data *data = req-data;
- /* Sanity check: all the SG entries must be aligned by block size. */
- for (i = 0; i data-sg_len; i++) {
- struct scatterlist *sgl;
-
- sgl = data-sg + i;
- if (sgl-length % data-blksz)
- return -EINVAL;
- }
if ((data-blksz % 4) != 0)
/* REVISIT: The MMC buffer increments only when MSB is written.
* Return error for blksz which is non multiple of four.
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mmc: omap_hsmmc: don't turn SDIO cards off when idle
Don't turn SDIO cards off to save power. Doing so will lose all
internal state in the card.
Signed-off-by: David Vrabel david.vra...@csr.com
---
drivers/mmc/host/omap_hsmmc.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e7142a2..e6d8cb3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/mmc/host.h
#include linux/mmc/core.h
+#include linux/mmc/card.h
#include linux/io.h
#include linux/semaphore.h
#include plat/dma.h
@@ -1359,8 +1360,12 @@ static int omap_hsmmc_sleep_to_off(struct
omap_hsmmc_host *host)
mmc_slot(host).card_detect ||
(mmc_slot(host).get_cover_state
mmc_slot(host).get_cover_state(host-dev, host-slot_id {
- mmc_release_host(host-mmc);
- return 0;
+ goto out;
+ }
+
+ /* Don't turn SDIO cards off. */
+ if (host-mmc-card mmc_card_sdio(host-mmc-card)) {
+ goto out;
}
mmc_slot(host).set_power(host-dev, host-slot_id, 0, 0);
@@ -1371,9 +1376,8 @@ static int omap_hsmmc_sleep_to_off(struct omap_hsmmc_host
*host)
host-dpm_state == CARDSLEEP ? CARDSLEEP : REGSLEEP);
host-dpm_state = OFF;
-
+out:
mmc_release_host(host-mmc);
-
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.
FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
As noted in the FIXME comment, I think the correct thing to do is to
always leave FCLK enabled. The clock/clockdomain subsystems should be
configuring smart-idle mode making explicit calls to disable FCLK
unnecessary. I couldn't follow the clock subsystem to see if it was
actually doing this, though.
---
drivers/mmc/host/omap_hsmmc.c | 94 -
1 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e6d8cb3..ad0f867 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -84,10 +87,12 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define IWE(1 24)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR(1 15)
#define CMD_TIMEOUT(1 16)
#define DATA_TIMEOUT (1 20)
@@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- /*
-* Clear status bits and enable interrupts
-*/
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
-
if (host-use_dma)
OMAP_HSMMC_WRITE(host-base, IE,
INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
@@ -638,18 +637,21 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
struct mmc_data *data;
- int end_cmd = 0, end_trans = 0, status;
+ u32 status;
+ int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
spin_lock(host-irq_lock);
- if (host-mrq == NULL) {
- OMAP_HSMMC_WRITE(host-base, STAT,
- OMAP_HSMMC_READ(host-base, STAT));
- /* Flush posted write */
- OMAP_HSMMC_READ(host-base, STAT);
- spin_unlock(host-irq_lock);
- return IRQ_HANDLED;
- }
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ OMAP_HSMMC_WRITE(host-base, STAT, status);
+ OMAP_HSMMC_READ(host-base, STAT); /* Flush posted write. */
+
+ if (status CIRQ)
+ card_irq = true;
+
+ if (host-mrq == NULL)
+ goto out;
data = host-data;
status =
Re: [PATCH] OMAP: hsmmc: fix memory leak
Hi,
On Wed, 10 Feb 2010, Tony Lindgren wrote:
* Aaro Koskinen aaro.koski...@nokia.com [100208 04:29]:
The platform data allocated with kmalloc() will become unreachable once
the init is complete, so it should be freed. The problem was discovered
by kmemleak.
Looks like this is safe to do as platform_device_add_data does kmemdup
on the data.
BTW, if you want to create a version for 2.6.33, we should still have
enough time to queue it as a fix. It's a very limited size leak though,
but still a leak.
The version for 2.6.33 is below (also attached).
...
From: Aaro Koskinen aaro.koski...@nokia.com
Date: Thu, 4 Feb 2010 13:06:59 +0200
Subject: [PATCH] OMAP: hsmmc: fix memory leak
The platform data allocated with kmalloc() will become unreachable once
the init is complete, so it should be freed. The problem was discovered
by kmemleak.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/mmc-twl4030.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 0c3c72d..8afe9dd 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -408,6 +408,7 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
{
struct twl4030_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
+ int i;
if (cpu_is_omap2430()) {
control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
@@ -434,7 +435,7 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
mmc = kzalloc(sizeof(struct omap_mmc_platform_data),
GFP_KERNEL);
if (!mmc) {
pr_err(Cannot allocate memory for mmc device!\n);
- return;
+ goto done;
}
if (c-name)
@@ -532,6 +533,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info
*controllers)
continue;
c-dev = mmc-dev;
}
+
+done:
+ for (i = 0; i nr_hsmmc; i++)
+ kfree(hsmmc_data[i]);
}
#endif
--
1.5.6.5
From 6d15f48ecc177bde18033af2884eb2c5ce53bfd7 Mon Sep 17 00:00:00 2001
From: Aaro Koskinen aaro.koski...@nokia.com
Date: Thu, 4 Feb 2010 13:06:59 +0200
Subject: [PATCH] OMAP: hsmmc: fix memory leak
The platform data allocated with kmalloc() will become unreachable once
the init is complete, so it should be freed. The problem was discovered
by kmemleak.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/mmc-twl4030.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-twl4030.c
index 0c3c72d..8afe9dd 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -408,6 +408,7 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info *controllers)
{
struct twl4030_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
+ int i;
if (cpu_is_omap2430()) {
control_pbias_offset = OMAP243X_CONTROL_PBIAS_LITE;
@@ -434,7 +435,7 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info *controllers)
mmc = kzalloc(sizeof(struct omap_mmc_platform_data), GFP_KERNEL);
if (!mmc) {
pr_err(Cannot allocate memory for mmc device!\n);
- return;
+ goto done;
}
if (c-name)
@@ -532,6 +533,10 @@ void __init twl4030_mmc_init(struct twl4030_hsmmc_info *controllers)
continue;
c-dev = mmc-dev;
}
+
+done:
+ for (i = 0; i nr_hsmmc; i++)
+ kfree(hsmmc_data[i]);
}
#endif
--
1.5.6.5
Re: Ubuntu installation on omap
Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 6:04 PM, Niamathullah sharief omap...@gmail.com wrote: Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 11:20 AM, Menon, Nishanth n...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Wednesday, February 10, 2010 7:30 AM On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? it is like working without graphics driver Is'nt http://groups.google.com/group/beagleboard/ having more folks Who can specifically help on beagleboard? Could we take the discussion there? Regards, Nishanth Menon -- 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: Ubuntu installation on omap
sorry i followed this link to create uImage http://elinux.org/BeagleBoardUbuntu#Create_uImage_for_U-Boot; now whether my bootm env is correct? On Wed, Feb 10, 2010 at 6:05 PM, Niamathullah sharief omap...@gmail.com wrote: Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 6:04 PM, Niamathullah sharief omap...@gmail.com wrote: Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 11:20 AM, Menon, Nishanth n...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Wednesday, February 10, 2010 7:30 AM On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? it is like working without graphics driver Is'nt http://groups.google.com/group/beagleboard/ having more folks Who can specifically help on beagleboard? Could we take the discussion there? Regards, Nishanth Menon -- 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: USB lockup on OMAP3530
snip So far I have tried many versions of the linux-omap and linux-omap-pm kernel, from about 2.6.30 to the latest git version. They all exhibit the USB OTG death bug. I've used kernels with openembedded patches and without, currently without. Yesterday I discovered the musb_hdrc.fifo_mode parameter and played around with it. I also modified the given configurations. Result: - FIFO configurations including .mode = BUF_DOUBLE don't work at all - no devices work. - the USB death bug is not fixed by: - using only one endpoint - using no TXRX entries but only separate RX and TX (every endpoint gets a TX and an RX entry though) - using a large number of endpoints with same maxpacket value ... still no solution. Enabling debug output of the musb_hdrc driver (yes I've also compiled in debug messages) is not very practical due to the high volume of messages; also, when the bug occurs nothing special is printed. The first error usually comes from the memory manager / filesystem complaining that it can't do IO to offline device, i.e. the disappeared external harddisk (which contains the swapfile). I would *really* appreciate somebody looking into this because this currently makes the hardware as useful as a brick for me. I can supply debug output and test patches. Would you care to try these two patches please? http://marc.info/?l=linux-usbm=125957336716915w=2 And The dependency patch: http://marc.info/?l=linux-usbm=125879861004131w=2 Let me know if these fix the bug for you. - Anand -- 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] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
On Wed, Feb 10, 2010 at 05:06:26AM +0100, ext Guzman Lugo, Fernando wrote: At this point there's an obvious question; what's the point of reserving a memory region and not mapping it? I remember the answer from Hari was: some clients prefer to reserve a big region once, and map parts of it continuously. I have my doubts that the use-case even works with the current code-base. But assuming it does work, your proposed changes would break it. Resource cleanup does not support that even without my proposed changes. Aha! I suspected it :P I just proposed a solution which fixes two issues in one patch. Moreover if this change is merged when the second issue be fixed this patch will not needed anymore, so why don't merge the patch which fixes both errors at this moment? simple patches complicated patches Personally I think your patches should be a continuation to the patches I just proposed. If nobody wants to split these patches, I'll gladly do so. +u32 dsp_res_addr = p_cur_res-ulDSPResAddr; + +status = PROC_UnMap(p_cur_res-hProcessor, + (void *)p_cur_res-ulDSPAddr, p_ctxt); It would be much easier to merge the two functions into one. Yes, I am agreed. Good. Perhaps we can start moving reserve/unreserve functionality to map/unmap, and eventually depreate the former. Cheers. -- Felipe Contreras -- 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] DSPBRIDGE: Fix to avoid possible recursive locking
Hi Deepak,
On Wed, 2010-02-10 at 02:01 +0100, ext Deepak Chitriki wrote:
This patch fixes possible recursive locking detection.The implementation
in which the spinlock is acquired and released is rectified in WMD_MSG_Get()
to avoid locking contention.
Added SYNC_EnterCS() and SYNC_LeaveCS()in WMD_MSG_Get()function.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 50201e5..8faf5ad 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -300,8 +300,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
@@ -352,8 +354,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
/* Exit critical section */
Can you explain the need of calling NTFY_Notify() in WMD_MSG_Get()?
I can see that the InputMsg calls NTFY_Notify() already!
Can we get rid of NTFY_Notify() from WMD_MSG_Get() all together?
Cheers,
Ameya.
--
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] OMAP: hsmmc: fix memory leak
On Mon, 2010-02-08 at 14:33 +0200, Aaro Koskinen wrote: The platform data allocated with kmalloc() will become unreachable once the init is complete, so it should be freed. The problem was discovered by kmemleak. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com You forgot to add: Acked-by: Adrian Hunter adrian.hun...@nokia.com -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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] DSPBRIDGE: check pointer before calling Proc_Detach
Hi, On Thu, 2010-02-04 at 22:17 +0100, ext Omar Ramirez Luna wrote: From: Ernest Ramos Falcon erne...@ti.com This patch adds a check before calling Proc_Detach, otherwise in case a failure occurs on PROC_Attach and hProcessor is invalid when the userspace task closes its handle, unexpected behavior might be seen as this pointer is dereferenced in PROC_Detach. Signed-off-by: Ernest Ramos Falcon erne...@ti.com --- drivers/dsp/bridge/rmgr/drv_interface.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index 32aff66..b0f0d93 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -539,7 +539,8 @@ static int bridge_release(struct inode *ip, struct file *filp) pr_ctxt = filp-private_data; flush_signals(current); DRV_RemoveAllResources(pr_ctxt); - PROC_Detach(pr_ctxt); + if (pr_ctxt-hProcessor) + PROC_Detach(pr_ctxt); MEM_Free(pr_ctxt); filp-private_data = NULL; I guess PROC_Detach already checks for a valid hProcessor handle! Why we need this check here again? Also if you go ahead with this patch, then how are you going to cover a use case where userspace application calls PROC_Attach() which fails, but without checking the failure userspace application calls PROC_Detach()! Cheers, Ameya. -- 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: Ubuntu installation on omap
still i am getting my kernel booting i am using bootcmd=mmcinit;fatload mmc 0:1 0x8000 uImage;bootm 0x8000. But i am creating uImage using mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d ./vmlinuz-* ./uImage is this ok?i think the problem might be here. Please help me On Wed, Feb 10, 2010 at 6:08 PM, Niamathullah sharief omap...@gmail.com wrote: sorry i followed this link to create uImage http://elinux.org/BeagleBoardUbuntu#Create_uImage_for_U-Boot; now whether my bootm env is correct? On Wed, Feb 10, 2010 at 6:05 PM, Niamathullah sharief omap...@gmail.com wrote: Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 6:04 PM, Niamathullah sharief omap...@gmail.com wrote: Now i have the new problem. My env has changed and my uImage is not booting. see reading uImage 3610172 bytes read ## Booting kernel from Legacy Image at 8000 ... Image Name: 2.6.32.7-x7.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3610108 Bytes = 3.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... After this it is not going. I followed the link http://elinux.org/BeagleBoardUbuntu#Create_U-Boot_boot_image to create the uImage. whether my env setting are correct? i mean ## Booting kernel from Legacy Image at 8000 ... is correct when i followed the above link to create uImage? On Wed, Feb 10, 2010 at 11:20 AM, Menon, Nishanth n...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niamathullah sharief Sent: Wednesday, February 10, 2010 7:30 AM On Tue, Feb 9, 2010 at 8:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Feb 9, 2010 at 3:41 AM, Niamathullah sharief omap...@gmail.com wrote: Hi, I am trying to install ubuntu on my beagleboard. i installed successfully and it is booting fine. But after booting the graphics which i get is not good. It has some graphics problem. Ahh, what kind of graphic problems? it is like working without graphics driver Is'nt http://groups.google.com/group/beagleboard/ having more folks Who can specifically help on beagleboard? Could we take the discussion there? Regards, Nishanth Menon -- 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] OMAP UART: Add omap-serial driver support.
Tony,
+static void serial_omap_start_tx(struct uart_port *port)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+
+ if (up-use_dma !(up-port.x_char)) {
+
+ struct circ_buf *xmit = up-port.state-xmit;
+ unsigned int start = up-uart_dma.tx_buf_dma_phys +
+ (xmit-tail (UART_XMIT_SIZE - 1));
+ if (uart_circ_empty(xmit) || up-uart_dma.tx_dma_state)
+ return;
+ spin_lock((up-uart_dma.tx_lock));
+ up-uart_dma.tx_dma_state = 1;
+ spin_unlock((up-uart_dma.tx_lock));
+
+ up-uart_dma.tx_buf_size = uart_circ_chars_pending(xmit);
+ /*
+ * It is a circular buffer. See if the buffer has wounded back.
+ * If yes it will have to be transferred in two separate dma
+ * transfers
+ */
+ if (start + up-uart_dma.tx_buf_size =
+ up-uart_dma.tx_buf_dma_phys + UART_XMIT_SIZE)
+ up-uart_dma.tx_buf_size =
+ (up-uart_dma.tx_buf_dma_phys +
+ UART_XMIT_SIZE) - start;
+
+ if (up-uart_dma.tx_dma_channel == 0xFF)
+ omap_request_dma(up-uart_dma.uart_dma_tx,
+ UART Tx DMA,
+ (void *)uart_tx_dma_callback, up,
+ (up-uart_dma.tx_dma_channel));
You need to check the result from omap_request_dma. On a busy system
it's quite possible that all DMA channels are taken and you need to
dynamically fall back to PIO transfer instead.
Looks like this function is easy to fix for that. Maybe you also
need to reprogram something in the UART for switching between DMA
and PIO?
I explored the possibility of falling back to to Interrupt mode when we get an
-EBUSY signal from request dma.
It is quite complex, as we set DMA mode in FCR [Fifo control register]
and FCR can be configured only when the baud clock is not running
(DLL_REG and DLH_REG set to 0).
So we need to reconfigure complete register set since setting DLL and
DLH to zero means
we need to reconfigure for baudrate again this would affect the mcr
configuration and other
flow control configuration which is set. Thus increasing the
complexity of switching
to interrupt mode.
---
Regards,
Govindraj.R
--
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] OMAP3: Serial: Improved sleep logic
From: Tero Kristo tero.kri...@nokia.com
This patch contains following improvements:
- Only RX interrupt will now kick the sleep prevent timer
- TX fifo status is checked before disabling clocks, this will prevent
on-going transmission to be cut
- Smartidle is disabled while entering idle if we have data in the transmit
buffer because having this enabled would prevent wakeups from the TX
interrupt and this would cause pauses while sending large blocks of data
- Sleep prevent timer is changed to use ktime_get() instead of a jiffy timer
as jiffy timers are not valid within idle loop (tick scheduler is stopped)
- RX and TX fifos are cleared when clocks are enabled, this will purge the
first character from RX fifo, which is most likely garbage
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/serial.c | 70 +++---
1 files changed, 45 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 837b347..d7d96ba 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -23,12 +23,15 @@
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/delay.h
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/control.h
+#include asm/div64.h
+
#include prm.h
#include pm.h
#include prm-regbits-34xx.h
@@ -36,13 +39,13 @@
#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52
#define UART_OMAP_WER 0x17/* Wake-up enable register */
-#define DEFAULT_TIMEOUT (5 * HZ)
+#define DEFAULT_TIMEOUT (5LL * NSEC_PER_SEC)
struct omap_uart_state {
int num;
int can_sleep;
- struct timer_list timer;
- u32 timeout;
+ ktime_t expire_time;
+ u64 timeout;
void __iomem *wk_st;
void __iomem *wk_en;
@@ -231,6 +234,9 @@ static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
clk_enable(uart-fck);
uart-clocked = 1;
omap_uart_restore_context(uart);
+
+ /* Clear RX and TX fifos, as they contain garbage at this point */
+ serial_write_reg(uart-p, UART_FCR, 0xa7);
}
#ifdef CONFIG_PM
@@ -302,9 +308,7 @@ static void omap_uart_block_sleep(struct omap_uart_state
*uart)
omap_uart_smart_idle_enable(uart, 0);
uart-can_sleep = 0;
if (uart-timeout)
- mod_timer(uart-timer, jiffies + uart-timeout);
- else
- del_timer(uart-timer);
+ uart-expire_time = ktime_add_ns(ktime_get(), uart-timeout);
}
static void omap_uart_allow_sleep(struct omap_uart_state *uart)
@@ -317,25 +321,28 @@ static void omap_uart_allow_sleep(struct omap_uart_state
*uart)
if (!uart-clocked)
return;
- omap_uart_smart_idle_enable(uart, 1);
+ if (serial_read_reg(uart-p, UART_LSR) UART_LSR_TEMT)
+ omap_uart_smart_idle_enable(uart, 1);
uart-can_sleep = 1;
- del_timer(uart-timer);
-}
-
-static void omap_uart_idle_timer(unsigned long data)
-{
- struct omap_uart_state *uart = (struct omap_uart_state *)data;
-
- omap_uart_allow_sleep(uart);
}
void omap_uart_prepare_idle(int num)
{
struct omap_uart_state *uart;
+ ktime_t t;
list_for_each_entry(uart, uart_list, node) {
+ if (num == uart-num !uart-can_sleep) {
+ t = ktime_get();
+ if (t.tv64 uart-expire_time.tv64)
+ uart-can_sleep = 1;
+ }
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ if (serial_read_reg(uart-p, UART_LSR)
+ UART_LSR_TEMT)
+ omap_uart_disable_clocks(uart);
+ else
+ omap_uart_smart_idle_enable(uart, 0);
return;
}
}
@@ -360,6 +367,7 @@ void omap_uart_resume_idle(int num)
/* Check for normal UART wakeup */
if (__raw_readl(uart-wk_st) uart-wk_mask)
omap_uart_block_sleep(uart);
+
return;
}
}
@@ -407,8 +415,14 @@ int omap_uart_can_sleep(void)
static irqreturn_t omap_uart_interrupt(int irq, void *dev_id)
{
struct omap_uart_state *uart = dev_id;
+ u8 lsr;
- omap_uart_block_sleep(uart);
+ lsr = serial_read_reg(uart-p, UART_LSR);
+ /* Check for receive interrupt */
+ if (lsr UART_LSR_DR)
+ omap_uart_block_sleep(uart);
+ if (lsr UART_LSR_TEMT uart-can_sleep)
+ omap_uart_smart_idle_enable(uart, 1);
return IRQ_NONE;
}
@@ -420,9 +434,9 @@ static void omap_uart_idle_init(struct omap_uart_state
*uart)
uart-can_sleep = 0;
uart-timeout =
Re: Ubuntu installation on omap
On Wed, Feb 10, 2010 at 8:33 AM, Niamathullah sharief omap...@gmail.com wrote: still i am getting my kernel booting i am using bootcmd=mmcinit;fatload mmc 0:1 0x8000 uImage;bootm 0x8000. But i am creating uImage using mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d ./vmlinuz-* ./uImage is this ok?i think the problem might be here. Please help me this is kinda offtopic for this list, you should really use: http://groups.google.com/group/beagleboard heads up: 'mmcinit' was depreciated in later uboot's as it's now 'mmc init' For the beagle most use: 0x8030 instead of 0x8000 but it should boot.. Could you pastebin.com your complete boot log from the serial port, so we could see what's actually going wrong? Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dspbridge: Simplify Atoi() method
On 2/10/2010 1:59 AM, Andy Shevchenko wrote: On Wed, Feb 10, 2010 at 4:02 AM, Omar Ramirez Lunaomar.rami...@ti.com wrote: Try to use simple_strtol() kernel native method instead. strtol or strtoul? I don't know for sure, see below. sorry, i meant: here it says simple_strtol but the code says simple_strtoul However, there are opened questions: - why type of Atoi() is s32 if the sign is used only to detect base? This is the question about l vs ul. agree, IMO this should be ul, I haven't reviewed all the places where Atoi is used but the ones I have seen use it as ul about the sign: I haven't seen any value with '+' or '-' prefix so with this patch the decision to identify as base10 is left to simple_guess_base inside strtoul if value strings had '0x' instead of ending 'H' for hex the whole Atoi could be replaced, i guess this would also allow to use strict_strtoul and avoid a checkpatch warning :( - 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: omap3evm: Doesn't boot at 4fa42e46
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, February 09, 2010 9:34 PM To: linux-omap@vger.kernel.org Subject: RE: omap3evm: Doesn't boot at 4fa42e46 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, February 09, 2010 9:02 PM To: linux-omap@vger.kernel.org Subject: omap3evm: Doesn't boot at 4fa42e46 Hi all, Just updated my repo to the commit: commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 Merge: e599f12 c446167 Author: Tony Lindgren t...@atomide.com Date: Thu Feb 4 20:07:44 2010 -0800 The kernel builds fine; but doesn't boot on the OMAP3EVM. I have been able to trace the code until rest_init(); but will need to restart debugging. There seems to be an exception during execution. Will continue to dig further. This is just an FYI. The kernel panics during I2C init in function omap3_evm_i2c_init() during this call: omap_register_i2c_bus(2, 400, NULL, 0); I see that there isn't any difference between omap3_evm_i2c_init() and omap3430_i2c_init(). Has anyone tried the booting 3430SDP at this commit? ...just trying to understand if this is a board specific issue OR is it a generic OMAP3 issue before I try bisect. ~sanjeev uImage created with omap3_defconfig at the HEAD boots fine on the EVM. I couldn't find much differences between this defconfig and my .config - related to i2c where the failure occurs. Unfortunately bisect didn't help much :( I just know the last commit where the EVM boots fine (with defconfig). 9b17b59 : Add devkit8000_defconfig Just a snapshot of git-bisect from my command history: premi # git-bisect bad f9ffaa9 Some good revs are not ancestor of the bad rev. git bisect cannot work properly in this case. Maybe you mistake good and bad revs? premi # premi # history | grep bisect | grep good 512 git-bisect good c6348aa 518 git-bisect good a9861b5 523 git-bisect good 9b17b59 premi # premi # history | grep bisect | grep bad 507 git-bisect bad 4fa42e4 533 git-bisect bad 0b421ec 538 git-bisect bad fc76be4 543 git-bisect bad 66ddfc6 547 git-bisect bad f9ffaa9 premi # Best regards, Sanjeev Best regards, Sanjeev -- 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 -- 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: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM
* Hiremath, Vaibhav hvaib...@ti.com [100210 01:17]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 05, 2010 10:09 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM * Hiremath, Vaibhav hvaib...@ti.com [100204 21:31]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, February 05, 2010 6:35 AM To: linux-omap@vger.kernel.org Subject: [APPLIED] [PATCH 2/4-V1] AM3517: Enable TSC2004 driver support for AM3517EVM This patch has been applied to the linux-omap by youw fwiendly patch wobot. [Hiremath, Vaibhav] Tony, Please revert this single commit. Actually I had a discussion with Dmitry Torokhov and the conclusion is, as of now for TSC2004 we can reuse TSC2007, and once they start diverging we can split them. I will be submitting patches for this support shortly. So please revert hits commit. Yeah noticed that as they did not compile with omap3_defconfig. Reverted all of them except patch AM3517: Enable basic I2C Support. [Hiremath, Vaibhav] Tony, The issue was only with TSC2004 support patch, all other patches should go in, since the driver is already being supported in Linux kernel, it was just hookup part. So can you please merge all other patches expect TSC2004 support? Please repost the others, they don't apply. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE: check pointer before calling Proc_Detach
-Original Message- From: Ameya Palande [mailto:ameya.pala...@nokia.com] Sent: Wednesday, February 10, 2010 7:48 AM To: Ramirez Luna, Omar Cc: linux-omap; Doyu Hiroshi (Nokia-D/Helsinki); Contreras Felipe (Nokia- D/Helsinki); Menon, Nishanth; Ramos Falcon, Ernesto Subject: Re: [PATCH] DSPBRIDGE: check pointer before calling Proc_Detach Hi, On Thu, 2010-02-04 at 22:17 +0100, ext Omar Ramirez Luna wrote: From: Ernest Ramos Falcon erne...@ti.com This patch adds a check before calling Proc_Detach, otherwise in case a failure occurs on PROC_Attach and hProcessor is invalid when the userspace task closes its handle, unexpected behavior might be seen as this pointer is dereferenced in PROC_Detach. Signed-off-by: Ernest Ramos Falcon erne...@ti.com --- drivers/dsp/bridge/rmgr/drv_interface.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c b/drivers/dsp/bridge/rmgr/drv_interface.c index 32aff66..b0f0d93 100644 --- a/drivers/dsp/bridge/rmgr/drv_interface.c +++ b/drivers/dsp/bridge/rmgr/drv_interface.c @@ -539,7 +539,8 @@ static int bridge_release(struct inode *ip, struct file *filp) pr_ctxt = filp-private_data; flush_signals(current); DRV_RemoveAllResources(pr_ctxt); -PROC_Detach(pr_ctxt); +if (pr_ctxt-hProcessor) +PROC_Detach(pr_ctxt); MEM_Free(pr_ctxt); filp-private_data = NULL; I guess PROC_Detach already checks for a valid hProcessor handle! Why we need this check here again? Sorry, I think this applied for different version of dspbridge. Also if you go ahead with this patch, then how are you going to cover a use case where userspace application calls PROC_Attach() which fails, but without checking the failure userspace application calls PROC_Detach()! PROC_Detach can not be called directly from user space, is deprecated; the only place where this is function is called is bridge_release, so nothing would happen. Anyway, dismiss this patch. Cheers, Ameya. -- 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] OMAP: hsmmc: fix memory leak
* Artem Bityutskiy dedeki...@gmail.com [100210 05:26]: On Mon, 2010-02-08 at 14:33 +0200, Aaro Koskinen wrote: The platform data allocated with kmalloc() will become unreachable once the init is complete, so it should be freed. The problem was discovered by kmemleak. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com You forgot to add: Acked-by: Adrian Hunter adrian.hun...@nokia.com Thanks, I'll add that. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] OMAP UART: Add omap-serial driver support.
* Govindraj govindraj...@gmail.com [100210 06:36]:
Tony,
+static void serial_omap_start_tx(struct uart_port *port)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+
+ if (up-use_dma !(up-port.x_char)) {
+
+ struct circ_buf *xmit = up-port.state-xmit;
+ unsigned int start = up-uart_dma.tx_buf_dma_phys +
+ (xmit-tail (UART_XMIT_SIZE - 1));
+ if (uart_circ_empty(xmit) || up-uart_dma.tx_dma_state)
+ return;
+ spin_lock((up-uart_dma.tx_lock));
+ up-uart_dma.tx_dma_state = 1;
+ spin_unlock((up-uart_dma.tx_lock));
+
+ up-uart_dma.tx_buf_size = uart_circ_chars_pending(xmit);
+ /*
+ * It is a circular buffer. See if the buffer has wounded
back.
+ * If yes it will have to be transferred in two separate dma
+ * transfers
+ */
+ if (start + up-uart_dma.tx_buf_size =
+ up-uart_dma.tx_buf_dma_phys +
UART_XMIT_SIZE)
+ up-uart_dma.tx_buf_size =
+ (up-uart_dma.tx_buf_dma_phys +
+ UART_XMIT_SIZE) - start;
+
+ if (up-uart_dma.tx_dma_channel == 0xFF)
+ omap_request_dma(up-uart_dma.uart_dma_tx,
+ UART Tx DMA,
+ (void *)uart_tx_dma_callback, up,
+ (up-uart_dma.tx_dma_channel));
You need to check the result from omap_request_dma. On a busy system
it's quite possible that all DMA channels are taken and you need to
dynamically fall back to PIO transfer instead.
Looks like this function is easy to fix for that. Maybe you also
need to reprogram something in the UART for switching between DMA
and PIO?
I explored the possibility of falling back to to Interrupt mode when we get an
-EBUSY signal from request dma.
It is quite complex, as we set DMA mode in FCR [Fifo control register]
and FCR can be configured only when the baud clock is not running
(DLL_REG and DLH_REG set to 0).
So we need to reconfigure complete register set since setting DLL and
DLH to zero means
we need to reconfigure for baudrate again this would affect the mcr
configuration and other
flow control configuration which is set. Thus increasing the
complexity of switching
to interrupt mode.
Sure, that's what I figured too.. How about make the reconfigure function
non __init for that?
Sounds like it will also be needed if we want to power off the uart
for off-idle too.
This is quite a critical driver to get right, it's the only debug
console we have in most cases.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes
-Original Message- From: Felipe Contreras [mailto:felipe.contre...@nokia.com] Sent: Wednesday, February 10, 2010 7:08 AM To: Guzman Lugo, Fernando Cc: Ameya Palande; linux-omap; Ramirez Luna, Omar; Menon, Nishanth; Chitriki Rudramuni, Deepak; Phil Carmody Subject: Re: [PATCH] DSPBRIDGE: Prevent memory corruption in DRV_ProcFreeDMMRes On Wed, Feb 10, 2010 at 05:06:26AM +0100, ext Guzman Lugo, Fernando wrote: At this point there's an obvious question; what's the point of reserving a memory region and not mapping it? I remember the answer from Hari was: some clients prefer to reserve a big region once, and map parts of it continuously. I have my doubts that the use-case even works with the current code-base. But assuming it does work, your proposed changes would break it. Resource cleanup does not support that even without my proposed changes. Aha! I suspected it :P Resource cleanup does not support that because it tries to unreserved every chunk mapped. However it does not means the dspbridge does not support reserving a big chunk of memory and mapping small parts of that memory, but I have not tested it to confirm if it works. I just proposed a solution which fixes two issues in one patch. Moreover if this change is merged when the second issue be fixed this patch will not needed anymore, so why don't merge the patch which fixes both errors at this moment? simple patches complicated patches The patch is more simple than it looks. Personally I think your patches should be a continuation to the patches I just proposed. Yes, I think it would be better. Regards, Fernando. If nobody wants to split these patches, I'll gladly do so. + u32 dsp_res_addr = p_cur_res-ulDSPResAddr; + + status = PROC_UnMap(p_cur_res-hProcessor, +(void *)p_cur_res-ulDSPAddr, p_ctxt); It would be much easier to merge the two functions into one. Yes, I am agreed. Good. Perhaps we can start moving reserve/unreserve functionality to map/unmap, and eventually depreate the former. Cheers. -- Felipe Contreras -- 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: omap3evm: Doesn't boot at 4fa42e46
* Premi, Sanjeev pr...@ti.com [100210 09:09]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, February 09, 2010 9:34 PM To: linux-omap@vger.kernel.org Subject: RE: omap3evm: Doesn't boot at 4fa42e46 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Tuesday, February 09, 2010 9:02 PM To: linux-omap@vger.kernel.org Subject: omap3evm: Doesn't boot at 4fa42e46 Hi all, Just updated my repo to the commit: commit 4fa42e4679324b0e3c54fb509535eea3923ccb63 Merge: e599f12 c446167 Author: Tony Lindgren t...@atomide.com Date: Thu Feb 4 20:07:44 2010 -0800 The kernel builds fine; but doesn't boot on the OMAP3EVM. I have been able to trace the code until rest_init(); but will need to restart debugging. There seems to be an exception during execution. Will continue to dig further. This is just an FYI. The kernel panics during I2C init in function omap3_evm_i2c_init() during this call: omap_register_i2c_bus(2, 400, NULL, 0); I see that there isn't any difference between omap3_evm_i2c_init() and omap3430_i2c_init(). Has anyone tried the booting 3430SDP at this commit? ...just trying to understand if this is a board specific issue OR is it a generic OMAP3 issue before I try bisect. ~sanjeev uImage created with omap3_defconfig at the HEAD boots fine on the EVM. I couldn't find much differences between this defconfig and my .config - related to i2c where the failure occurs. Maybe post the diff -u of the configs? Unfortunately bisect didn't help much :( I just know the last commit where the EVM boots fine (with defconfig). 9b17b59 : Add devkit8000_defconfig Just a snapshot of git-bisect from my command history: premi # git-bisect bad f9ffaa9 Some good revs are not ancestor of the bad rev. git bisect cannot work properly in this case. Maybe you mistake good and bad revs? premi # premi # history | grep bisect | grep good 512 git-bisect good c6348aa 518 git-bisect good a9861b5 523 git-bisect good 9b17b59 premi # premi # history | grep bisect | grep bad 507 git-bisect bad 4fa42e4 533 git-bisect bad 0b421ec 538 git-bisect bad fc76be4 543 git-bisect bad 66ddfc6 547 git-bisect bad f9ffaa9 premi # Can you try bisecting the omap for-next branch starting at 9ba874506b7b3883d78b8cad61eba39c4bb09885? If 9ba874506b7b3883d78b8cad61eba39c4bb09885 does not boot, then you have to start at 4f4e65d2484811210a2826fa9d59712c7fcf1b49. Otherwise you'll end up bisecting all kinds of merges.. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Trying to understand how to use regulator supplies
I've got a OMAP3530 board with a tsc2004 touch controller that is
powered off of VAUX1(VAUX1_30 on my schematic) at 3V, and I'm trying to
understand how to code it up so that vaux1 power comes up before the i2c
code tries to probe for the touch controller.
Looking at some of the board files, I've added in:
/* VAUX1 for mainboard (touch and productID) */
static struct regulator_init_data omap3logic_vaux1 = {
.constraints = {
.min_uV = 300,
.max_uV = 300,
.name = VAUX1_30
.apply_uV = true,
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
};
as well as a corresponding:
.vaux1 = omap3logic_vaux1,
in the twl4030_platform_data structure, but the voltage doesn't come up.
How do I tell the kernel to turn on vaux1 so I can detect the tsc2004
chip?
--
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: Trying to understand how to use regulator supplies
On Wed, Feb 10, 2010 at 02:07:04PM -0500, Peter Barada wrote:
I've got a OMAP3530 board with a tsc2004 touch controller that is
powered off of VAUX1(VAUX1_30 on my schematic) at 3V, and I'm trying to
understand how to code it up so that vaux1 power comes up before the i2c
code tries to probe for the touch controller.
You really should ask this question on linux-kernel and/or CC the
regulator API maintainers - there's nothing OMAP specific here.
static struct regulator_init_data omap3logic_vaux1 = {
.constraints = {
.min_uV = 300,
.max_uV = 300,
.name = VAUX1_30
.apply_uV = true,
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
};
as well as a corresponding:
.vaux1 = omap3logic_vaux1,
in the twl4030_platform_data structure, but the voltage doesn't come up.
How do I tell the kernel to turn on vaux1 so I can detect the tsc2004
chip?
If you want to do it purely via constraints set always_on (and drop the
CHANGE_STATUS option) though ideally the driver for the chip would have
regulator support and be set as a consumer, in which case it would get()
and enable() the supplies it needs before interacting with the chip.
The constraints you have set above allow drivers to turn on the power
but will leave it in the default state unless any of them do so.
Explicit support in the driver would allow it to disable the supplies
while the touchscreen is not in use, saving some power.
--
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
[PATCHv3 3/4] Add ASoC support for DevKit8000
This patch expands the omap3beagle sound soc for the
beagle board clone Devkit8000.
Change log
V2
Expand omap3beagle sound soc for DevKit8000 support.
V3
Separate Kconfig for Devkit8000.
Signed-off-by: Thomas Weber sw...@gmx.li
---
sound/soc/omap/Kconfig |8
sound/soc/omap/Makefile |1 +
sound/soc/omap/omap3beagle.c |6 +++---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index 61952aa..8520b75 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -101,6 +101,14 @@ config SND_OMAP_SOC_OMAP3_BEAGLE
help
Say Y if you want to add support for SoC audio on the Beagleboard.
+config SND_OMAP_SOC_DEVKIT8000
+ tristate SoC Audio support for DevKit8000
+ depends on TWL4030_CORE SND_OMAP_SOC MACH_DEVKIT8000
+ select SND_OMAP_SOC_MCBSP
+ select SND_SOC_TWL4030
+ help
+ Say Y if you want to add support for SoC audio on the DevKit8000
+
config SND_OMAP_SOC_ZOOM2
tristate SoC Audio support for Zoom2
depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP_ZOOM2
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index 19283e5..c8195c9 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o
obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o
+obj-$(CONFIG_SND_OMAP_SOC_DEVKIT8000) += snd-soc-omap3beagle.o
obj-$(CONFIG_SND_OMAP_SOC_ZOOM2) += snd-soc-zoom2.o
obj-$(CONFIG_SND_OMAP_SOC_IGEP0020) += snd-soc-igep0020.o
diff --git a/sound/soc/omap/omap3beagle.c b/sound/soc/omap/omap3beagle.c
index d88ad5c..240e097 100644
--- a/sound/soc/omap/omap3beagle.c
+++ b/sound/soc/omap/omap3beagle.c
@@ -117,11 +117,11 @@ static int __init omap3beagle_soc_init(void)
{
int ret;
- if (!machine_is_omap3_beagle()) {
- pr_debug(Not OMAP3 Beagle!\n);
+ if (!(machine_is_omap3_beagle() || machine_is_devkit8000())) {
+ pr_debug(Not OMAP3 Beagle or Devkit8000!\n);
return -ENODEV;
}
- pr_info(OMAP3 Beagle SoC init\n);
+ pr_info(OMAP3 Beagle/Devkit8000 SoC init\n);
omap3beagle_snd_device = platform_device_alloc(soc-audio, -1);
if (!omap3beagle_snd_device) {
--
1.6.4.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: omap3evm: Doesn't boot at 4fa42e46
Sanjeev/Tony
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Wednesday, February 10, 2010 11:34 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: omap3evm: Doesn't boot at 4fa42e46
* Premi, Sanjeev pr...@ti.com [100210 09:09]:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
Sent: Tuesday, February 09, 2010 9:34 PM
To: linux-omap@vger.kernel.org
Subject: RE: omap3evm: Doesn't boot at 4fa42e46
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Premi, Sanjeev
Sent: Tuesday, February 09, 2010 9:02 PM
To: linux-omap@vger.kernel.org
Subject: omap3evm: Doesn't boot at 4fa42e46
Hi all,
Just updated my repo to the commit:
commit 4fa42e4679324b0e3c54fb509535eea3923ccb63
Merge: e599f12 c446167
Author: Tony Lindgren t...@atomide.com
Date: Thu Feb 4 20:07:44 2010 -0800
The kernel builds fine; but doesn't boot on the OMAP3EVM.
I have been able to trace the code until rest_init(); but
will need to restart debugging.
There seems to be an exception during execution.
Will continue to dig further. This is just an FYI.
The kernel panics during I2C init in function omap3_evm_i2c_init()
during this call:
omap_register_i2c_bus(2, 400, NULL, 0);
I see that Zoom2/3 also don't boot up and given that DEBUG_LL does not work for
these boards,
its very difficult to narrow down the problem.
After around 2 hours of narrowing down, this is what solves the issue probably:
m0_entry seems to be null, causing strcmp() to crash.
Patch: (will not apply as TABS are not there :) )
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 986077f..d5a03f8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -435,7 +435,7 @@ int __init omap_mux_init_signal(char *muxname, int val)
char *m0_entry = m-muxnames[0];
int i;
- if (m0_name strcmp(m0_name, m0_entry))
+ if (m0_name m0_entry strcmp(m0_name, m0_entry))
continue;
for (i = 0; i OMAP_MUX_NR_MODES; i++) {
--
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] DSPBRIDGE: Fix to avoid possible recursive locking
Hi Ameya,
Yes I agree with your comments.
As I understand NTFY_Notify() is called again inside WMD_MSG_Get() to make sure
that notification is done in case if message queue is not empty.Since
notification is already done once in InputMsg() while copying message to
message queue,it doesn't make sense to notify again in
WMD_MSG_Get().I guess this is not needed.I did a quick sanity testing removing
NTFY_Notify() from WMD_MSG_Get() and no issues.
I will rework the patch and update.
Thanks,
Deepak
__
From: Ameya Palande [ameya.pala...@nokia.com]
Sent: Wednesday, February 10, 2010 6:57 PM
To: Chitriki Rudramuni, Deepak
Cc: linux-omap; Ramirez Luna, Omar; Menon, Nishanth
Subject: Re: [PATCH] DSPBRIDGE: Fix to avoid possible recursive locking
Hi Deepak,
On Wed, 2010-02-10 at 02:01 +0100, ext Deepak Chitriki wrote:
This patch fixes possible recursive locking detection.The implementation
in which the spinlock is acquired and released is rectified in WMD_MSG_Get()
to avoid locking contention.
Added SYNC_EnterCS() and SYNC_LeaveCS()in WMD_MSG_Get()function.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 50201e5..8faf5ad 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -300,8 +300,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
@@ -352,8 +354,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
/* Exit critical section */
Can you explain the need of calling NTFY_Notify() in WMD_MSG_Get()?
I can see that the InputMsg calls NTFY_Notify() already!
Can we get rid of NTFY_Notify() from WMD_MSG_Get() all together?
Cheers,
Ameya.--
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: omap3evm: Doesn't boot at 4fa42e46
* Pandita, Vikram vikram.pand...@ti.com [100210 14:56]:
snip
The kernel panics during I2C init in function omap3_evm_i2c_init()
during this call:
omap_register_i2c_bus(2, 400, NULL, 0);
I see that Zoom2/3 also don't boot up and given that DEBUG_LL does not work
for these boards,
its very difficult to narrow down the problem.
After around 2 hours of narrowing down, this is what solves the issue
probably:
m0_entry seems to be null, causing strcmp() to crash.
Patch: (will not apply as TABS are not there :) )
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 986077f..d5a03f8 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -435,7 +435,7 @@ int __init omap_mux_init_signal(char *muxname, int val)
char *m0_entry = m-muxnames[0];
int i;
- if (m0_name strcmp(m0_name, m0_entry))
+ if (m0_name m0_entry strcmp(m0_name, m0_entry))
continue;
for (i = 0; i OMAP_MUX_NR_MODES; i++) {
Hmm is this only with CONFIG_OMAP_MUX and only on 3630?
In for-next we don't have yet the recent mux fix commit
9ecef433204f9b06550dd45cf84f14706f8fe4f0. Can you make sure
you have that applied and see if that solves the problem?
To me it seems that m0_entry should never be NULL after mux
init as that's the signal register name. The 3630 entries should
get populated by omap_mux_init_list.
If omap36xx_cbp_subset is missing some of the 3630 only entries
added by commit 9ecef433204f9b06550dd45cf84f14706f8fe4f0 into
omap3_muxmodes, then that would explain why m0_entry would
be NULL..
Anyways, as I don't have a 3630 here I'm just guessing. Until
you get the DEBUG_LL working on zoom3, you can just increase
the CONFIG_LOG_BUF_SHIFT to something large enough and printk
m0_name and m0_entry without doing anything with them. Then
after the boot you can take a look at dmesg and see if it
provides any clues.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Hi,
* Vimal Singh vimal.neww...@gmail.com [100208 03:43]:
From 35da04834f4b0363e90a628bdb369318d80b7a6c Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 5 Feb 2010 05:56:18 +0530
Subject: [PATCH 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
I've applied all three into omap for-next branch.
Anybody from MTD list care to ack this first patch?
Regards,
Tony
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 139
arch/arm/plat-omap/include/plat/nand.h | 10 ++-
drivers/mtd/nand/omap2.c | 35 +---
4 files changed, 155 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dba44a1..c012dd1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -135,5 +135,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y+= $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2):= gpmc-nand.o
+obj-y+= $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
obj-y+= $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..64d74f0
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,139 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_retime(void)
+{
+ struct gpmc_timings t;
+ int err;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
+ t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
+ t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
+ t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_retime() 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+
Re: [PATCH] ARM: OMAP4 clock domain: Add check for avoiding dependency related update.
Hi Abhijit,
On Wed, 10 Feb 2010, Abhijit Pagare wrote:
A check is added for avoiding the sleep/wakeup dependency updates
for OMAP4 as the structures for the dependencies are currently absent.
Signed-off-by: Abhijit Pagare abhijitpag...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Thanks, I've made the following changes to the patch to try to ensure that
this doesn't slip through the cracks, and queued it for 2.6.34. If you
have any comments on the revised patch, please let me know.
- Paul
From: Abhijit Pagare abhijitpag...@ti.com
Date: Wed, 10 Feb 2010 13:42:03 +0530
Subject: [PATCH] ARM: OMAP4 clock domain: Add check for avoiding dependency
related update.
A check is added for avoiding the sleep/wakeup dependency updates
for OMAP4 as the structures for the dependencies are currently absent.
Signed-off-by: Abhijit Pagare abhijitpag...@ti.com
[p...@pwsan.com: added warnings, explanatory comment, copyright update]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index a38a615..de4278c 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1,8 +1,8 @@
/*
* OMAP2/3/4 clockdomain framework functions
*
- * Copyright (C) 2008-2009 Texas Instruments, Inc.
- * Copyright (C) 2008-2009 Nokia Corporation
+ * Copyright (C) 2008-2010 Texas Instruments, Inc.
+ * Copyright (C) 2008-2010 Nokia Corporation
*
* Written by Paul Walmsley and Jouni Högander
* Added OMAP4 specific support by Abhijit Pagare abhijitpag...@ti.com
@@ -891,8 +891,17 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
pr_debug(clockdomain: enabling automatic idle transitions for %s\n,
clkdm-name);
- if (atomic_read(clkdm-usecount) 0)
- _clkdm_add_autodeps(clkdm);
+ /*
+* XXX This should be removed once TI adds wakeup/sleep
+* dependency code and data for OMAP4.
+*/
+ if (cpu_is_omap44xx()) {
+ WARN_ONCE(1, clockdomain: OMAP4 wakeup/sleep dependency
+ support is not yet implemented\n);
+ } else {
+ if (atomic_read(clkdm-usecount) 0)
+ _clkdm_add_autodeps(clkdm);
+ }
_omap2_clkdm_set_hwsup(clkdm, 1);
@@ -924,8 +933,17 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
_omap2_clkdm_set_hwsup(clkdm, 0);
- if (atomic_read(clkdm-usecount) 0)
- _clkdm_del_autodeps(clkdm);
+ /*
+* XXX This should be removed once TI adds wakeup/sleep
+* dependency code and data for OMAP4.
+*/
+ if (cpu_is_omap44xx()) {
+ WARN_ONCE(1, clockdomain: OMAP4 wakeup/sleep dependency
+ support is not yet implemented\n);
+ } else {
+ if (atomic_read(clkdm-usecount) 0)
+ _clkdm_del_autodeps(clkdm);
+ }
}
--
1.6.6.GIT
Re: [PATCH v3 2/2] ARM : OMAP : Remove #ifdef from board-omap3evm.c
* Greg KH g...@kroah.com [100115 12:14]: On Tue, Jan 05, 2010 at 12:56:04PM +0200, Felipe Balbi wrote: On Tue, Jan 05, 2010 at 09:49:32AM +0100, ext Maulik Mankad wrote: ARM : OMAP : Remove #ifdef from board-omap3evm.c Remove #ifdef around usb_nop_xceiv_register() from board-omap3evm.c Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Acked-by: Felipe Balbi felipe.ba...@nokia.com Tony, let's wait for Greg's Ack to the previous patch, but if everything is Fine, you can take this one on for-next. I can take it as I took the one that this depended on. Or both can go through Tony's tree, I don't care :) If so, please add: Acked-by: Greg Kroah-Hartman gre...@suse.de to the patches. Just to follow up on this, I've added both patches to omap for-next queue. Compiles fine now, will also check compile for x86. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH] DSPBRIDGE: Fix to avoid possible recursive locking
Please discard this patch.The rework patch will be available in v1.
Thanks,
Deepak
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On
Behalf Of Chitriki Rudramuni, Deepak
Sent: Thursday, February 11, 2010 4:44 AM
To: Ameya Palande
Cc: linux-omap; Ramirez Luna, Omar; Menon, Nishanth
Subject: RE: [PATCH] DSPBRIDGE: Fix to avoid possible recursive locking
Hi Ameya,
Yes I agree with your comments.
As I understand NTFY_Notify() is called again inside WMD_MSG_Get() to make sure
that notification is done in case if message queue is not empty.Since
notification is already done once in InputMsg() while copying message to
message queue,it doesn't make sense to notify again in
WMD_MSG_Get().I guess this is not needed.I did a quick sanity testing removing
NTFY_Notify() from WMD_MSG_Get() and no issues.
I will rework the patch and update.
Thanks,
Deepak
__
From: Ameya Palande [ameya.pala...@nokia.com]
Sent: Wednesday, February 10, 2010 6:57 PM
To: Chitriki Rudramuni, Deepak
Cc: linux-omap; Ramirez Luna, Omar; Menon, Nishanth
Subject: Re: [PATCH] DSPBRIDGE: Fix to avoid possible recursive locking
Hi Deepak,
On Wed, 2010-02-10 at 02:01 +0100, ext Deepak Chitriki wrote:
This patch fixes possible recursive locking detection.The implementation
in which the spinlock is acquired and released is rectified in WMD_MSG_Get()
to avoid locking contention.
Added SYNC_EnterCS() and SYNC_LeaveCS()in WMD_MSG_Get()function.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 50201e5..8faf5ad 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -300,8 +300,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
@@ -352,8 +354,10 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ (void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
NTFY_Notify(hMsgQueue-hNtfy,
DSP_NODEMESSAGEREADY);
+ (void)SYNC_EnterCS(hMsgMgr-hSyncCS);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
/* Exit critical section */
Can you explain the need of calling NTFY_Notify() in WMD_MSG_Get()?
I can see that the InputMsg calls NTFY_Notify() already!
Can we get rid of NTFY_Notify() from WMD_MSG_Get() all together?
Cheers,
Ameya.--
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
[APPLIED] [PATCH 1/3] omap3evm: Add mux settings for keypad
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 01c4b575fe539f042d063eae94265aedada5f224 PatchWorks http://patchwork.kernel.org/patch/77302/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=01c4b575fe539f042d063eae94265aedada5f224 -- 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
[APPLIED] [PATCH 2/3] omap3evm: Fixes after moving to matrix_keypad
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): e4f292d5bf004d9f519498c18d95aa15a129eef1 PatchWorks http://patchwork.kernel.org/patch/77305/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e4f292d5bf004d9f519498c18d95aa15a129eef1 -- 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
[APPLIED] [PATCH 3/3] omap3evm: Configure GPIO175 for touchscreen PEN_IRQ
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): a504fd55c8d47a57efe18df5f8d44cb8925abdda PatchWorks http://patchwork.kernel.org/patch/77307/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a504fd55c8d47a57efe18df5f8d44cb8925abdda -- 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
[PATCHv1] DSPBRIDGE: Fix to avoid possible recursive locking
Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
Ref:
v0:http://marc.info/?l=linux-omapm=126584779011493w=2
v1:Comment fixes from v0
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 3a275f1..7de3705 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -296,8 +296,6 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
- NTFY_Notify(hMsgQueue-hNtfy,
- DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
@@ -348,8 +346,6 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
- NTFY_Notify(hMsgQueue-hNtfy,
- DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
/* Exit critical section */
--
1.6.3.3
--
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
[APPLIED] [PATCH -next] omap3: pandora: update regulator setup
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 41b822083600f1e20266577730289d5cc26cb6dd PatchWorks http://patchwork.kernel.org/patch/77552/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=41b822083600f1e20266577730289d5cc26cb6dd -- 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
upcoming merge window: Board files merged, patchwork and omap inbox cleared
Hi all, I've merged all the patches I could from patchwork [1] into omap for-next branch [2]. I've also updated the master branch so it has for-next merged into it. Please make sure your patches are in and applied properly. If you don't see your patch in the for-next branch, and it does not show up in the patchwork [1] queue either, please resend the whole series. I've nuked my omap inbox, so I can't find the related patches otherwise :) If your patch is not in for-next, one or more of your patches did not apply, or had some other issues, or somehow it fell through the cracks. I have not replied to all patches that did not apply, or applied but I had to manually edit them first. Kevin and Paul maintain separate queues that have not been merged in yet, so for clock and PM patches see Paul's and Kevin's queues too. Currently there are three patches in my patchwork queue: - [v4] OMAP: sDMA driver: descriptor autoloading feature is still waiting for a device driver patch to use it - OMAP2/3: update default defconfig, towards smaller kernel is still under discussion, we'll update it as the last patch to get in all the new boards - omap3evm: Doesn't boot at 4fa42e46 we may still want to send a related patch as a fix once sorted out For the regressions, looks like MMC only works for one of the slots on n8x0, anybody got ideas why? Regards, Tony [1] http://patchwork.kernel.org/project/linux-omap/list/ [2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/for-next -- 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 00/17] omap updates for 2.6.34 merge window, part 1
Hi all, Over the next few days I'll be posting total of 66 omap patches for review. Here's part 1. Regards, Tony --- Felipe Balbi (4): omap1: mailbox: kill compile warning omap2/3/4: mailbox: kill compile warning in mailbox.c omap2/3/4: gpmc: kill compile warning omap2/3/4: gpmc: avoid section definitions on headers Hiroshi DOYU (3): omap iommu: cleanup iommu page address mask and definitions omap: iommu: fix incorrect address for supersection 1st entry omap iommu: fix incorrect address for largepage 1st entry Janusz Krzysztofik (4): omap: McBSP: Use macros for all register read/write operations omap: McBSP: Modify macros/functions API for easy cache access omap: McBSP: Introduce caching in register write operations omap: McBSP: Use cache when modifying individual register bits Ladislav Michl (2): omap: convert boards to use physmap-flash MTD: remove no longer used OMAP flash map Vimal Singh (3): omap2/3/4: Introducing 'gpmc-nand.c' for GPMC specific NAND init omap3: SDP: Introducing 'board-sdp-flash.c' for flash init omap3: Add support for flash on 3430SDP board vikram pandita (1): omap2/3/4: serial: fix coding style indentaion arch/arm/mach-omap1/Makefile |2 arch/arm/mach-omap1/board-fsample.c |9 - arch/arm/mach-omap1/board-h2.c |9 - arch/arm/mach-omap1/board-h3.c |9 - arch/arm/mach-omap1/board-innovator.c|9 - arch/arm/mach-omap1/board-osk.c |9 - arch/arm/mach-omap1/board-palmte.c |9 - arch/arm/mach-omap1/board-palmtt.c |9 - arch/arm/mach-omap1/board-palmz71.c | 10 - arch/arm/mach-omap1/board-perseus2.c |9 - arch/arm/mach-omap1/board-sx1.c | 11 - arch/arm/mach-omap1/board-voiceblue.c|9 - arch/arm/mach-omap1/devices.c|2 arch/arm/mach-omap1/flash.c | 33 ++ arch/arm/mach-omap1/mailbox.c|9 - arch/arm/mach-omap1/mcbsp.c | 16 + arch/arm/mach-omap2/Makefile |6 arch/arm/mach-omap2/board-2430sdp.c |7 arch/arm/mach-omap2/board-3430sdp.c | 111 arch/arm/mach-omap2/board-h4.c |7 arch/arm/mach-omap2/board-sdp-flash.c| 272 +++ arch/arm/mach-omap2/gpmc-nand.c | 139 ++ arch/arm/mach-omap2/gpmc.c |6 arch/arm/mach-omap2/include/mach/board-sdp.h | 21 + arch/arm/mach-omap2/mailbox.c|2 arch/arm/mach-omap2/mcbsp.c | 20 + arch/arm/mach-omap2/serial.c | 19 + arch/arm/plat-omap/include/plat/flash.h | 16 + arch/arm/plat-omap/include/plat/gpmc.h |4 arch/arm/plat-omap/include/plat/mcbsp.h |3 arch/arm/plat-omap/include/plat/nand.h | 10 + arch/arm/plat-omap/iommu.c |6 arch/arm/plat-omap/iopgtable.h | 50 +++- arch/arm/plat-omap/mcbsp.c | 366 +- drivers/mtd/maps/Kconfig |9 - drivers/mtd/maps/Makefile|1 drivers/mtd/maps/omap_nor.c | 188 - drivers/mtd/nand/omap2.c | 35 -- 38 files changed, 962 insertions(+), 500 deletions(-) create mode 100644 arch/arm/mach-omap1/flash.c create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/gpmc-nand.c create mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h create mode 100644 arch/arm/plat-omap/include/plat/flash.h -- Signature -- 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 01/17] omap: convert boards to use physmap-flash
From: Ladislav Michl la...@linux-mips.org
Convert OMAP based boards to use physmap-flash. Refreshed against today's
Linux omap kernel tree
Cc: linux-...@lists.infradead.org
Signed-off-by: Ladislav Michl la...@linux-mips.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Makefile|2 +-
arch/arm/mach-omap1/board-fsample.c |9 +---
arch/arm/mach-omap1/board-h2.c |9 +---
arch/arm/mach-omap1/board-h3.c |9 +---
arch/arm/mach-omap1/board-innovator.c |9 +---
arch/arm/mach-omap1/board-osk.c |9 +---
arch/arm/mach-omap1/board-palmte.c |9 +---
arch/arm/mach-omap1/board-palmtt.c |9 +---
arch/arm/mach-omap1/board-palmz71.c | 10 +
arch/arm/mach-omap1/board-perseus2.c|9 +---
arch/arm/mach-omap1/board-sx1.c | 11 ++
arch/arm/mach-omap1/board-voiceblue.c |9 +---
arch/arm/mach-omap1/flash.c | 33 +++
arch/arm/mach-omap2/board-2430sdp.c |7 +++
arch/arm/mach-omap2/board-h4.c |7 +++
arch/arm/plat-omap/include/plat/flash.h | 16 +++
16 files changed, 112 insertions(+), 55 deletions(-)
create mode 100644 arch/arm/mach-omap1/flash.c
create mode 100644 arch/arm/plat-omap/include/plat/flash.h
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9ce17f1..b6a537c 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 7e70c3c..096f2ed 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -18,18 +18,19 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
#include linux/input.h
#include linux/smc91x.h
#include mach/hardware.h
#include asm/mach-types.h
#include asm/mach/arch.h
-#include asm/mach/flash.h
#include asm/mach/map.h
#include plat/tc.h
#include mach/gpio.h
#include plat/mux.h
+#include plat/flash.h
#include plat/fpga.h
#include plat/keypad.h
#include plat/common.h
@@ -150,9 +151,9 @@ static struct mtd_partition nor_partitions[] = {
},
};
-static struct flash_platform_data nor_data = {
- .map_name = cfi_probe,
+static struct physmap_flash_data nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = nor_partitions,
.nr_parts = ARRAY_SIZE(nor_partitions),
};
@@ -164,7 +165,7 @@ static struct resource nor_resource = {
};
static struct platform_device nor_device = {
- .name = omapflash,
+ .name = physmap-flash,
.id = 0,
.dev= {
.platform_data = nor_data,
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index fa7cece..d1100e4 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -26,6 +26,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
#include linux/input.h
#include linux/i2c/tps65010.h
#include linux/smc91x.h
@@ -35,7 +36,6 @@
#include asm/mach-types.h
#include asm/mach/arch.h
-#include asm/mach/flash.h
#include asm/mach/map.h
#include plat/mux.h
@@ -45,6 +45,7 @@
#include plat/usb.h
#include plat/keypad.h
#include plat/common.h
+#include plat/flash.h
#include board-h2.h
@@ -121,9 +122,9 @@ static struct mtd_partition h2_nor_partitions[] = {
}
};
-static struct flash_platform_data h2_nor_data = {
- .map_name = cfi_probe,
+static struct physmap_flash_data h2_nor_data = {
.width = 2,
+ .set_vpp= omap1_set_vpp,
.parts = h2_nor_partitions,
.nr_parts = ARRAY_SIZE(h2_nor_partitions),
};
@@ -134,7 +135,7 @@ static struct resource h2_nor_resource = {
};
static struct platform_device h2_nor_device = {
- .name = omapflash,
+ .name = physmap-flash,
.id = 0,
.dev= {
.platform_data = h2_nor_data,
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 6a7f9c3..a53ab82 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -25,6 +25,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mtd/physmap.h
#include linux/input.h
#include linux/spi/spi.h
#include linux/i2c/tps65010.h
@@ -37,7 +38,6 @@
#include asm/mach-types.h
#include asm/mach/arch.h
[PATCH 02/17] MTD: remove no longer used OMAP flash map
From: Ladislav Michl la...@linux-mips.org
All OMAP boards are now using physmap-flash.
Cc: linux-...@lists.infradead.org
Signed-off-by: Ladislav Michl la...@linux-mips.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/mtd/maps/Kconfig|9 --
drivers/mtd/maps/Makefile |1
drivers/mtd/maps/omap_nor.c | 188 ---
3 files changed, 0 insertions(+), 198 deletions(-)
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 2de0cc8..9605cb8 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -428,15 +428,6 @@ config MTD_H720X
This enables access to the flash chips on the Hynix evaluation boards.
If you have such a board, say 'Y'.
-config MTD_OMAP_NOR
- tristate TI OMAP board mappings
- depends on MTD_CFI ARCH_OMAP
- help
- This enables access to the NOR flash chips on TI OMAP-based
- boards defining flash platform devices and flash platform data.
- These boards include the Innovator, H2, H3, OSK, Perseus2, and
- more. If you have such a board, say 'Y'.
-
# This needs CFI or JEDEC, depending on the cards found.
config MTD_PCI
tristate PCI MTD driver
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index ce31521..faa9fef 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260)+= wr_sbc82xx_flash.o
obj-$(CONFIG_MTD_DMV182) += dmv182.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
-obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
obj-$(CONFIG_MTD_RBTX4939) += rbtx4939-flash.o
diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c
index ead0b2f..e69de29 100644
--- a/drivers/mtd/maps/omap_nor.c
+++ b/drivers/mtd/maps/omap_nor.c
@@ -1,188 +0,0 @@
-/*
- * Flash memory support for various TI OMAP boards
- *
- * Copyright (C) 2001-2002 MontaVista Software Inc.
- * Copyright (C) 2003-2004 Texas Instruments
- * Copyright (C) 2004 Nokia Corporation
- *
- * Assembled using driver code copyright the companies above
- * and written by David Brownell, Jian Zhang jzh...@ti.com,
- * Tony Lindgren t...@atomide.com and others.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include linux/platform_device.h
-#include linux/module.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/ioport.h
-#include linux/slab.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-
-#include asm/io.h
-#include mach/hardware.h
-#include asm/mach/flash.h
-#include plat/tc.h
-
-#ifdef CONFIG_MTD_PARTITIONS
-static const char *part_probes[] = { /* RedBoot, */ cmdlinepart, NULL };
-#endif
-
-struct omapflash_info {
- struct mtd_partition*parts;
- struct mtd_info *mtd;
- struct map_info map;
-};
-
-static void omap_set_vpp(struct map_info *map, int enable)
-{
- static int count;
- u32 l;
-
- if (cpu_class_is_omap1()) {
- if (enable) {
- if (count++ == 0) {
- l = omap_readl(EMIFS_CONFIG);
- l |= OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- } else {
- if (count (--count == 0)) {
- l = omap_readl(EMIFS_CONFIG);
- l = ~OMAP_EMIFS_CONFIG_WP;
- omap_writel(l, EMIFS_CONFIG);
- }
- }
- }
-}
-
-static int __init
[PATCH 03/17] omap iommu: cleanup iommu page address mask and definitions
From: Hiroshi DOYU hiroshi.d...@nokia.com This is just a cleanup, but adds a few macros here, which can be used in the proceeding patches. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/iopgtable.h | 50 +++- 1 files changed, 39 insertions(+), 11 deletions(-) diff --git a/arch/arm/plat-omap/iopgtable.h b/arch/arm/plat-omap/iopgtable.h index 37dac43..ab23b6a 100644 --- a/arch/arm/plat-omap/iopgtable.h +++ b/arch/arm/plat-omap/iopgtable.h @@ -1,7 +1,7 @@ /* * omap iommu: pagetable definitions * - * Copyright (C) 2008-2009 Nokia Corporation + * Copyright (C) 2008-2010 Nokia Corporation * * Written by Hiroshi DOYU hiroshi.d...@nokia.com * @@ -13,26 +13,52 @@ #ifndef __PLAT_OMAP_IOMMU_H #define __PLAT_OMAP_IOMMU_H +/* + * L2 table address mask and size definitions. + */ #define IOPGD_SHIFT20 -#define IOPGD_SIZE (1 IOPGD_SHIFT) +#define IOPGD_SIZE (1UL IOPGD_SHIFT) #define IOPGD_MASK (~(IOPGD_SIZE - 1)) -#define IOSECTION_MASK IOPGD_MASK -#define PTRS_PER_IOPGD (1 (32 - IOPGD_SHIFT)) -#define IOPGD_TABLE_SIZE (PTRS_PER_IOPGD * sizeof(u32)) -#define IOSUPER_SIZE (IOPGD_SIZE 4) +/* + * section address mask and size definitions. + */ +#define IOSECTION_SHIFT20 +#define IOSECTION_SIZE (1UL IOSECTION_SHIFT) +#define IOSECTION_MASK (~(IOSECTION_SIZE - 1)) + +/* + * supersection address mask and size definitions. + */ +#define IOSUPER_SHIFT 24 +#define IOSUPER_SIZE (1UL IOSUPER_SHIFT) #define IOSUPER_MASK (~(IOSUPER_SIZE - 1)) +#define PTRS_PER_IOPGD (1UL (32 - IOPGD_SHIFT)) +#define IOPGD_TABLE_SIZE (PTRS_PER_IOPGD * sizeof(u32)) + +/* + * small page address mask and size definitions. + */ #define IOPTE_SHIFT12 -#define IOPTE_SIZE (1 IOPTE_SHIFT) +#define IOPTE_SIZE (1UL IOPTE_SHIFT) #define IOPTE_MASK (~(IOPTE_SIZE - 1)) -#define IOPAGE_MASKIOPTE_MASK -#define PTRS_PER_IOPTE (1 (IOPGD_SHIFT - IOPTE_SHIFT)) -#define IOPTE_TABLE_SIZE (PTRS_PER_IOPTE * sizeof(u32)) -#define IOLARGE_SIZE (IOPTE_SIZE 4) +/* + * large page address mask and size definitions. + */ +#define IOLARGE_SHIFT 16 +#define IOLARGE_SIZE (1UL IOLARGE_SHIFT) #define IOLARGE_MASK (~(IOLARGE_SIZE - 1)) +#define PTRS_PER_IOPTE (1UL (IOPGD_SHIFT - IOPTE_SHIFT)) +#define IOPTE_TABLE_SIZE (PTRS_PER_IOPTE * sizeof(u32)) + +#define IOPAGE_MASKIOPTE_MASK + +/* + * some descriptor attributes. + */ #define IOPGD_TABLE(1 0) #define IOPGD_SECTION (2 0) #define IOPGD_SUPER(1 18 | 2 0) @@ -40,12 +66,14 @@ #define IOPTE_SMALL(2 0) #define IOPTE_LARGE(1 0) +/* to find an entry in a page-table-directory */ #define iopgd_index(da)(((da) IOPGD_SHIFT) (PTRS_PER_IOPGD - 1)) #define iopgd_offset(obj, da) ((obj)-iopgd + iopgd_index(da)) #define iopte_paddr(iopgd) (*iopgd ~((1 10) - 1)) #define iopte_vaddr(iopgd) ((u32 *)phys_to_virt(iopte_paddr(iopgd))) +/* to find an entry in the second-level page table. */ #define iopte_index(da)(((da) IOPTE_SHIFT) (PTRS_PER_IOPTE - 1)) #define iopte_offset(iopgd, da)(iopte_vaddr(iopgd) + iopte_index(da)) -- 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 04/17] omap: iommu: fix incorrect address for supersection 1st entry
From: Hiroshi DOYU hiroshi.d...@nokia.com
There was a potential risk that the following memset could override
its range if a given address was not the 1st entry of a
supersection. This is not the case for iovmm.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
Signed-off-by: Hari Nagalla hnaga...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/iommu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 463d638..e748119 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -667,7 +667,7 @@ static size_t iopgtable_clear_entry_core(struct iommu *obj,
u32 da)
if ((*iopgd IOPGD_SUPER) == IOPGD_SUPER) {
nent *= 16;
/* rewind to the 1st entry */
- iopgd = (u32 *)((u32)iopgd IOSUPER_MASK);
+ iopgd = iopgd_offset(obj, (da IOSUPER_MASK));
}
bytes *= nent;
}
--
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 06/17] omap: McBSP: Use macros for all register read/write operations
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
There are several places where readw()/writew() functions are used instead of
OMAP_MCBSP_READ()/WRITE() macros for manipulating McBSP registers. Replace
them with macros to ensure consistent behaviour after caching is introduced.
Tested on OMAP1510 based Amstrad Delta.
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/mcbsp.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index c1eb615..eaaf53b 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -636,26 +636,26 @@ int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
mcbsp = id_to_mcbsp_ptr(id);
base = mcbsp-io_base;
- writew(buf, base + OMAP_MCBSP_REG_DXR1);
+ OMAP_MCBSP_WRITE(base, DXR1, buf);
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR2) XSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR2) XSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) (~XSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) (~XSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for transmit confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR2) XRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR2) XRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR2)
- (~XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2)
+ (~XRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR2) |
- (XRST),
- base + OMAP_MCBSP_REG_SPCR2);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) |
+ (XRST));
udelay(10);
dev_err(mcbsp-dev, Could not write to
McBSP%d Register\n, mcbsp-id);
@@ -681,24 +681,24 @@ int omap_mcbsp_pollread(unsigned int id, u16 *buf)
base = mcbsp-io_base;
/* if frame sync error - clear the error */
- if (readw(base + OMAP_MCBSP_REG_SPCR1) RSYNC_ERR) {
+ if (OMAP_MCBSP_READ(base, SPCR1) RSYNC_ERR) {
/* clear error */
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) (~RSYNC_ERR),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) (~RSYNC_ERR));
/* resend */
return -1;
} else {
/* wait for recieve confirmation */
int attemps = 0;
- while (!(readw(base + OMAP_MCBSP_REG_SPCR1) RRDY)) {
+ while (!(OMAP_MCBSP_READ(base, SPCR1) RRDY)) {
if (attemps++ 1000) {
- writew(readw(base + OMAP_MCBSP_REG_SPCR1)
- (~RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1)
+ (~RRST));
udelay(10);
- writew(readw(base + OMAP_MCBSP_REG_SPCR1) |
- (RRST),
- base + OMAP_MCBSP_REG_SPCR1);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) |
+ (RRST));
udelay(10);
dev_err(mcbsp-dev, Could not read from
McBSP%d Register\n, mcbsp-id);
@@ -706,7 +706,7 @@ int omap_mcbsp_pollread(unsigned int id, u16 *buf)
}
}
}
- *buf = readw(base + OMAP_MCBSP_REG_DRR1);
+ *buf =
[PATCH 07/17] omap: McBSP: Modify macros/functions API for easy cache access
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
OMAP_MCBSP_READ()/_WRITE() macros and omap_mcbsp_read()/_write() functions
accept McBSP register base address as an argument. In order to support
caching, that must be replaced with an address of the omap_mcbsp structure
that would provide addresses for both register AND cache access.
Since OMAP_ prefix seems obvious in macro names, drop it off in order to
minimize line wrapping throughout the file.
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/mcbsp.c | 281
1 files changed, 125 insertions(+), 156 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index eaaf53b..f8245f2 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -30,26 +30,26 @@
struct omap_mcbsp **mcbsp_ptr;
int omap_mcbsp_count;
-void omap_mcbsp_write(void __iomem *io_base, u16 reg, u32 val)
+void omap_mcbsp_write(struct omap_mcbsp *mcbsp, u16 reg, u32 val)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- __raw_writew((u16)val, io_base + reg);
+ __raw_writew((u16)val, mcbsp-io_base + reg);
else
- __raw_writel(val, io_base + reg);
+ __raw_writel(val, mcbsp-io_base + reg);
}
-int omap_mcbsp_read(void __iomem *io_base, u16 reg)
+int omap_mcbsp_read(struct omap_mcbsp *mcbsp, u16 reg)
{
if (cpu_class_is_omap1() || cpu_is_omap2420())
- return __raw_readw(io_base + reg);
+ return __raw_readw(mcbsp-io_base + reg);
else
- return __raw_readl(io_base + reg);
+ return __raw_readl(mcbsp-io_base + reg);
}
-#define OMAP_MCBSP_READ(base, reg) \
- omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) \
- omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
+#define MCBSP_READ(mcbsp, reg) \
+ omap_mcbsp_read(mcbsp, OMAP_MCBSP_REG_##reg)
+#define MCBSP_WRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp, OMAP_MCBSP_REG_##reg, val)
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
@@ -60,31 +60,31 @@ static void omap_mcbsp_dump_reg(u8 id)
dev_dbg(mcbsp-dev, McBSP%d regs \n, mcbsp-id);
dev_dbg(mcbsp-dev, DRR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
+ MCBSP_READ(mcbsp, DRR2));
dev_dbg(mcbsp-dev, DRR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR1));
+ MCBSP_READ(mcbsp, DRR1));
dev_dbg(mcbsp-dev, DXR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR2));
+ MCBSP_READ(mcbsp, DXR2));
dev_dbg(mcbsp-dev, DXR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR1));
+ MCBSP_READ(mcbsp, DXR1));
dev_dbg(mcbsp-dev, SPCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR2));
+ MCBSP_READ(mcbsp, SPCR2));
dev_dbg(mcbsp-dev, SPCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SPCR1));
+ MCBSP_READ(mcbsp, SPCR1));
dev_dbg(mcbsp-dev, RCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR2));
+ MCBSP_READ(mcbsp, RCR2));
dev_dbg(mcbsp-dev, RCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, RCR1));
+ MCBSP_READ(mcbsp, RCR1));
dev_dbg(mcbsp-dev, XCR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR2));
+ MCBSP_READ(mcbsp, XCR2));
dev_dbg(mcbsp-dev, XCR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, XCR1));
+ MCBSP_READ(mcbsp, XCR1));
dev_dbg(mcbsp-dev, SRGR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR2));
+ MCBSP_READ(mcbsp, SRGR2));
dev_dbg(mcbsp-dev, SRGR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, SRGR1));
+ MCBSP_READ(mcbsp, SRGR1));
dev_dbg(mcbsp-dev, PCR0: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, PCR0));
+ MCBSP_READ(mcbsp, PCR0));
dev_dbg(mcbsp-dev, ***\n);
}
@@ -93,15 +93,14 @@ static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void
*dev_id)
struct omap_mcbsp *mcbsp_tx = dev_id;
u16 irqst_spcr2;
-
[PATCH 08/17] omap: McBSP: Introduce caching in register write operations
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Determine cache size required per McBSP port at init time, based on
processor type running on.
Allocate space for storing cached copies of McBSP register values at
port request.
Modify omap_msbcp_write() function to update the cache with every
register write operation.
Modify omap_mcbsp_read() to support reading from cache or hardware.
Update MCBSP_READ() macro for modified omap_mcbsp_read() function API.
Introduce a new macro that reads from the cache.
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with: omap_perseus2_730_defconfig, omap_generic_1610_defconfig,
omap_generic_2420_defconfig, omap_2430sdp_defconfig, omap_3430sdp_defconfig,
omap_4430sdp_defconfig with CONFIG_OMAP_MCBSP=y selected.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/mcbsp.c | 16 +-
arch/arm/mach-omap2/mcbsp.c | 20 ++--
arch/arm/plat-omap/include/plat/mcbsp.h |3 +
arch/arm/plat-omap/mcbsp.c | 77 +--
4 files changed, 84 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 6bddce1..f9a5cf7 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -99,9 +99,11 @@ static struct omap_mcbsp_platform_data omap7xx_mcbsp_pdata[]
= {
},
};
#define OMAP7XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap7xx_mcbsp_pdata)
+#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap7xx_mcbsp_pdataNULL
#define OMAP7XX_MCBSP_PDATA_SZ 0
+#define OMAP7XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP15XX
@@ -132,9 +134,11 @@ static struct omap_mcbsp_platform_data
omap15xx_mcbsp_pdata[] = {
},
};
#define OMAP15XX_MCBSP_PDATA_SZARRAY_SIZE(omap15xx_mcbsp_pdata)
+#define OMAP15XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap15xx_mcbsp_pdata NULL
#define OMAP15XX_MCBSP_PDATA_SZ0
+#define OMAP15XX_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP16XX
@@ -165,19 +169,25 @@ static struct omap_mcbsp_platform_data
omap16xx_mcbsp_pdata[] = {
},
};
#define OMAP16XX_MCBSP_PDATA_SZARRAY_SIZE(omap16xx_mcbsp_pdata)
+#define OMAP16XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
#else
#define omap16xx_mcbsp_pdata NULL
#define OMAP16XX_MCBSP_PDATA_SZ0
+#define OMAP16XX_MCBSP_REG_NUM 0
#endif
int __init omap1_mcbsp_init(void)
{
- if (cpu_is_omap7xx())
+ if (cpu_is_omap7xx()) {
omap_mcbsp_count = OMAP7XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap15xx())
+ omap_mcbsp_cache_size = OMAP7XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap15xx()) {
omap_mcbsp_count = OMAP15XX_MCBSP_PDATA_SZ;
- if (cpu_is_omap16xx())
+ omap_mcbsp_cache_size = OMAP15XX_MCBSP_REG_NUM * sizeof(u16);
+ } else if (cpu_is_omap16xx()) {
omap_mcbsp_count = OMAP16XX_MCBSP_PDATA_SZ;
+ omap_mcbsp_cache_size = OMAP16XX_MCBSP_REG_NUM * sizeof(u16);
+ }
mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
GFP_KERNEL);
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 4b6e515..d601f94 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -65,9 +65,11 @@ static struct omap_mcbsp_platform_data
omap2420_mcbsp_pdata[] = {
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
+#define OMAP2420_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define omap2420_mcbsp_pdata NULL
#define OMAP2420_MCBSP_PDATA_SZ0
+#define OMAP2420_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP2430
@@ -114,9 +116,11 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
+#define OMAP2430_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define omap2430_mcbsp_pdata NULL
#define OMAP2430_MCBSP_PDATA_SZ0
+#define OMAP2430_MCBSP_REG_NUM 0
#endif
#ifdef CONFIG_ARCH_OMAP3
@@ -168,9 +172,11 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
+#define OMAP34XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
#else
#define
[PATCH 09/17] omap: McBSP: Use cache when modifying individual register bits
From: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP registers to be used for updating them
happened to be errornous.
From the hardware side, the issue appeared to be caused by a relatively high
power requirements of an external USB adapter connected to the board's printer
dedicated USB port.
I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.
Applies on top of patch 3 from this series:
[PATCH v9 3/4] OMAP: McBSP: Introduce caching in register write operations
Tested on OMAP1510 based Amstrad Delta using linux-omap for-next, commit
fb7380d70e041e4b3892f6b19dff7efb609d15a4 (2.6.33-rc3+ dated 2010-01-11).
Compile-tested with omap_3430sdp_defconfig.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com
Acked-by: Jarkko Nikula jhnik...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/mcbsp.c | 78 +++-
1 files changed, 47 insertions(+), 31 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 61e440a..473be3d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -114,7 +114,8 @@ static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void
*dev_id)
dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_tx, SPCR2, irqst_spcr2 ~(XSYNC_ERR));
+ MCBSP_WRITE(mcbsp_tx, SPCR2,
+ MCBSP_READ_CACHE(mcbsp_tx, SPCR2) ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -134,7 +135,8 @@ static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void
*dev_id)
dev_err(mcbsp_rx-dev, RX Frame Sync Error! : 0x%x\n,
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
- MCBSP_WRITE(mcbsp_rx, SPCR1, irqst_spcr1 ~(RSYNC_ERR));
+ MCBSP_WRITE(mcbsp_rx, SPCR1,
+ MCBSP_READ_CACHE(mcbsp_rx, SPCR1) ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -544,24 +546,25 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
}
mcbsp = id_to_mcbsp_ptr(id);
- mcbsp-rx_word_length = (MCBSP_READ(mcbsp, RCR1) 5) 0x7;
- mcbsp-tx_word_length = (MCBSP_READ(mcbsp, XCR1) 5) 0x7;
+ mcbsp-rx_word_length = (MCBSP_READ_CACHE(mcbsp, RCR1) 5) 0x7;
+ mcbsp-tx_word_length = (MCBSP_READ_CACHE(mcbsp, XCR1) 5) 0x7;
- idle = !((MCBSP_READ(mcbsp, SPCR2) | MCBSP_READ(mcbsp, SPCR1)) 1);
+ idle = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
+ MCBSP_READ_CACHE(mcbsp, SPCR1)) 1);
if (idle) {
/* Start the sample generator */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 6));
}
/* Enable transmitter and receiver */
tx = 1;
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | tx);
rx = 1;
- w = MCBSP_READ(mcbsp, SPCR1);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR1);
MCBSP_WRITE(mcbsp, SPCR1, w | rx);
/*
@@ -574,16 +577,16 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
if (idle) {
/* Start frame sync */
- w = MCBSP_READ(mcbsp, SPCR2);
+ w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 7));
}
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
/* Release the transmitter and receiver */
- w = MCBSP_READ(mcbsp, XCCR);
+ w = MCBSP_READ_CACHE(mcbsp, XCCR);
w = ~(tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
- w = MCBSP_READ(mcbsp, RCCR);
+ w = MCBSP_READ_CACHE(mcbsp, RCCR);
w = ~(rx ? RDISABLE : 0);
MCBSP_WRITE(mcbsp, RCCR, w);
}
@@ -609,28 +612,29 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset transmitter */
tx = 1;
if (cpu_is_omap2430() ||
[PATCH 11/17] omap2/3/4: mailbox: kill compile warning in mailbox.c
From: Felipe Balbi felipe.ba...@nokia.com
Change %d to %ld to avoid the compile warning.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 281ab63..2c9fd1c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -93,7 +93,7 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
mbox_ick_handle = clk_get(NULL, mailboxes_ick);
if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %d\n,
+ printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
PTR_ERR(mbox_ick_handle));
return PTR_ERR(mbox_ick_handle);
}
--
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 10/17] omap1: mailbox: kill compile warning
From: Felipe Balbi felipe.ba...@nokia.com
use ioremap and remove unused variable to get rid
of compile warnings.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/mailbox.c |9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index a2d07aa..379100c 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -73,7 +73,7 @@ static inline void omap_init_rtc(void) {}
# define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
#endif
-#define OMAP1_MBOX_BASEOMAP1_IO_ADDRESS(OMAP16XX_MAILBOX_BASE)
+#define OMAP1_MBOX_BASEOMAP16XX_MAILBOX_BASE
static struct resource mbox_resources[] = {
{
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index caf889a..4f5b3da 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -146,7 +146,6 @@ EXPORT_SYMBOL(mbox_dsp_info);
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
struct resource *res;
- int ret = 0;
if (pdev-num_resources != 2) {
dev_err(pdev-dev, invalid number of resources: %d\n,
@@ -160,12 +159,18 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
dev_err(pdev-dev, invalid mem resource\n);
return -ENODEV;
}
- mbox_base = res-start;
+
+ mbox_base = ioremap(res-start, resource_size(res));
+ if (!mbox_base) {
+ dev_err(pdev-dev, ioremap failed\n);
+ return -ENODEV;
+ }
/* DSP IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(pdev-dev, invalid irq resource\n);
+ iounmap(mbox_base);
return -ENODEV;
}
mbox_dsp_info.irq = res-start;
--
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 12/17] omap2/3/4: gpmc: kill compile warning
From: Felipe Balbi felipe.ba...@nokia.com
Get rid of the following warnings:
arch/arm/mach-omap2/gpmc.c:550:30: warning: non-ANSI
function declaration of function 'omap3_gpmc_save_context'
arch/arm/mach-omap2/gpmc.c:581:33: warning: non-ANSI
function declaration of function 'omap3_gpmc_restore_context'
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 7027cdc..5bc3ca0 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -552,9 +552,10 @@ void __init gpmc_init(void)
#ifdef CONFIG_ARCH_OMAP3
static struct omap3_gpmc_regs gpmc_context;
-void omap3_gpmc_save_context()
+void omap3_gpmc_save_context(void)
{
int i;
+
gpmc_context.sysconfig = gpmc_read_reg(GPMC_SYSCONFIG);
gpmc_context.irqenable = gpmc_read_reg(GPMC_IRQENABLE);
gpmc_context.timeout_ctrl = gpmc_read_reg(GPMC_TIMEOUT_CONTROL);
@@ -583,9 +584,10 @@ void omap3_gpmc_save_context()
}
}
-void omap3_gpmc_restore_context()
+void omap3_gpmc_restore_context(void)
{
int i;
+
gpmc_write_reg(GPMC_SYSCONFIG, gpmc_context.sysconfig);
gpmc_write_reg(GPMC_IRQENABLE, gpmc_context.irqenable);
gpmc_write_reg(GPMC_TIMEOUT_CONTROL, gpmc_context.timeout_ctrl);
--
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 13/17] omap2/3/4: gpmc: avoid section definitions on headers
From: Felipe Balbi felipe.ba...@nokia.com trivial patch, no functional changes. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/gpmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h index e081338..3f3609a 100644 --- a/arch/arm/plat-omap/include/plat/gpmc.h +++ b/arch/arm/plat-omap/include/plat/gpmc.h @@ -110,6 +110,6 @@ extern void gpmc_prefetch_reset(void); extern int gpmc_prefetch_status(void); extern void omap3_gpmc_save_context(void); extern void omap3_gpmc_restore_context(void); -extern void __init gpmc_init(void); +extern void gpmc_init(void); #endif -- 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 14/17] omap2/3/4: serial: fix coding style indentaion
From 8f4ec0907030d94a66572017e86d82cd1b8cf7aa Mon Sep 17 00:00:00 2001 From: vikram pandita vikram.pand...@ti.com Date: Wed, 10 Feb 2010 18:22:54 -0800 Subject: [PATCH] omap2/3/4: serial: fix coding style indentaion No logical code change Fix coding style indentaion as per checkpatch.pl Fix multi-line comment style reported by Nishanth Menon Signed-off-by: Vikram Pandita vikram.pand...@ti.com Cc: Nishanth Menon n...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 2b78400..5f3035e 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -716,15 +716,16 @@ void __init omap_serial_init_port(int port) DEV_CREATE_FILE(dev, dev_attr_sleep_timeout); } - /* omap44xx: Never read empty UART fifo -* omap3xxx: Never read empty UART fifo on UARTs -* with IP rev =0x52 -*/ - if (cpu_is_omap44xx()) - uart-p-serial_in = serial_in_override; - else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF) - = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) - uart-p-serial_in = serial_in_override; + /* +* omap44xx: Never read empty UART fifo +* omap3xxx: Never read empty UART fifo on UARTs +* with IP rev =0x52 +*/ + if (cpu_is_omap44xx()) + uart-p-serial_in = serial_in_override; + else if ((serial_read_reg(uart-p, UART_OMAP_MVER) 0xFF) + = UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) + uart-p-serial_in = serial_in_override; } /** -- 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 15/17] omap2/3/4: Introducing 'gpmc-nand.c' for GPMC specific NAND init
From 2cf160e424cdb4efa29e1078841a649a44f50c79 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 10 Feb 2010 18:22:54 -0800
Subject: [PATCH] omap2/3/4: Introducing 'gpmc-nand.c' for GPMC specific NAND
init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 492cf16..0b17dca 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -135,5 +135,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..64d74f0
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,139 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+
+#include plat/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_retime(void)
+{
+ struct gpmc_timings t;
+ int err;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
+ t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
+ t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
+ t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_retime() 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
+ gpmc_nand_data-phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return err;
+ }
+
+ err = gpmc_nand_setup();
+ if (err 0) {
+ dev_err(dev,
[PATCH 16/17] omap3: SDP: Introducing 'board-sdp-flash.c' for flash init
From 6351a5d5dc656b348074d3ef67a63420c054041a Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 10 Feb 2010 18:22:55 -0800
Subject: [PATCH] omap3: SDP: Introducing 'board-sdp-flash.c' for flash init
This patch adds 'board-sdp-flash.c', which could be utilized
by boards similar to 3430SDP. (For ex: 2430sdp, 36030sdp).
This file does initialization for all three flash devices present
in SDP boards (NOR, NAND, OneNAND), by finding there 'cs' number
dynamically using switch setting information (S8: 1-4).
This also expects partition information from core board files (for
ex: board-3430sdp.c). Which allows to choose different default
partitions for different boards.
A new structure is created for this purpose: 'flash_partitions'
in 'mach/board-sdp.h'. This has two members:
1. struct mtd_partition *parts
2. int nr_parts
A board file is expected to fill this structure and pass it to
'sdp-flsash-init'. Partition information should be passed in
structure array of 'flash_partitions'. Partition information should
be passed in below sequence in array:
NOR
OneNAND
NAND
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-sdp-flash.c
b/arch/arm/mach-omap2/board-sdp-flash.c
new file mode 100644
index 000..b1b88de
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,272 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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.
+ */
+
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.h
+#include mach/board-sdp.h
+
+#define REG_FPGA_REV 0x10
+#define REG_FPGA_DIP_SWITCH_INPUT2 0x60
+#define MAX_SUPPORTED_GPMC_CONFIG 3
+
+#define DEBUG_BASE 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#define DBG_MPDB 4
+
+/* various memory sizes */
+#define FLASH_SIZE_SDPV1 SZ_64M /* NOR flash (64 Meg aligned) */
+#define FLASH_SIZE_SDPV2 SZ_128M /* NOR flash (256 Meg aligned) */
+
+/*
+ * SDP3430 V2 Board CS organization
+ * Different from SDP3430 V1. Now 4 switches used to specify CS
+ *
+ * See also the Switch S8 settings in the comments.
+ *
+ * REVISIT: Add support for 2430 SDP
+ */
+static const unsigned char chip_sel_sdp[][GPMC_CS_NUM] = {
+ {PDC_NOR, PDC_NAND, PDC_ONENAND, DBG_MPDB, 0, 0, 0, 0}, /* S8: */
+ {PDC_ONENAND, PDC_NAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1110 */
+ {PDC_NAND, PDC_ONENAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1101 */
+};
+
+static struct physmap_flash_data sdp_nor_data = {
+ .width = 2,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .id = 0,
+ .dev= {
+ .platform_data = sdp_nor_data,
+ },
+ .num_resources = 1,
+ .resource = sdp_nor_resource,
+};
+
+static void
+__init board_nor_init(struct flash_partitions sdp_nor_parts, u8 cs)
+{
+ int err;
+
+ sdp_nor_data.parts = sdp_nor_parts.parts;
+ sdp_nor_data.nr_parts = sdp_nor_parts.nr_parts;
+
+ /* Configure start address and size of NOR device */
+ if (omap_rev() = OMAP3430_REV_ES1_0) {
+ err = gpmc_cs_request(cs, FLASH_SIZE_SDPV2 - 1,
+ (unsigned long *)sdp_nor_resource.start);
+ sdp_nor_resource.end = sdp_nor_resource.start
+ + FLASH_SIZE_SDPV2 - 1;
+ } else {
+ err = gpmc_cs_request(cs, FLASH_SIZE_SDPV1 - 1,
+ (unsigned long *)sdp_nor_resource.start);
+ sdp_nor_resource.end = sdp_nor_resource.start
+ + FLASH_SIZE_SDPV1 - 1;
+ }
+ if (err 0) {
+ printk(KERN_ERR NOR: Can't request GPMC CS\n);
+ return;
+ }
+ if (platform_device_register(sdp_nor_device) 0)
+ printk(KERN_ERR Unable to register NOR device\n);
+}
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+static struct omap_onenand_platform_data board_onenand_data = {
+ .dma_channel= -1, /* disable DMA in OMAP OneNAND driver */
+};
+
+static void
+__init board_onenand_init(struct flash_partitions sdp_onenand_parts, u8 cs)
+{
+
[PATCH 17/17] omap3: Add support for flash on 3430SDP board
From ff8b5c4a3d1fa6bbb1dab3d7b443e611fc997a05 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 10 Feb 2010 18:22:55 -0800
Subject: [PATCH] omap3: Add support for flash on 3430SDP board
This patch adds support for flashes on 3430SDP boards. All three
NAND, NOR and OneNAND are supported. I have tested it on
3430SDP (ES2 and ES3.1).
This patch can be treated as an example to how to utilize:
'gpmc-nand.c' and 'board-sdp-flash.c'.
Similar patches can be created for 2430sdp and 3630sdp or any other
similar board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0b17dca..af5853f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -100,7 +100,8 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
- mmc-twl4030.o
+ mmc-twl4030.o \
+ board-sdp-flash.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index eda4f64..2e38e5b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,6 +41,8 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include mach/board-sdp.h
+
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
@@ -650,6 +652,114 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+
RE: [PATCHv1] DSPBRIDGE: Fix to avoid possible recursive locking
From: Chitriki Rudramuni, Deepak
Sent: Thursday, February 11, 2010 2:30 AM
Removed NTFY_Notify() in WMD_MSG_Get() to avoid locking contention
as NTFY_Notify() is already invoked in InputMsg().
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
Ref:
v0:http://marc.info/?l=linux-omapm=126584779011493w=2
v1:Comment fixes from v0
Please move the Ref into the diff stat section (below ---
In the next line).
---
drivers/dsp/bridge/wmd/msg_sm.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c
b/drivers/dsp/bridge/wmd/msg_sm.c
index 3a275f1..7de3705 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -296,8 +296,6 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
else {
- NTFY_Notify(hMsgQueue-hNtfy,
- DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
One line code does not need {} - please remove it as well.
@@ -348,8 +346,6 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
- NTFY_Notify(hMsgQueue-hNtfy,
- DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
}
One line code does not need {} - please remove it as well.
/* Exit critical section */
--
1.6.3.3
Regards,
Nishanth Menon
--
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] nand support on zoom boards
Re-posting this patch series once again after re-basing on latest LO master. - vimal On Wed, Jan 13, 2010 at 12:31 PM, Vimal Singh vimal.neww...@gmail.com wrote: From 345704a79f15b0481b14d5d504b0bcdf55f2a9a6 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 12 Jan 2010 18:12:53 +0530 Subject: [PATCH] nand support on zoom boards I have verified it on zoom2/3 support on zoom boards. I still have not tried it on LDP (zoom1) board. So, I'll post patch for same later. Vimal Singh (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' OMAP3: Add support for NAND on ZOOM2 board OMAP3: Add support for NAND on ZOOM3 board arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-zoom-flash.c | 85 + arch/arm/mach-omap2/board-zoom2.c | 49 ++ arch/arm/mach-omap2/board-zoom3.c | 49 ++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 5 files changed, 196 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
From: Vimal Singh vimalsi...@ti.com
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c| 85 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++
2 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..f2328a4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,85 @@
+/*
+ * board-zoom-flash.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Vimal Singh vimalsi...@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.
+ */
+
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+
+#include mach/board-zoom.h
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+
+/* Note that all values in this struct are in nanoseconds */
+static struct gpmc_timings nand_timings = {
+
+ .sync_clk = 0,
+
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
+
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
+
+ .we_off = 30,
+ .oe_off = 48,
+
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
+
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data zoom_nand_data = {
+ .nand_setup = NULL,
+ .gpmc_t = nand_timings,
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+};
+
+/**
+ * zoom_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts= zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ gpmc_nand_init(zoom_nand_data);
+}
+#else
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+}
+#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
+
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..f4469d3 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -1,5 +1,16 @@
/*
* Defines for zoom boards
*/
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+struct flash_partitions {
+ struct mtd_partition *parts;
+ int nr_parts;
+};
+
+#define ZOOM_NAND_CS 0
+
+extern void __init zoom_flash_init(struct flash_partitions [], int);
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] OMAP3: Add support for NAND on ZOOM2 board
From: Vimal Singh vimalsi...@ti.com
This patch adds NAND support to ZOOM2 board.
This uses 'board-zoom-flash.c' for NAND initialization.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom2.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d3e54da..bd37d6e 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
board-rx51-peripherals.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 9a26f84..1e39677 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -77,10 +77,59 @@ static struct omap_board_mux board_mux[]
#define board_mux NULL
#endif
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom2_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] OMAP3: Add support for NAND on ZOOM3 board
From: Vimal Singh vimalsi...@ti.com
This patch adds NAND support to ZOOM3 board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index bd37d6e..556e62f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2) +=
board-zoom2.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index d3e3cd5..fcd0c0d 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -34,6 +34,54 @@ static void __init omap_zoom_map_io(void)
static struct omap_board_config_kernel zoom_config[] __initdata = {
};
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
@@ -66,6 +114,7 @@ static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
--
1.6.3.3
--
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: [PATCHV6 1/3] OMAP3: introduce DPLL4 Jtype
Hi,
On Wed, 10 Feb 2010, Vishwanath BS wrote:
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block called j type dpll, requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
I made a few changes to this patch (revised version below) and ququed it
up for 2.6.34. Please let me know if you have any comments on the revised
patch.
thanks,
- Paul
From 8069cd708068fa48eaf065c576455537ca4a740d Mon Sep 17 00:00:00 2001
From: Richard Woodruff r-woodru...@ti.com
Date: Wed, 10 Feb 2010 17:24:31 -0700
Subject: [PATCH] DPLL4 for 3630 introduces a changed block called j type dpll,
requiring
special divisor bits and additional reg fields. To allow for silicons to
use this, this is introduced as a flag and is enabled for 3630 silicon.
OMAP4 also has j type dpll for usb.
Tested with 3630 ZOOM3 and OMAP3430 ZOOM2
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[p...@pwsan.com: added some comments; updated copyrights and credits; fixed
some style issues]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock.h |4 ++
arch/arm/mach-omap2/clock34xx_data.c| 32 ++-
arch/arm/mach-omap2/clock44xx_data.c|1 +
arch/arm/mach-omap2/cm-regbits-34xx.h |5 ++
arch/arm/mach-omap2/dpll3xxx.c | 67 +--
arch/arm/plat-omap/include/plat/clock.h |5 ++
6 files changed, 109 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index c500a5f..f7e7100 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,10 @@
#define DPLL_LOW_POWER_BYPASS 0x5
#define DPLL_LOCKED0x7
+/* DPLL Type and DCO Selection Flags */
+#define DPLL_J_TYPE0x1
+#define DPLL_NO_DCO_SEL0x2
+
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
long omap2_clk_round_rate(struct clk *clk, unsigned long rate);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index caa6a41..8be3eda 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -38,6 +38,7 @@
/* Maximum DPLL multiplier, divider values for OMAP3 */
#define OMAP3_MAX_DPLL_MULT2048
+#define OMAP3630_MAX_JTYPE_DPLL_MULT 4095
#define OMAP3_MAX_DPLL_DIV 128
/*
@@ -529,7 +530,8 @@ static struct clk emu_core_alwon_ck = {
/* DPLL4 */
/* Supplies 96MHz, 54Mhz TV DAC, DSS fclk, CAM sensor clock, emul trace clk */
/* Type: DPLL */
-static struct dpll_data dpll4_dd = {
+static struct dpll_data dpll4_dd;
+static struct dpll_data dpll4_dd_34xx __initdata = {
.mult_div1_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL2),
.mult_mask = OMAP3430_PERIPH_DPLL_MULT_MASK,
.div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
@@ -552,6 +554,29 @@ static struct dpll_data dpll4_dd = {
.rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE
};
+static struct dpll_data dpll4_dd_3630 __initdata = {
+ .mult_div1_reg = OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL2),
+ .mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK,
+ .div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
+ .clk_bypass = sys_ck,
+ .clk_ref= sys_ck,
+ .control_reg= OMAP_CM_REGADDR(PLL_MOD, CM_CLKEN),
+ .enable_mask= OMAP3430_EN_PERIPH_DPLL_MASK,
+ .modes = (1 DPLL_LOW_POWER_STOP) | (1 DPLL_LOCKED),
+ .auto_recal_bit = OMAP3430_EN_PERIPH_DPLL_DRIFTGUARD_SHIFT,
+ .recal_en_bit = OMAP3430_PERIPH_DPLL_RECAL_EN_SHIFT,
+ .recal_st_bit = OMAP3430_PERIPH_DPLL_ST_SHIFT,
+ .autoidle_reg = OMAP_CM_REGADDR(PLL_MOD, CM_AUTOIDLE),
+ .autoidle_mask = OMAP3430_AUTO_PERIPH_DPLL_MASK,
+ .idlest_reg = OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST),
+ .idlest_mask= OMAP3430_ST_PERIPH_CLK_MASK,
+ .max_multiplier = OMAP3630_MAX_JTYPE_DPLL_MULT,
+ .min_divider= 1,
+ .max_divider= OMAP3_MAX_DPLL_DIV,
+ .rate_tolerance = DEFAULT_DPLL_RATE_TOLERANCE,
+ .flags = DPLL_J_TYPE
+};
+
static struct clk dpll4_ck = {
.name = dpll4_ck,
.ops= clkops_noncore_dpll_ops,
@@ -3377,6 +3402,11 @@ int __init omap3xxx_clk_init(void)
clkops_omap36xx_pwrdn_with_hsdiv_wait_restore;
}
+ if (cpu_is_omap3630())
+ dpll4_dd = dpll4_dd_3630;
+ else
+ dpll4_dd =
Re: [PATCHV6 1/3] OMAP3: introduce DPLL4 Jtype
by the way, just noticed that the subject line got dropped; fixed that here. - Paul -- 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: [PATCHV6 2/3] OMAP3: Introduce 3630 DPLL4 HSDivider changes
On Wed, 10 Feb 2010, Vishwanath BS wrote:
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if cpu type is 3630.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
thanks, applied with a few minor changes for 2.6.34; revised patch
follows.
- Paul
From: Vishwanath BS vishwanath...@ti.com
Date: Wed, 10 Feb 2010 17:18:24 -0700
Subject: [PATCH] OMAP3 clock: Introduce 3630 DPLL4 HSDivider changes
Divider (M2, M3, M4, M5 and M6) field width has been increased by 1 bit
in 3630. This patch has changes to accommodate this in CM dynamically
based on chip version.
Basically new clock nodes have been added for 3630 DPLL4 M2,M3,M4,M5 and
M6 and value of these nodes are used if cpu type is 3630.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[p...@pwsan.com: updated to apply on 2.6.34 queue; comments added]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock34xx_data.c| 146 +-
arch/arm/mach-omap2/cm-regbits-34xx.h |5 +
arch/arm/plat-omap/include/plat/clock.h |5 +-
3 files changed, 149 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 8be3eda..f58c895 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -237,6 +237,42 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll4_rates_3630[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_36XX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_36XX },
+ { .div = 3, .val = 3, .flags = RATE_IN_36XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_36XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_36XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_36XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_36XX },
+ { .div = 8, .val = 8, .flags = RATE_IN_36XX },
+ { .div = 9, .val = 9, .flags = RATE_IN_36XX },
+ { .div = 10, .val = 10, .flags = RATE_IN_36XX },
+ { .div = 11, .val = 11, .flags = RATE_IN_36XX },
+ { .div = 12, .val = 12, .flags = RATE_IN_36XX },
+ { .div = 13, .val = 13, .flags = RATE_IN_36XX },
+ { .div = 14, .val = 14, .flags = RATE_IN_36XX },
+ { .div = 15, .val = 15, .flags = RATE_IN_36XX },
+ { .div = 16, .val = 16, .flags = RATE_IN_36XX },
+ { .div = 17, .val = 17, .flags = RATE_IN_36XX },
+ { .div = 18, .val = 18, .flags = RATE_IN_36XX },
+ { .div = 19, .val = 19, .flags = RATE_IN_36XX },
+ { .div = 20, .val = 20, .flags = RATE_IN_36XX },
+ { .div = 21, .val = 21, .flags = RATE_IN_36XX },
+ { .div = 22, .val = 22, .flags = RATE_IN_36XX },
+ { .div = 23, .val = 23, .flags = RATE_IN_36XX },
+ { .div = 24, .val = 24, .flags = RATE_IN_36XX },
+ { .div = 25, .val = 25, .flags = RATE_IN_36XX },
+ { .div = 26, .val = 26, .flags = RATE_IN_36XX },
+ { .div = 27, .val = 27, .flags = RATE_IN_36XX },
+ { .div = 28, .val = 28, .flags = RATE_IN_36XX },
+ { .div = 29, .val = 29, .flags = RATE_IN_36XX },
+ { .div = 30, .val = 30, .flags = RATE_IN_36XX },
+ { .div = 31, .val = 31, .flags = RATE_IN_36XX },
+ { .div = 32, .val = 32, .flags = RATE_IN_36XX },
+ { .div = 0 }
+};
+
/* DPLL1 */
/* MPU clock source */
/* Type: DPLL */
@@ -606,8 +642,15 @@ static const struct clksel div16_dpll4_clksel[] = {
{ .parent = NULL }
};
+static const struct clksel div32_dpll4_clksel[] = {
+ { .parent = dpll4_ck, .rates = div32_dpll4_rates_3630 },
+ { .parent = NULL }
+};
+
/* This virtual clock is the source for dpll4_m2x2_ck */
-static struct clk dpll4_m2_ck = {
+static struct clk dpll4_m2_ck;
+
+static struct clk dpll4_m2_ck_34xx __initdata = {
.name = dpll4_m2_ck,
.ops= clkops_null,
.parent = dpll4_ck,
@@ -619,6 +662,18 @@ static struct clk dpll4_m2_ck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll4_m2_ck_3630 __initdata = {
+ .name = dpll4_m2_ck,
+ .ops= clkops_null,
+ .parent = dpll4_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(PLL_MOD, OMAP3430_CM_CLKSEL3),
+ .clksel_mask= OMAP3630_DIV_96M_MASK,
+ .clksel = div32_dpll4_clksel,
+ .clkdm_name = dpll4_clkdm,
+ .recalc = omap2_clksel_recalc,
+};
+
/* The PWRDN bit is apparently only available on 3430ES2 and above */
static struct clk dpll4_m2x2_ck = {
.name = dpll4_m2x2_ck,
@@ -679,7 +734,9 @@ static struct clk omap_96m_fck = {
};
/* This virtual clock is the source for
Re: [PATCHV6 3/3] OMAP3: add support for 192Mhz DPLL4M2 output
Hi, On Wed, 10 Feb 2010, Vishwanath BS wrote: In 3630, DPLL4M2 o/p can be 96MH or 192MHz (for SGX to run at 192). This patch has changes to support this feature. 96MHz clock is generated by dividing 192Mhz clock by 2 using CM_CLKSEL_CORE register. SGX can select Core Clock, 192MHz clock or CM_96M_FCLK as it's functional clock. In summary changes done are 1. Added a feature called omap3_has_192mhz_clk and enabled for 3630 2. Added a new clock node called omap_192m_alwon_ck 3. Made omap_96m_alwon_fck to derive it's clock from omap_192m_alwon_ck Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Vishwanath BS vishwanath...@ti.com this patch still had a whitespace problem, but I fixed it up here and queued it for 2.6.34. - Paul -- 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/2] OMAP: omap_device: when 'called from invalid state', print state
On Tue, 26 Jan 2010, Kevin Hilman wrote: The omap_device_[enable|idle|shutdown] functions print a warning when called from an invalid state. Print the invalid state in the warning messages. This also uses __func__ to get the function name. Also, move the entire print string onto a single line to facilitate grepping or error messages. Recent discussions on LKML show strong preference for grep-able code vs. strict 80 column limit. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks, queued for 2.6.34. - Paul -- 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
