Re: [PATCH v9 4/4] OMAP: McBSP: Use cache when modifying individual register bits
Hello Janusz,
On Friday 15 January 2010 18:43:11 ext Janusz Krzysztofik wrote:
--- git/arch/arm/plat-omap/mcbsp.c.orig2010-01-14 00:36:14.0
+0100 +++ git/arch/arm/plat-omap/mcbsp.c 2010-01-14 02:05:23.0
+0100 @@ -114,7 +114,8 @@ static irqreturn_t omap_mcbsp_tx_irq_han
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));
The reg_cache will never have the XSYNC_ERR, or any other flags set,
since these flags has never written to the reg_cache.
So it is kind of not necessary to clear the flag, which is actually
always 0.
Agree.
Another thing is that as far as I understand the reason behind of this
series is that you have a problem, that you can not trust on the values
that you read from the McBSP registers, if this is true, than the problem
can occur when the above path has been taken:
...
irqst_spcr2 = MCBSP_READ(mcbsp_tx, SPCR2);
...
if (irqst_spcr2 XSYNC_ERR) {
But since you read from McBSP registers much rarely, than probably the
corruption is not that visible?
Sure no software solution can correct my hardware issue in case of
register bits manintained by the hardware itself. Well, maybe software
that limits heat dissipation by lowering overal power consumption could
do to some extent ;).
What I'm going to address here is only a case when writing back possibly
corrupted bits can be avoided if correct values are well known and
can be determined without reading them back from the register itself.
Yeah, this is also my understanding, but I just did not found the right words ;)
Anyway, clearing the status/error flags are not necessary, since the
reg_cache will never got these bits set, you could just write back the
SPCR2/SPCR1 register content from the cache as it is...
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -134,7 +135,8 @@ static irqreturn_t omap_mcbsp_rx_irq_han
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));
Same here.
...
@@ -653,7 +657,7 @@ int omap_mcbsp_pollwrite(unsigned int id
if (MCBSP_READ(mcbsp, SPCR2) XSYNC_ERR) {
/* clear error */
MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ(mcbsp, SPCR2) (~XSYNC_ERR));
+ MCBSP_READ_CACHE(mcbsp, SPCR2) (~XSYNC_ERR));
Well, I think here also, the reg_cache does not have the XSYNC_ERR set,
it is only set in the McBSP register.
/* resend */
return -1;
} else {
@@ -662,10 +666,12 @@ int omap_mcbsp_pollwrite(unsigned int id
while (!(MCBSP_READ(mcbsp, SPCR2) XRDY)) {
if (attemps++ 1000) {
MCBSP_WRITE(mcbsp, SPCR2,
- MCBSP_READ(mcbsp, SPCR2) (~XRST));
+ MCBSP_READ_CACHE(mcbsp, SPCR2)
+ (~XRST));
Also here, the XRST will surely not set in the cached SPCR2...
This applies fro all other cases regarding to status/error bits in McBSP.
OK, I can try to identify all those cases.
What about introducing this simplification in a separate followup patch,
quoting your rationale in its changelog? I can try to prepare one if you
agree.
I think it is OK to have a followup patch addressing these.
Just mention in a comment, that you are writing the cached value back to the
register, which does not have these status flags set, thus clearing the reason
in McBSP.
Jarkko: What do you think?
Otherwise, I think this set is good to go.
Thanks,
Janusz
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/4] OMAP: McBSP: Use register cache
Hello, On Thursday 14 January 2010 17:58:29 ext Janusz Krzysztofik wrote: Change the way McBSP registers are maintained: store values written to the device in a cache in order to make use of those cached values when convenient. This could help for developing the McBSP context save/restore features, as well as solve the problem of possible register corruption, experienced on OMAP1510 based Amstrad Delta board at least. Please make a followup patch for the unneeded masking of status bits as we discussed regarding to patch 4. Acked-by: Peter Ujfalusi peter.ujfal...@nokia.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
[PATCHV5 2/4] OMAP3: Remove FreqSel for 3630
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for OMAP3630. So
remove
references to that.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/dpll.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index 87a5529..f872d10 100755
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -346,8 +346,9 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
_omap3_noncore_dpll_bypass(clk);
- /* Set jitter correction */
- if (!cpu_is_omap44xx()) {
+ /* Set jitter correction. No jitter correction for OMAP4 and 3630
+since freqsel is field is no longer present */
+ if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
v = __raw_readl(dd-control_reg);
v = ~dd-freqsel_mask;
v |= freqsel __ffs(dd-freqsel_mask);
@@ -430,8 +431,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (dd-last_rounded_rate == 0)
return -EINVAL;
- /* No freqsel on OMAP4 */
- if (!cpu_is_omap44xx()) {
+ /* No freqsel on OMAP4 and OMAP3630 */
+ if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
if (!freqsel)
--
1.5.6.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
[PATCHV5 0/4] 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. Frequency Selection (FREQSEL) is no longer required for 3630 3. CLKSEL field width is increased for DPLL4 M2, M3, M4, M5 and M6 4. DPLL4 M2 o/p can be either 96MHz or 192 Mhz (to support s...@192). This patch series has dependency on Clock framework reorganization available at http://patchwork.kernel.org/patch/67343 http://patchwork.kernel.org/patch/67344 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 Vishwanath BS (4): OMAP3: introduce DPLL4 Jtype OMAP3: Remove FreqSel for 3630 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/dpll.c | 57 +++- 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, 305 insertions(+), 24 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
[PATCHV5 4/4] 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 a9ec184..1a21a91 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_192_alwon_fck = {
+ .name = omap_192_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_192_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_192_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 },
@@ -1308,12 +1339,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 },
@@ -1322,7 +1365,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_192_alwon_fck, .rates = sgx_192m_rates },
+ { .parent = corex2_fck, .rates = sgx_corex2_rates },
+ { .parent = NULL }
};
static struct clk sgx_fck = {
@@ -1336,6 +1381,8 @@ static struct clk sgx_fck = {
.clksel = sgx_clksel,
[PATCHV5 3/4] OMAP3: Introduce 3630 DPLL4 HSDivider changes
DPLL4 HS 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 |8 ++-
arch/arm/plat-omap/include/plat/clock.h |5 +-
3 files changed, 143 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 152cd3c..a9ec184 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -236,6 +236,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 =
[PATCHV5 1/4] OMAP3: introduce DPLL4 Jtype
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 |6 +++-
arch/arm/mach-omap2/dpll.c | 48 ++-
arch/arm/plat-omap/include/plat/clock.h |5 +++
6 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..3216f9c
--- 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_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index f5ef08d..152cd3c
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -529,7 +529,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 +553,30 @@ 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 = OMAP3430_PERIPH_DPLL_MULT_MASK,
+ .div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
+ .clk_bypass = sys_ck,
+ .clk_ref= sys_ck,
+ .freqsel_mask = OMAP3430_PERIPH_DPLL_FREQSEL_MASK,
+ .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 = OMAP3_MAX_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,
@@ -3246,6 +3271,11 @@ int __init omap2_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 2210e22..a95930e 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..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define
Re: [PATCH 1/3] DSPBRIDGE: Fix header locations mach to plat
On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote: Fix header locations, replaced mach to plat Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/dspbridge.c|2 +- arch/arm/plat-omap/include/dspbridge/host_os.h |2 +- drivers/dsp/bridge/wmd/tiomap3430.c|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c index ea109a3..4150896 100644 --- a/arch/arm/mach-omap2/dspbridge.c +++ b/arch/arm/mach-omap2/dspbridge.c @@ -14,7 +14,7 @@ #include linux/platform_device.h #ifdef CONFIG_BRIDGE_DVFS -#include mach/omap-pm.h +#include plat/omap-pm.h #endif #include dspbridge/host_os.h diff --git a/arch/arm/plat-omap/include/dspbridge/host_os.h b/arch/arm/plat-omap/include/dspbridge/host_os.h index 6fe1462..74cf6d4 100644 --- a/arch/arm/plat-omap/include/dspbridge/host_os.h +++ b/arch/arm/plat-omap/include/dspbridge/host_os.h @@ -54,7 +54,7 @@ #include linux/ioport.h #include linux/platform_device.h #include dspbridge/dbtype.h -#include mach/clock.h +#include plat/clock.h #include linux/clk.h #include linux/pagemap.h #include asm/cacheflush.h diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c b/drivers/dsp/bridge/wmd/tiomap3430.c index 7138396..b123707 100644 --- a/drivers/dsp/bridge/wmd/tiomap3430.c +++ b/drivers/dsp/bridge/wmd/tiomap3430.c @@ -34,7 +34,7 @@ #include mach-omap2/cm.h #include mach-omap2/prm-regbits-34xx.h #include mach-omap2/cm-regbits-34xx.h -#include mach/control.h +#include plat/control.h /* --- DSP/BIOS Bridge */ #include dspbridge/std.h Acked-by: Ameya Palande ameya.pala...@nokia.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: [PATCHV5 1/4] OMAP3: introduce DPLL4 Jtype
On Man, Jan 18, 2010 at 01:59:19 +0530, Vishwanath BS wrote: 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 [snip] +/* A new flag called flag has been added which indiciates what is the type + * of dpll (like j_type, no_dco_sel) + */ + I think this comment block violates coding style. Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] DSPBRIDGE: change to cpufreq_register_notifier for OPP changes
On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote:
From: Fernando Guzman Lugo x0095...@ti.com
This patch changes clk_notifier_unregister with
cpufreq_unregister_notifier, which is used for OPP change
notifications
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/Kconfig |2 +-
drivers/dsp/bridge/rmgr/drv_interface.c | 25 +++--
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/dsp/bridge/Kconfig b/drivers/dsp/bridge/Kconfig
index e494f02..ea639e3 100644
--- a/drivers/dsp/bridge/Kconfig
+++ b/drivers/dsp/bridge/Kconfig
@@ -13,7 +13,7 @@ menuconfig MPU_BRIDGE
config BRIDGE_DVFS
bool Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)
- depends on MPU_BRIDGE OMAP_PM_SRF
+ depends on MPU_BRIDGE OMAP_PM_SRF CPU_FREQ
default n
help
DVFS allows DSP Bridge to initiate the operating point change to
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 8fce70c..19682b5 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -236,15 +236,18 @@ u32 vdd1_dsp_freq[6][4] = {
};
#ifdef CONFIG_BRIDGE_DVFS
-static int dspbridge_post_scale(struct notifier_block *op, unsigned long
level,
- void *ptr)
+static int dspbridge_scale_notification(struct notifier_block *op,
+ unsigned long val, void *ptr)
{
- PWR_PM_PostScale(PRCM_VDD1, level);
+ struct dspbridge_platform_data *pdata =
+ omap_dspbridge_dev-dev.platform_data;
+ if (CPUFREQ_POSTCHANGE == val pdata-dsp_get_opp)
+ PWR_PM_PostScale(PRCM_VDD1, pdata-dsp_get_opp());
return 0;
}
static struct notifier_block iva_clk_notifier = {
- .notifier_call = dspbridge_post_scale,
+ .notifier_call = dspbridge_scale_notification,
NULL,
};
#endif
@@ -380,12 +383,13 @@ static int __devinit omap34xx_bridge_probe(struct
platform_device *pdev)
GT_0trace(driverTrace, GT_7CLASS,
clk_get PASS to get iva2_ck \n);
}
- if (!clk_notifier_register(clk_handle, iva_clk_notifier)) {
+ if (!cpufreq_register_notifier(iva_clk_notifier,
+ CPUFREQ_TRANSITION_NOTIFIER)) {
GT_0trace(driverTrace, GT_7CLASS,
- clk_notifier_register PASS for iva2_ck \n);
+ cpufreq_register_notifier PASS for iva2_ck\n);
} else {
GT_0trace(driverTrace, GT_7CLASS,
- clk_notifier_register FAIL for iva2_ck \n);
+ cpufreq_register_notifier FAIL for iva2_ck\n);
}
#endif
driverContext = DSP_Init(initStatus);
@@ -429,12 +433,13 @@ static int __devexit omap34xx_bridge_remove(struct
platform_device *pdev)
goto func_cont;
#ifdef CONFIG_BRIDGE_DVFS
- if (!clk_notifier_unregister(clk_handle, iva_clk_notifier)) {
+ if (!cpufreq_unregister_notifier(iva_clk_notifier,
+ CPUFREQ_TRANSITION_NOTIFIER)) {
GT_0trace(driverTrace, GT_7CLASS,
- clk_notifier_unregister PASS for iva2_ck \n);
+ cpufreq_unregister_notifier PASS for iva2_ck\n);
} else {
GT_0trace(driverTrace, GT_7CLASS,
- clk_notifier_unregister FAILED for iva2_ck \n);
+ cpufreq_unregister_notifier FAILED for iva2_ck\n);
}
#endif /* #ifdef CONFIG_BRIDGE_DVFS */
Acked-by: Ameya Palande ameya.pala...@nokia.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: [PATCHV5 4/4] OMAP3: add support for 192Mhz DPLL4M2 output
On Mon, Jan 18, 2010 at 01:59:22 +0530, 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 --- 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(-) [snip] diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 9a028bd..6718e40 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -500,6 +500,7 @@ extern u32 omap3_features; #define OMAP3_HAS_SGXBIT(2) #define OMAP3_HAS_NEON BIT(3) #define OMAP3_HAS_ISPBIT(4) +#define OMAP3_HAS_192MHZ_CLK BIT(5) Looks like it could use a couple more tabs before BIT(5). Regards, -- Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] DSPBRIDGE: Use dspbridge to initialize platform data
On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote: Include dspbridge compilation whenever bridge driver is selected to be compiled, either as a module or part of the kernel. This will initialize platform data specific PM functions. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index a37c713..1693c03 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -57,7 +57,9 @@ obj-$(CONFIG_OMAP_IOMMU)+= $(iommu-y) # Debobs obj-$(CONFIG_OMAP3_DEBOBS) += debobs.o -obj-$(CONFIG_MPU_BRIDGE) += dspbridge.o +ifneq ($(CONFIG_MPU_BRIDGE),) +obj-y+= dspbridge.o +endif # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o Acked-by: Ameya Palande ameya.pala...@nokia.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] save and restore etm state across core OFF modes
On Wed, Jan 13, 2010 at 06:58:28 -0600, Nishanth Menon wrote:
Alexander Shishkin said the following on 01/13/2010 05:36 AM:
On Tue, Jan 12, 2010 at 04:08:23 -0600, Nishanth Menon wrote:
Alexander Shishkin had written, on 01/12/2010 03:46 PM, the following:
On Tue, Jan 12, 2010 at 01:04:04 -0800, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [100112 09:31]:
Alexander Shishkin had written, on 01/12/2010 11:30 AM, the following:
On Tue, Jan 12, 2010 at 11:13:13 -0600, Nishanth Menon wrote:
Alexander Shishkin had written, on 01/12/2010 11:04 AM, the following:
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index 69521be..0a5ec86 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
[...]
/* Store current cpsr*/
mrs r2, cpsr
stmia r8!, {r2}
@@ -520,6 +616,7 @@ clean_caches:
cmp r9, #1 /* Check whether L2 inval is required or not*/
bne skip_l2_inval
clean_l2:
+#if 0
my aversion to #if 0 kicks in here :(.. do we have an alternative
like using the CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG or something
else?
Fair enough. I could replace it with #if !defined(...) as the first
thing that comes to mind. This way it will only take disabling the
config option to catch any possible regressions in between. Does this
sound reasonable?
sounds ok to me.. unless folks have ideas coz of clean_l2 label..
more comments might be useful before a rev2 of the patch..
The best solution would be to be able to toggle this via sysfs or
debugfs by swapping the sram code for idle loop when JTAG support
is needed.
Well, if you say, compile the ETM driver in, this will be needed most of
the time.
I can think of reasons for an against a sysfs entry (as part of
discussion -warning lot of self contradictions below- but I think
might save a bit of back and froth ;)):
for sysfs entry:
a) save and restore will have additional latency when you save a
chunk such as EMU domain regs - this will not be needed in
production phones, disabling it might pop up surprises
counter: having a disabled defconfig allows relevant folks to
enable on a need basis
counter to counter: what do you do when a user reports
an issue in a release and you'd want to debug it with
ETM on his platform other than doing a rebuild?
Well, my intention is to have it enabled for most of the cases only having
it disabled for testing purposes.
with a sysfs you can go either way, with proper #ifdeferry, you can
get the best of all worlds I guess.. I know in one of the products,
a similar patch was not taken in due to introduction of additional
scratchpad space and latencies - so there are folks who would like
this and those who would like to see this not present in the binary
they flash to thier device.
What would you suggest for a place in sysfs for such a file? I'm thinking
/sys/power.
Regards,
--
Alex
--
To unsubscribe from this list: send the line unsubscribe 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 v9 4/4] OMAP: McBSP: Use cache when modifying individual register bits
On Mon, 18 Jan 2010 10:05:12 +0200 Peter Ujfalusi peter.ujfal...@nokia.com wrote: What about introducing this simplification in a separate followup patch, quoting your rationale in its changelog? I can try to prepare one if you agree. I think it is OK to have a followup patch addressing these. Just mention in a comment, that you are writing the cached value back to the register, which does not have these status flags set, thus clearing the reason in McBSP. Jarkko: What do you think? I agree, follow-up patch sound cleaner and safer than modifying the patch 4. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Friday, January 15, 2010 4:00 PM
To: Y, Kishore
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support
Hi,
On Mon, 2009-12-21 at 16:06 +0100, ext Y, Kishore wrote:
From 2f873819a4b9eb0bd658db1e59408d8f0aeb14b6 Mon Sep 17 00:00:00 2001
From: Sudeep Basavaraj sudeep.basava...@ti.com
Date: Mon, 14 Dec 2009 18:54:51 +0530
Subject: [PATCH] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support
Enables dss to process color formats with pre-mulitplied alpha values.
With this we can have alpha values defined for each pixel
and hence can have different blending values for each pixel.
What does pre-multiplied alpha mean? The TRM didn't really open it up...
Don't we already have per pixel alpha when using ARGB/RGBA?
When we set pixel format to ARGB/RGBA dss alpha blender would multiply the
value present in 'A' with 'RGB'.
By setting this bit display hardware assumes that the R,G,B are already
multiplied with the alpha value and there is no need to multiply again.
Ex:-
A R G B
argb data 128 255 128 100
pre-multiplied 128 128 64 50
So this bit, when set, would not multiply the pixel with alpha value.
This patch seems to always set the bit on, never set it off. Is that the
purpose?
As per TRM, this bit is valid only for ARGB formats and experts suggested that
we can safely assume pre-multiplied data always in real world
Tomi
Signed-off-by: Sudeep Basavaraj sudeep.basava...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/dss/dispc.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index 6dabf4b..5f7819b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -913,6 +913,11 @@ static void _dispc_set_vid_color_conv(enum
omap_plane plane, bool enable)
dispc_write_reg(dispc_reg_att[plane], val);
}
+static void _dispc_set_alpha_blend_attrs(enum omap_plane plane, bool
enable)
+{
+ REG_FLD_MOD(dispc_reg_att[plane], enable ? 1 : 0, 28, 28);
+}
+
void dispc_enable_replication(enum omap_plane plane, bool enable)
{
int bit;
@@ -1689,6 +1694,9 @@ static int _dispc_setup_plane(enum omap_plane
plane,
_dispc_set_rotation_attrs(plane, rotation, mirror, color_mode);
+ if (cpu_is_omap3630() (plane != OMAP_DSS_VIDEO1))
+ _dispc_set_alpha_blend_attrs(plane, 1);
+
if (plane != OMAP_DSS_VIDEO1)
_dispc_setup_global_alpha(plane, global_alpha);
Re: [PATCH] OMAP3 PM export chip IDCODE, Production ID and Die ID
Hello Tony and Kevin, On Wed, Oct 14, 2009 at 11:44:07AM +0200, De-Schrijver Peter (Nokia-D/Helsinki) wrote: On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [091013 12:09]: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via sysfs. This can be used to track down silicon specific issues. The info is exported via sysfs because it should be possible to include this in corematic dumps. Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Please export these via debugfs. I don't think we want to export unique chip identifiers by default. Right, which is why I suggested using debugfs, which is something that probably wouldn't be enabled/exported on default production kernels. Which is why I do not want it in debugfs as we log this info in crash reports on devices which might not have debugfs enabled. As Peter said here, this patch is to identify the chip from user land. So it is not really a debug tool, but a identification tool. Any good reason why we should not have it? Another thing is, it could go into /proc/cpuinfo. Currently I don't see any OMAP related info there, only ARM. Do you guys know why we don't put anything in /proc/cpuinfo? Cheers, Peter. -- goa is a state of mind -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html BR, -- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support
On Mon, 2010-01-18 at 12:26 +0100, ext Y, Kishore wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Friday, January 15, 2010 4:00 PM To: Y, Kishore Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support Hi, On Mon, 2009-12-21 at 16:06 +0100, ext Y, Kishore wrote: From 2f873819a4b9eb0bd658db1e59408d8f0aeb14b6 Mon Sep 17 00:00:00 2001 From: Sudeep Basavaraj sudeep.basava...@ti.com Date: Mon, 14 Dec 2009 18:54:51 +0530 Subject: [PATCH] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support Enables dss to process color formats with pre-mulitplied alpha values. With this we can have alpha values defined for each pixel and hence can have different blending values for each pixel. What does pre-multiplied alpha mean? The TRM didn't really open it up... Don't we already have per pixel alpha when using ARGB/RGBA? When we set pixel format to ARGB/RGBA dss alpha blender would multiply the value present in 'A' with 'RGB'. By setting this bit display hardware assumes that the R,G,B are already multiplied with the alpha value and there is no need to multiply again. Ex:- A R G B argb data 128 255 128 100 pre-multiplied128 128 64 50 So this bit, when set, would not multiply the pixel with alpha value. Ok, after staring long enough to the TRM's alpha-picture, I got it =). But having this bit always on on 3630 would mean that the software designed for 3430 would not work properly on 3630, wouldn't it? This patch seems to always set the bit on, never set it off. Is that the purpose? As per TRM, this bit is valid only for ARGB formats and experts suggested that we can safely assume pre-multiplied data always in real world I asked a few experts here, and they weren't so sure, and neither am I. I don't see any problems making this feature configurable, but there may be problems if it's hardcoded. So, it should be configurable. I think the default should be the same as on 3430, so that they will work similarly. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB: Add empty functions in otg.h
On Fri, Jan 15, 2010 at 08:10:14PM +0100, ext Greg KH wrote: On Tue, Jan 05, 2010 at 02:16:58PM +0530, Maulik Mankad wrote: USB : Add empty functions in otg.h Add empty functions for usb_nop_xceiv_register() and usb_nop_xceiv_unregister() in otg.h so that these functions can be called even when CONFIG_NOP_USB_XCEIV is not enabled. It allows to remove ifdef's from board file. Signed-off-by: Maulik Mankad x0082...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Acked-by: Olof Johansson o...@lixom.net Cc: Sergei Shtylyov sshtyl...@ru.mvista.com Cc: Gupta, Ajay Kumar ajay.gu...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@suse.de Oops, no, I'm rejecting this, as it breaks the build: CC [M] drivers/usb/otg/nop-usb-xceiv.o drivers/usb/otg/nop-usb-xceiv.c:41: error: redefinition of ‘usb_nop_xceiv_register’ include/linux/usb/otg.h:132: error: previous definition of ‘usb_nop_xceiv_register’ was here drivers/usb/otg/nop-usb-xceiv.c:53: error: redefinition of ‘usb_nop_xceiv_unregister’ include/linux/usb/otg.h:136: error: previous definition of ‘usb_nop_xceiv_unregister’ was here make[2]: *** [drivers/usb/otg/nop-usb-xceiv.o] Error 1 make[1]: *** [drivers/usb/otg] Error 2 make[1]: *** Waiting for unfinished jobs Doesn't anyone build their patches anymore? Kids these days... Maulik, you have to handle the case where the driver is build as a dynamically linked module, so: #if defined(CONFIG_USB_NOP_XCEIV) || defined(CONFIG_USB_NOP_XCEIV_MODULE) something like that. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHV2 0/2] OMAP3630: Clock: Workaround for DPLL HS divider limitation
From e599557dc73a581001b39d595cfacdc45ec2 Mon Sep 17 00:00:00 2001 From: Vijaykumar GN vijaykumar...@ti.com Date: Tue, 12 Jan 2010 17:15:29 +0530 Subject: [PATCH 0/2] OMAP3630: Clock: Workaround for DPLL HS divider limitation This series of patch implements a workaround for the DPLL HS divider limitation in OMAP3630. Without this workaround the divider value goes to its reset state after the corresponding PWRDN bit is set from the CM_CLKEN_PLL register. The correct divider value can be restored by writing dummy value to the register than what is in there, and then re-writing the desired value. HS Dividers impacted are 1. DPLL3_M3 2. DPLL4_M2 3. DPLL4_M3 4. DPLL4_M4 5. DPLL4_M5 6. DPLL4_M6 This patch series has dependency on Clock framework reorganization available at http://patchwork.kernel.org/patch/73638/ http://patchwork.kernel.org/patch/73635/ http://patchwork.kernel.org/patch/73637/ http://patchwork.kernel.org/patch/73636/ V1: Initial Patch Series V2: Incorporated comments Mike Turquette (2): OMAP3630: Clock: add clksel_shift to struct clk OMAP3630: Clock: Fixing HSDivider Limitation arch/arm/mach-omap2/clock34xx.c | 36 ++ arch/arm/mach-omap2/clock34xx.h |1 + arch/arm/mach-omap2/clock34xx_data.c| 21 arch/arm/plat-omap/include/plat/clock.h |1 + 4 files changed, 62 insertions(+), 0 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
[PATCHV2 1/2] OMAP3630: Clock: add clksel_shift to struct clk
From f9a7f877368830fdf28f9892940d05517f07a582 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Tue, 12 Jan 2010 16:58:39 +0530
Subject: [PATCH 1/2] OMAP3630: Clock: add clksel_shift to struct clk
Introduces clksel_shift to struct clk and populates the same for
dpll4_m3_ck, dpll4_m4_ck, dpll4_m2_ck, dpll4_m6, dpll4_m5_ck and dpll3_m3.
The purpose of this change is to make it easy for a generic function to
refresh specific CM_CLKSEL registers on a per-clock basis by first
adding then subtracting the shift value from the register.This is the
recommended sequence to solve HSDivider PWRDN limitations in OMAP3630.
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx_data.c|6 ++
arch/arm/plat-omap/include/plat/clock.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 6473247..ed17501 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -537,6 +537,7 @@ static struct clk dpll3_m3_ck = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_EMU_MOD, CM_CLKSEL1),
.clksel_mask= OMAP3430_DIV_DPLL3_MASK,
+ .clksel_shift = OMAP3430_DIV_DPLL3_SHIFT,
.clksel = div16_dpll3_clksel,
.clkdm_name = dpll3_clkdm,
.recalc = omap2_clksel_recalc,
@@ -677,6 +678,7 @@ static struct clk dpll4_m2_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, OMAP3430_CM_CLKSEL3),
.clksel_mask= OMAP3630_DIV_96M_MASK,
+ .clksel_shift = OMAP3430_DIV_96M_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
@@ -792,6 +794,7 @@ static struct clk dpll4_m3_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_CLKSEL),
.clksel_mask= OMAP3630_CLKSEL_TV_MASK,
+ .clksel_shift = OMAP3430_CLKSEL_TV_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
@@ -892,6 +895,7 @@ static struct clk dpll4_m4_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_DSS_MOD, CM_CLKSEL),
.clksel_mask= OMAP3630_CLKSEL_DSS1_MASK,
+ .clksel_shift = OMAP3430_CLKSEL_DSS1_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
@@ -933,6 +937,7 @@ static struct clk dpll4_m5_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_CLKSEL),
.clksel_mask= OMAP3630_CLKSEL_CAM_MASK,
+ .clksel_shift = OMAP3430_CLKSEL_CAM_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
@@ -970,6 +975,7 @@ static struct clk dpll4_m6_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_EMU_MOD, CM_CLKSEL1),
.clksel_mask= OMAP3630_DIV_DPLL4_MASK,
+ .clksel_shift = OMAP3430_DIV_DPLL4_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 71d78f7..e841755 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -93,6 +93,7 @@ struct clk {
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
defined(CONFIG_ARCH_OMAP4)
u8 fixed_div;
+ u8 clksel_shift;
void __iomem*clksel_reg;
u32 clksel_mask;
const struct clksel *clksel;
--
1.5.6.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
[PATCHV2 2/2] OMAP3630: Clock: Fixing HSDivider Limitation
From 719417657425d4f12369b5ddad79c86baddfefa5 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Mon, 18 Jan 2010 17:38:19 +0530
Subject: [PATCH 2/2] OMAP3630: Clock: Fixing HSDivider Limitation
It implements the recommended sequence to solve HS divider PWRDN limitation in
OMAP3630 DPLL3 and DPLL4. Without this workaround the divider value goes
to its reset state after the corresponding PWRDN bit is set from the
CM_CLKEN_PLL register. The correct divider value can be restored by
writing a dummy value to the register different than what is in there, and
then re-writing the desired value.
This Work around is applicable for below HS Dividers.
1. DPLL3_M3
2. DPLL4_M2
3. DPLL4_M3
4. DPLL4_M4
5. DPLL4_M5
6. DPLL4_M6
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 36 ++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 15 ++
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 0d30e53..e5213f8 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -146,6 +146,42 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/** omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider problem.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
+ * dpll4_m6_ck dividers get lost after their respective PWRDN bits are set.
+ * Any write to the corresponding CM_CLKSEL register will refresh the
+ * dividers. Only x2 clocks are affected, so it is safe to trust the parent
+ * clock information to refresh the CM_CLKSEL registers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 v;
+ int ret;
+
+ /* enable the clock */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ v = __raw_readl(clk-parent-clksel_reg);
+ v += (1 clk-parent-clksel_shift);
+ __raw_writel(v, clk-parent-clksel_reg);
+ v -= (1 clk-parent-clksel_shift);
+ __raw_writel(v, clk-parent-clksel_reg);
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 9a2c07e..6f7d271 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -20,5 +20,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
extern const struct clkops clkops_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 955d4ef..39a1b3c 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3447,6 +3447,21 @@ int __init omap2_clk_init(void)
dpll4_m4_ck = dpll4_m4_ck_3630;
dpll4_m5_ck = dpll4_m5_ck_3630;
dpll4_m6_ck = dpll4_m6_ck_3630;
+
+ /* For 3630: override clkops_omap2_dflt_wait for the
+* clocks affected from HSDivider PWRDN reset limitation */
+ dpll3_m3x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m2x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m3x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m4x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m5x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
+ dpll4_m6x2_ck.ops =
+ clkops_omap3_pwrdn_with_hsdiv_wait_restore;
} else {
dpll4_dd = dpll4_dd_34xx;
dpll4_m2_ck = dpll4_m2_ck_34xx;
--
1.5.6.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: [PATCH 0/3] OMAP4: prcm/clock fixes
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 14, 2010 4:42 AM To: Nayak, Rajendra Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 0/3] OMAP4: prcm/clock fixes Hi Rajendra, well, right after I sent this message, I noticed that I was looking at an older copy of my lakml inbox. So, On Wed, 13 Jan 2010, Paul Walmsley wrote: Patch 1 is missing from both the linux-omap and linux-arm-kernel mailing lists. Too big, perhaps? Patches 2 and 3 only made it to linux-omap, it seems. At least, I can't find them on linux-arm-kernel. Anyway, patches 2 and 3 have been queued up for 2.6.33-rc*, but could you please resend the whole series? ... since patches 2 and 3 have made it to the lists, all you need to resend is patch 1. Ok, so I will repost it as an attachement since its too big. Hope that's fine. thanks, - 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] save and restore etm state across core OFF modes
Alexander Shishkin said the following on 01/18/2010 04:46 AM:
On Wed, Jan 13, 2010 at 06:58:28 -0600, Nishanth Menon wrote:
Alexander Shishkin said the following on 01/13/2010 05:36 AM:
On Tue, Jan 12, 2010 at 04:08:23 -0600, Nishanth Menon wrote:
Alexander Shishkin had written, on 01/12/2010 03:46 PM, the following:
On Tue, Jan 12, 2010 at 01:04:04 -0800, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [100112 09:31]:
Alexander Shishkin had written, on 01/12/2010 11:30 AM, the following:
On Tue, Jan 12, 2010 at 11:13:13 -0600, Nishanth Menon wrote:
Alexander Shishkin had written, on 01/12/2010 11:04 AM, the following:
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 69521be..0a5ec86 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
[...]
/* Store current cpsr*/
mrs r2, cpsr
stmia r8!, {r2}
@@ -520,6 +616,7 @@ clean_caches:
cmp r9, #1 /* Check whether L2 inval is required or not*/
bne skip_l2_inval
clean_l2:
+#if 0
my aversion to #if 0 kicks in here :(.. do we have an alternative
like using the CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG or something
else?
Fair enough. I could replace it with #if !defined(...) as the first
thing that comes to mind. This way it will only take disabling the
config option to catch any possible regressions in between. Does this
sound reasonable?
sounds ok to me.. unless folks have ideas coz of clean_l2 label..
more comments might be useful before a rev2 of the patch..
The best solution would be to be able to toggle this via sysfs or
debugfs by swapping the sram code for idle loop when JTAG support
is needed.
Well, if you say, compile the ETM driver in, this will be needed most of
the time.
I can think of reasons for an against a sysfs entry (as part of
discussion -warning lot of self contradictions below- but I think
might save a bit of back and froth ;)):
for sysfs entry:
a) save and restore will have additional latency when you save a
chunk such as EMU domain regs - this will not be needed in
production phones, disabling it might pop up surprises
counter: having a disabled defconfig allows relevant folks to
enable on a need basis
counter to counter: what do you do when a user reports
an issue in a release and you'd want to debug it with
ETM on his platform other than doing a rebuild?
Well, my intention is to have it enabled for most of the cases only having
it disabled for testing purposes.
with a sysfs you can go either way, with proper #ifdeferry, you can
get the best of all worlds I guess.. I know in one of the products,
a similar patch was not taken in due to introduction of additional
scratchpad space and latencies - so there are folks who would like
this and those who would like to see this not present in the binary
they flash to thier device.
What would you suggest for a place in sysfs for such a file? I'm thinking
/sys/power.
I would have imagined this is a perfect candidate for debugfs?
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] OMAP3 PM export chip IDCODE, Production ID and Die ID
Eduardo Valentin eduardo.valen...@nokia.com writes: Hello Tony and Kevin, On Wed, Oct 14, 2009 at 11:44:07AM +0200, De-Schrijver Peter (Nokia-D/Helsinki) wrote: On Tue, Oct 13, 2009 at 09:51:30PM +0200, ext Kevin Hilman wrote: On Tue, Oct 13, 2009 at 12:48 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@deeprootsystems.com [091013 12:09]: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: From: De-Schrijver Peter (Nokia-D/Helsinki) peter.de-schrij...@nokia.com This patch exports the OMAP3 IDCODE, Production ID and Die ID to userspace via sysfs. This can be used to track down silicon specific issues. The info is exported via sysfs because it should be possible to include this in corematic dumps. Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Please export these via debugfs. I don't think we want to export unique chip identifiers by default. Right, which is why I suggested using debugfs, which is something that probably wouldn't be enabled/exported on default production kernels. Which is why I do not want it in debugfs as we log this info in crash reports on devices which might not have debugfs enabled. As Peter said here, this patch is to identify the chip from user land. So it is not really a debug tool, but a identification tool. Any good reason why we should not have it? Another thing is, it could go into /proc/cpuinfo. Currently I don't see any OMAP related info there, only ARM. Do you guys know why we don't put anything in /proc/cpuinfo? I don't know any reason not to. This sounds like a good candiate for OMAP specific details in /proc/cpuinfo. Kevin -- To unsubscribe from this list: send the line unsubscribe 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] OMAP4: prcm/clock fixes
Hi Rajendra, On Mon, 18 Jan 2010, Nayak, Rajendra wrote: Ok, so I will repost it as an attachement since its too big. Hope that's fine. How about either posting it on a website somewhere and sending a link? Or send it to me and I will post it on the website here. thanks - 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: [PATCHV2 1/2] OMAP3630: Clock: add clksel_shift to struct clk
Mike, Vijayakumar,
On Mon, 18 Jan 2010, G.N, Vijayakumar wrote:
From f9a7f877368830fdf28f9892940d05517f07a582 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Tue, 12 Jan 2010 16:58:39 +0530
Subject: [PATCH 1/2] OMAP3630: Clock: add clksel_shift to struct clk
Please don't post all this junk at the top of a patch, otherwise one of us
has to edit the patch description by hand. The From: line should be all
that's necessary.
Introduces clksel_shift to struct clk and populates the same for
dpll4_m3_ck, dpll4_m4_ck, dpll4_m2_ck, dpll4_m6, dpll4_m5_ck and dpll3_m3.
The purpose of this change is to make it easy for a generic function to
refresh specific CM_CLKSEL registers on a per-clock basis by first
adding then subtracting the shift value from the register.This is the
recommended sequence to solve HSDivider PWRDN limitations in OMAP3630.
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx_data.c|6 ++
arch/arm/plat-omap/include/plat/clock.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 6473247..ed17501 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -537,6 +537,7 @@ static struct clk dpll3_m3_ck = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_EMU_MOD, CM_CLKSEL1),
.clksel_mask= OMAP3430_DIV_DPLL3_MASK,
+ .clksel_shift = OMAP3430_DIV_DPLL3_SHIFT,
Any reason why this is needed if the code can just do __ffs(clksel_mask)
to get the shift offset? This will chew up another (4 bytes * number of
struct clks) and it doesn't seem necessary.
- 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: [PATCHV2 1/2] OMAP3630: Clock: add clksel_shift to struct clk
Another comment.
On Mon, 18 Jan 2010, G.N, Vijayakumar wrote:
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 6473247..ed17501 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -537,6 +537,7 @@ static struct clk dpll3_m3_ck = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(OMAP3430_EMU_MOD, CM_CLKSEL1),
.clksel_mask= OMAP3430_DIV_DPLL3_MASK,
+ .clksel_shift = OMAP3430_DIV_DPLL3_SHIFT,
.clksel = div16_dpll3_clksel,
.clkdm_name = dpll3_clkdm,
.recalc = omap2_clksel_recalc,
@@ -677,6 +678,7 @@ static struct clk dpll4_m2_ck_3630 __initdata = {
.init = omap2_init_clksel_parent,
.clksel_reg = OMAP_CM_REGADDR(PLL_MOD, OMAP3430_CM_CLKSEL3),
.clksel_mask= OMAP3630_DIV_96M_MASK,
+ .clksel_shift = OMAP3430_DIV_96M_SHIFT,
.clksel = div32_dpll4_clksel,
.clkdm_name = dpll4_clkdm,
.recalc = omap2_clksel_recalc,
What commit is this patch supposed to apply on? If it's not mainline then
you need to state what commit or branch it's intended to apply on top of.
- 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: [PATCHV2 2/2] OMAP3630: Clock: Fixing HSDivider Limitation
Vijayakumar, Mike,
some threshold comments,
On Mon, 18 Jan 2010, G.N, Vijayakumar wrote:
From 719417657425d4f12369b5ddad79c86baddfefa5 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@ti.com
Date: Mon, 18 Jan 2010 17:38:19 +0530
Subject: [PATCH 2/2] OMAP3630: Clock: Fixing HSDivider Limitation
Again please make sure the patch comment area is clean.
It implements the recommended sequence to solve HS divider PWRDN limitation in
OMAP3630 DPLL3 and DPLL4.
If there is a Limitation reference number or Errata reference number with
this issue, please reference it in the patch description or comments so
people can cross-reference it with documentation.
Without this workaround the divider value goes
to its reset state after the corresponding PWRDN bit is set from the
CM_CLKEN_PLL register. The correct divider value can be restored by
writing a dummy value to the register different than what is in there, and
then re-writing the desired value.
This Work around is applicable for below HS Dividers.
1. DPLL3_M3
2. DPLL4_M2
3. DPLL4_M3
4. DPLL4_M4
5. DPLL4_M5
6. DPLL4_M6
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 36
++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 15 ++
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 0d30e53..e5213f8 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -146,6 +146,42 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait = {
.find_companion = omap2_clk_dflt_find_companion,
};
+/** omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider problem.
The '/**' needs to be on its own line. I appreciate the useful comments,
but please make sure they conform to
Documentation/kernel-doc-nano-HOWTO.txt
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck, dpll4_m5_ck
+ * dpll4_m6_ck dividers get lost after their respective PWRDN bits are set.
+ * Any write to the corresponding CM_CLKSEL register will refresh the
+ * dividers. Only x2 clocks are affected, so it is safe to trust the parent
+ * clock information to refresh the CM_CLKSEL registers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 v;
+ int ret;
+
+ /* enable the clock */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ v = __raw_readl(clk-parent-clksel_reg);
+ v += (1 clk-parent-clksel_shift);
Using += here could affect many bits in the register if the add carries.
This doesn't seem like what you want.
Also, isn't there a risk of side-effects here, that if this bit was not
already set, that everything further down the clock tree from this could
be affected? Wouldn't it be best to just rewrite the correct clksel
value?
Also, this should be using __ffs() as mentioned previously.
+ __raw_writel(v, clk-parent-clksel_reg);
+ v -= (1 clk-parent-clksel_shift);
etc., same problems as above.
+ __raw_writel(v, clk-parent-clksel_reg);
Should there be an OCP barrier after this? See omap2_clksel_set_rate().
+ }
+ return ret;
+}
+
+const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore = {
+ .enable = omap3_pwrdn_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .find_companion = omap2_clk_dflt_find_companion,
+ .find_idlest= omap2_clk_dflt_find_idlest,
+};
+
const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 9a2c07e..6f7d271 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -20,5 +20,6 @@ extern const struct clkops clkops_omap3430es2_ssi_wait;
extern const struct clkops clkops_omap3430es2_hsotgusb_wait;
extern const struct clkops clkops_omap3430es2_dss_usbhost_wait;
extern const struct clkops clkops_noncore_dpll_ops;
+extern const struct clkops clkops_omap3_pwrdn_with_hsdiv_wait_restore;
#endif
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index 955d4ef..39a1b3c 100755
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -3447,6 +3447,21 @@ int __init omap2_clk_init(void)
dpll4_m4_ck = dpll4_m4_ck_3630;
dpll4_m5_ck = dpll4_m5_ck_3630;
dpll4_m6_ck = dpll4_m6_ck_3630;
+
+ /* For 3630:
RE: [PATCH 1/3] DSPBRIDGE: Fix header locations mach to plat
From: Ameya Palande on Monday, January 18, 2010 3:55 AM On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote: Fix header locations, replaced mach to plat Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/dspbridge.c|2 +- arch/arm/plat-omap/include/dspbridge/host_os.h |2 +- drivers/dsp/bridge/wmd/tiomap3430.c|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) [snip] Acked-by: Ameya Palande ameya.pala...@nokia.com Pushed to dspbridge-pm - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] DSPBRIDGE: change to cpufreq_register_notifier for OPP changes
From: Ameya Palande on Monday, January 18, 2010 4:20 AM On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote: From: Fernando Guzman Lugo x0095...@ti.com This patch changes clk_notifier_unregister with cpufreq_unregister_notifier, which is used for OPP change notifications Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- drivers/dsp/bridge/Kconfig |2 +- drivers/dsp/bridge/rmgr/drv_interface.c | 25 +++-- 2 files changed, 16 insertions(+), 11 deletions(-) [snip] Acked-by: Ameya Palande ameya.pala...@nokia.com Pushed to dspbridge-pm - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] DSPBRIDGE: Use dspbridge to initialize platform data
From: Ameya Palande on Monday, January 18, 2010 4:32 AM On Sat, 2010-01-16 at 03:01 +0100, ext Omar Ramirez Luna wrote: Include dspbridge compilation whenever bridge driver is selected to be compiled, either as a module or part of the kernel. This will initialize platform data specific PM functions. Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- arch/arm/mach-omap2/Makefile |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) [snip] Acked-by: Ameya Palande ameya.pala...@nokia.com Pushed to dspbridge-pm - 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
[PATCH] OMAP3: clock: use std _MASK suffix for CM_FCLKEN_IVA2 defines
Add _MASK suffix to CM_FCLKEN_IVA2 bitfieds to conform with the rest of the usage in cm-regbits-34xx.h of using _SHIFT and _MASK suffixes. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/cm-regbits-34xx.h |2 +- arch/arm/mach-omap2/pm34xx.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index 6923deb..a76e835 100644 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -55,7 +55,7 @@ /* Bits specific to each register */ /* CM_FCLKEN_IVA2 */ -#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2(1 0) +#define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK (1 0) #define OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT 0 /* CM_CLKEN_PLL_IVA2 */ diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index c6cc809..045fd59 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -675,7 +675,7 @@ static void __init omap3_iva_idle(void) OMAP3430_IVA2_MOD, RM_RSTCTRL); /* Enable IVA2 clock */ - cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2, + cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK, OMAP3430_IVA2_MOD, CM_FCLKEN); /* Set IVA2 boot mode to 'idle' */ -- 1.6.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] DSPBRIDGE: Undo allocation of resources in case of cp_to_usr fails
From: Ramirez Luna, Omar on Wednesday, January 13, 2010 7:11 PM From: Ernesto Ramos erne...@ti.com Release resources allocated during MAP, Node Allocation, STRM Buf Allocation in the case of cp_to_usr fails. Signed-off-by: Ernesto Ramos erne...@ti.com CC: Nishanth Menon n...@ti.com CC: Hiroshi Doyu hiroshi.d...@nokia.com CC: Ameya Palande ameya.pala...@nokia.com --- drivers/dsp/bridge/pmgr/wcd.c | 35 --- 1 files changed, 28 insertions(+), 7 deletions(-) Pushed to dspbridge - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] DSPBRIDGE: Interface tightening to check for invalid input parameters
From: Ramirez Luna, Omar on Wednesday, January 13, 2010 7:11 PM From: Ernesto Ramos erne...@ti.com Add more error checking and range to address usecases accessing kernel APIs directly. Signed-off-by: Ernesto Ramos erne...@ti.com CC: Nishanth Menon n...@ti.com CC: Hiroshi Doyu hiroshi.d...@nokia.com CC: Ameya Palande ameya.pala...@nokia.com --- arch/arm/plat-omap/include/dspbridge/dbdefs.h |4 +- drivers/dsp/bridge/pmgr/wcd.c | 91 +++- drivers/dsp/bridge/services/mem.c |4 - 3 files changed, 75 insertions(+), 24 deletions(-) Pushed to dspbridge - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] DSPBRIDGE: NULL Pointer Dereference fix
From: Omar Ramirez Luna on Wednesday, January 13, 2010 7:11 PM From: Ernesto Ramos erne...@ti.com This patch takes care of the possible null pointers dereferenced within dsp bridge driver. Signed-off-by: Ernesto Ramos erne...@ti.com CC: Nishanth Menon n...@ti.com CC: Hiroshi Doyu hiroshi.d...@nokia.com CC: Ameya Palande ameya.pala...@nokia.com --- drivers/dsp/bridge/rmgr/nldr.c |3 ++- drivers/dsp/bridge/rmgr/node.c |6 +++--- drivers/dsp/bridge/rmgr/proc.c |9 - drivers/dsp/bridge/wmd/chnl_sm.c |2 +- 4 files changed, 10 insertions(+), 10 deletions(-) Pushed to dspbridge. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: clock: use std _MASK suffix for CM_FCLKEN_IVA2 defines
On Mon, 18 Jan 2010, Kevin Hilman wrote: Add _MASK suffix to CM_FCLKEN_IVA2 bitfieds to conform with the rest of the usage in cm-regbits-34xx.h of using _SHIFT and _MASK suffixes. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks Kevin, queued for .33-rc fixes. - 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: [PATCHV2 1/2] OMAP3630: Clock: add clksel_shift to struct clk
Correcting myself here: On Mon, 18 Jan 2010, Paul Walmsley wrote: This will chew up another (4 bytes * number of struct clks) Well, not really, since clksel_shift is a u8, and for the time being, it can nestle next to that other u8. But: and it doesn't seem necessary. It still doesn't seem necessary and so should be avoided. - 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: [PATCHv3 5/6] OMAP: Powerdomains: Add support for checking if pwrdm/clkdm can idle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
pwrdm_can_idle(pwrdm) will check if the specified powerdomain can enter
idle. This is done by checking all clockdomains under the powerdomain
if they can idle also.
omap2_clkdm_can_idle(clkdm) will check if the specified clockdomain can
enter idle. This checks the functional clocks and idle status bits of the
domain according to following rules:
1) get inverse of idlest and mask against idle_def.mask
* this gives a bitmask with non-idle bits high
2) bitwise OR active functional clocks from the domain to the result
* in some cases FCLK can be active but idlest still shows module in idle
3) disable bits defined in idle_def.mask
disable? it looks like they're just being ignored.
* some bits should be ignored, like UART clocks which are dynamically
switched inside sleep loop
These calls can be used e.g. inside cpuidle to decide which power states
core and mpu should enter during idle, as there are certain dependencies
between wakeup capabilities and reset logic.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Thanks for adding the IDLEST checks, I think that will help.
In the .mask field, instead of using a hard-coded mask, probably using
the existing bitfields headers would be a bit more readable, and help
ensure correctness.
Hopefully there's a way to auto-generate these for OMAP4.
---
arch/arm/mach-omap2/clockdomain.c | 27
arch/arm/mach-omap2/clockdomains.h| 54
+
arch/arm/mach-omap2/powerdomain.c | 25 +++
arch/arm/plat-omap/include/plat/clockdomain.h | 17
arch/arm/plat-omap/include/plat/powerdomain.h |1 +
5 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index dd285f0..f42111a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -472,6 +472,33 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
return 0;
}
+
+/**
+ * omap2_clkdm_can_idle - check if clockdomain has any active clocks or not
+ * @clkdm: struct clockdomain *
+ *
+ * Checks if the clockdomain has any active clock or not, i.e. whether it
+ * can enter idle. Returns -EINVAL if clkdm is NULL; 0 if unable to idle;
+ * 1 if can idle.
+ */
+int omap2_clkdm_can_idle(struct clockdomain *clkdm)
+{
+ int i;
+
+ if (!clkdm)
+ return -EINVAL;
+
+ for (i = 0; i clkdm-clk_reg_amt; i++)
+ if (((~cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+ CM_IDLEST + 4 * i)
+ clkdm-idle_def[i].mask) |
+ cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
+ CM_FCLKEN + 4 * i))
+ ~clkdm-idle_def[i].ignore)
This has some readability/indent issues.
Also, could check fclk first, if active fclks, no reason to check
idlest. How about something like this (untested, but I *think* I kept
the same logic):
for (i = 0; i clkdm-clk_reg_amt; i++) {
u32 idlest, fclk;
fclk = cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
CM_FCLKEN + 4 * i);
if (fclk ~clkdm-idle_def[i].ignore)
return 0;
idlest = cm_read_mod_reg(clkdm-pwrdm.ptr-prcm_offs,
CM_IDLEST + 4 * i);
if (~idlest clkdm-idle_def[i].mask)
return 0;
}
+ return 0;
+ return 1;
+}
+
/**
* omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
diff --git a/arch/arm/mach-omap2/clockdomains.h
b/arch/arm/mach-omap2/clockdomains.h
index c4ee076..2c1f2eb 100644
--- a/arch/arm/mach-omap2/clockdomains.h
+++ b/arch/arm/mach-omap2/clockdomains.h
@@ -167,6 +167,12 @@ static struct clockdomain iva2_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .clk_reg_amt= 1,
+ .idle_def = {
+ [0] = {
+ .mask = 0x1,
Use OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK
+ },
+ },
};
static struct clockdomain gfx_3430es1_clkdm = {
@@ -183,6 +189,12 @@ static struct clockdomain sgx_clkdm = {
.flags = CLKDM_CAN_HWSUP_SWSUP,
.clktrctrl_mask = OMAP3430ES2_CLKTRCTRL_SGX_MASK,
.omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES2),
+ .clk_reg_amt= 1,
+ .idle_def = {
+ [0] = {
+ .mask = 0x1,
Use OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_MASK
And here's a a good reason for using the pre-defined bitmasks. According to
the #defines (and
Re: [PATCHV5 1/4] OMAP3: introduce DPLL4 Jtype
Hello Vishwanath,
some more things to fix:
On Mon, 18 Jan 2010, Vishwanath BS wrote:
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 |6 +++-
arch/arm/mach-omap2/dpll.c | 48
++-
arch/arm/plat-omap/include/plat/clock.h |5 +++
6 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 93c48df..3216f9c
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -47,6 +47,10 @@
#define DPLL_LOW_POWER_BYPASS0x5
#define DPLL_LOCKED 0x7
+/* DPLL Type and DCO Selection Flags */
+#define DPLL_J_TYPE 0x1
+#define DPLL_NO_DCO_SEL 0x2
+
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index f5ef08d..152cd3c
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -529,7 +529,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 +553,30 @@ 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 = OMAP3430_PERIPH_DPLL_MULT_MASK,
+ .div1_mask = OMAP3430_PERIPH_DPLL_DIV_MASK,
+ .clk_bypass = sys_ck,
+ .clk_ref= sys_ck,
+ .freqsel_mask = OMAP3430_PERIPH_DPLL_FREQSEL_MASK,
+ .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 = OMAP3_MAX_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,
@@ -3246,6 +3271,11 @@ int __init omap2_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 2210e22..a95930e 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..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT 8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK
Re: [PATCHV5 4/4] OMAP3: add support for 192Mhz DPLL4M2 output
Vishwanath,
On Mon, 18 Jan 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
---
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 a9ec184..1a21a91 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_192_alwon_fck = {
+ .name = omap_192_alwon_fck,
Any reason why the variable name and the .name field shouldn't both be
omap_192m_alwon_fck to match the style of the rest of this file?
+ .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_192_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_192_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 },
@@ -1308,12 +1339,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 },
@@ -1322,7 +1365,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_192_alwon_fck, .rates = sgx_192m_rates },
+ {
Re: [v2 PATCH 2/5] ARM: OMAP4: PM: OMAP4 Power Domain Porting Related Clean-up.
Abhijit Pagare abhijitpag...@ti.com writes: Module offsets were same for OMAP2 and OMAP3 while they differ for OMAP4. Hence we need different macros for identifying platform specific offsets. Signed-off-by: Abhijit Pagare abhijitpag...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Rajendra Nayak rna...@ti.com Paul, just a heads up... This patch has a minor conflict which will need be resolved after my latest set of PM fixes for 2.6.33-rc goes in shortly. [...] Namely, the duplicate blocks to Clear pending reset flags below was removed so this patch no longer applies cleanly. diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 81ed252..3189acc 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -672,7 +672,7 @@ static void __init omap3_iva_idle(void) prm_write_mod_reg(OMAP3430_RST1_IVA2 | OMAP3430_RST2_IVA2 | OMAP3430_RST3_IVA2, - OMAP3430_IVA2_MOD, RM_RSTCTRL); + OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL); /* Enable IVA2 clock */ cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2, @@ -683,7 +683,7 @@ static void __init omap3_iva_idle(void) OMAP343X_CONTROL_IVA2_BOOTMOD); /* Un-reset IVA2 */ - prm_write_mod_reg(0, OMAP3430_IVA2_MOD, RM_RSTCTRL); + prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL); /* Disable IVA2 clock */ cm_write_mod_reg(0, OMAP3430_IVA2_MOD, CM_FCLKEN); @@ -692,7 +692,7 @@ static void __init omap3_iva_idle(void) prm_write_mod_reg(OMAP3430_RST1_IVA2 | OMAP3430_RST2_IVA2 | OMAP3430_RST3_IVA2, - OMAP3430_IVA2_MOD, RM_RSTCTRL); + OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL); } static void __init omap3_d2d_idle(void) @@ -715,8 +715,8 @@ static void __init omap3_d2d_idle(void) /* reset modem */ prm_write_mod_reg(OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RSTPWRON | OMAP3430_RM_RSTCTRL_CORE_MODEM_SW_RST, - CORE_MOD, RM_RSTCTRL); - prm_write_mod_reg(0, CORE_MOD, RM_RSTCTRL); + CORE_MOD, OMAP2_RM_RSTCTRL); + prm_write_mod_reg(0, CORE_MOD, OMAP2_RM_RSTCTRL); } static void __init prcm_setup_regs(void) @@ -893,13 +893,13 @@ static void __init prcm_setup_regs(void) prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); /* Clear any pending 'reset' flags */ - prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); - prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_PER_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_EMU_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_NEON_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_DSS_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, RM_RSTST); + prm_write_mod_reg(0x, MPU_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, CORE_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_PER_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_EMU_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_NEON_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_DSS_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, OMAP2_RM_RSTST); /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET); @@ -911,13 +911,13 @@ static void __init prcm_setup_regs(void) prm_write_mod_reg(0, OMAP3430_PER_MOD, OMAP3430_PM_IVAGRPSEL); /* Clear any pending 'reset' flags */ - prm_write_mod_reg(0x, MPU_MOD, RM_RSTST); - prm_write_mod_reg(0x, CORE_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_PER_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_EMU_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_NEON_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430_DSS_MOD, RM_RSTST); - prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, RM_RSTST); + prm_write_mod_reg(0x, MPU_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, CORE_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_PER_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_EMU_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_NEON_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430_DSS_MOD, OMAP2_RM_RSTST); + prm_write_mod_reg(0x, OMAP3430ES2_USBHOST_MOD, OMAP2_RM_RSTST); Simply droppying this hunk from the patch is should be all that will be needed. Kevin /* Clear any pending PRCM interrupts */ prm_write_mod_reg(0, OCP_MOD,
RE: [PATCH 00/10] trivial cleanups
From: Ramirez Luna, Omar on Friday, January 15, 2010 3:29 PM This is a small set of trivial cleanups piled up in the patch queue. Higlights: - New patch with contributors file. - Fix multiline macros to use do while patch is dropped for rework. Omar Ramirez Luna (10): DSPBRIDGE: trivial license fix in tramp and tramp_table_c6000 DSPBRIDGE: contributors file DSPBRIDGE: trivial file history cleanup for headers DSPBRIDGE: trivial file history cleanup for driver sources DSPBRIDGE: checkpatch - space required after comma DSPBRIDGE: checkpatch - space required before open parenthesis DSPBRIDGE: checkpatch spacing and indentation DSPBRIDGE: Checkpatch - line over 80 characters DSPBRIDGE: checkpatch - printk() should include KERN_ facility level DSPBRIDGE: trivial cleanup for io_sm Documentation/tidspbridge/CONTRIBUTORS| 70 ++ arch/arm/plat-omap/include/dspbridge/_chnl_sm.h | 46 +- arch/arm/plat-omap/include/dspbridge/_dcd.h | 40 +- arch/arm/plat-omap/include/dspbridge/brddefs.h| 18 +- arch/arm/plat-omap/include/dspbridge/cfg.h| 50 +-- arch/arm/plat-omap/include/dspbridge/cfgdefs.h| 27 +- arch/arm/plat-omap/include/dspbridge/chnl.h | 45 +- arch/arm/plat-omap/include/dspbridge/chnl_sm.h| 30 +- arch/arm/plat-omap/include/dspbridge/chnldefs.h | 26 +- arch/arm/plat-omap/include/dspbridge/chnlpriv.h | 33 +- arch/arm/plat-omap/include/dspbridge/clk.h| 11 +- arch/arm/plat-omap/include/dspbridge/cmm.h| 66 +-- arch/arm/plat-omap/include/dspbridge/cmmdefs.h| 20 +- arch/arm/plat-omap/include/dspbridge/cod.h| 58 +-- arch/arm/plat-omap/include/dspbridge/dbc.h| 32 +- arch/arm/plat-omap/include/dspbridge/dbdcd.h | 26 +- arch/arm/plat-omap/include/dspbridge/dbdcddef.h | 27 +- arch/arm/plat-omap/include/dspbridge/dbdefs.h | 61 +-- arch/arm/plat-omap/include/dspbridge/dbg.h| 25 +- arch/arm/plat-omap/include/dspbridge/dbldefs.h| 10 - arch/arm/plat-omap/include/dspbridge/dbll.h | 15 +- arch/arm/plat-omap/include/dspbridge/dblldefs.h | 11 - arch/arm/plat-omap/include/dspbridge/dbtype.h | 21 +- arch/arm/plat-omap/include/dspbridge/dehdefs.h| 14 +- arch/arm/plat-omap/include/dspbridge/dev.h| 64 +-- arch/arm/plat-omap/include/dspbridge/devdefs.h| 15 +- arch/arm/plat-omap/include/dspbridge/disp.h | 31 +- arch/arm/plat-omap/include/dspbridge/dispdefs.h | 14 +- arch/arm/plat-omap/include/dspbridge/dmm.h| 18 +- arch/arm/plat-omap/include/dspbridge/dpc.h| 26 +- arch/arm/plat-omap/include/dspbridge/drv.h| 48 +- arch/arm/plat-omap/include/dspbridge/drvdefs.h| 13 +- arch/arm/plat-omap/include/dspbridge/dspdrv.h | 33 +- arch/arm/plat-omap/include/dspbridge/errbase.h| 37 +- arch/arm/plat-omap/include/dspbridge/gb.h | 10 +- arch/arm/plat-omap/include/dspbridge/getsection.h | 21 +- arch/arm/plat-omap/include/dspbridge/gh.h |8 - arch/arm/plat-omap/include/dspbridge/gs.h | 15 +- arch/arm/plat-omap/include/dspbridge/gt.h | 27 +- arch/arm/plat-omap/include/dspbridge/host_os.h| 10 - arch/arm/plat-omap/include/dspbridge/io.h | 21 +- arch/arm/plat-omap/include/dspbridge/io_sm.h | 44 +- arch/arm/plat-omap/include/dspbridge/iodefs.h | 13 +- arch/arm/plat-omap/include/dspbridge/ldr.h| 34 +- arch/arm/plat-omap/include/dspbridge/list.h | 36 +- arch/arm/plat-omap/include/dspbridge/mbx_sh.h | 25 +- arch/arm/plat-omap/include/dspbridge/mem.h| 54 +-- arch/arm/plat-omap/include/dspbridge/memdefs.h| 16 +- arch/arm/plat-omap/include/dspbridge/mgr.h| 32 +- arch/arm/plat-omap/include/dspbridge/mgrpriv.h| 14 +- arch/arm/plat-omap/include/dspbridge/msg.h| 24 +- arch/arm/plat-omap/include/dspbridge/msgdefs.h| 15 +- arch/arm/plat-omap/include/dspbridge/nldr.h | 29 +- arch/arm/plat-omap/include/dspbridge/nldrdefs.h | 14 +- arch/arm/plat-omap/include/dspbridge/node.h | 48 +- arch/arm/plat-omap/include/dspbridge/nodedefs.h | 16 +- arch/arm/plat-omap/include/dspbridge/nodepriv.h | 23 +- arch/arm/plat-omap/include/dspbridge/ntfy.h | 22 +- arch/arm/plat-omap/include/dspbridge/proc.h | 47 +- arch/arm/plat-omap/include/dspbridge/procpriv.h | 13 +- arch/arm/plat-omap/include/dspbridge/pwr.h| 19 - arch/arm/plat-omap/include/dspbridge/pwr_sh.h | 12 +- arch/arm/plat-omap/include/dspbridge/reg.h| 35 +- arch/arm/plat-omap/include/dspbridge/rmm.h| 26 +- arch/arm/plat-omap/include/dspbridge/rms_sh.h | 34 +- arch/arm/plat-omap/include/dspbridge/rmstypes.h | 15 +- arch/arm/plat-omap/include/dspbridge/services.h | 17 +- arch/arm/plat-omap/include/dspbridge/std.h| 48 --
RE: [PATCH 0/4] DPC Removal from services
From: Ramirez Luna, Omar on Friday, January 15, 2010 5:35 PM This patches remove the DPC custom implementation and wrappers. They should be applied on top of trivial cleanups set and are part of the current patch queue. Omar Ramirez Luna (4): DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers DSPBRIDGE: Remove main DPC wrapper for IO and MMUfault DSPBRIDGE: Remove DPC module from SERVICES layer DSPBRIDGE: Remove DPC object structure arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |1 - arch/arm/plat-omap/include/dspbridge/dpc.h | 145 - arch/arm/plat-omap/include/dspbridge/io_sm.h|2 +- drivers/dsp/bridge/Makefile |3 +- drivers/dsp/bridge/pmgr/chnl.c |1 - drivers/dsp/bridge/services/dpc.c | 246 --- drivers/dsp/bridge/services/services.c | 10 +- drivers/dsp/bridge/wmd/_deh.h |5 +- drivers/dsp/bridge/wmd/io_sm.c | 86 ++-- drivers/dsp/bridge/wmd/mmu_fault.c | 12 +- drivers/dsp/bridge/wmd/mmu_fault.h |2 +- drivers/dsp/bridge/wmd/ue_deh.c | 13 +- 12 files changed, 87 insertions(+), 439 deletions(-) delete mode 100644 arch/arm/plat-omap/include/dspbridge/dpc.h delete mode 100644 drivers/dsp/bridge/services/dpc.c Pushed to dspbridge - 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: [v2 PATCH 2/5] ARM: OMAP4: PM: OMAP4 Power Domain Porting Related Clean-up.
Hi Kevin, On Mon, 18 Jan 2010, Kevin Hilman wrote: Paul, just a heads up... This patch has a minor conflict which will need be resolved after my latest set of PM fixes for 2.6.33-rc goes in shortly. Great, thanks for the heads-up. - 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 1/4] omap: Clean the serial port defines
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Friday, January 15, 2010 7:35 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 1/4] omap: Clean the serial port defines
This way we don't have conflicts with the defines
with compiling in multiple omaps. Set the addresses
for uarts in struct omap_globals for the early serial
init code.
Nice and much needed cleanup.
Signed-off-by: Tony Lindgren t...@atomide.com
snip
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 6e5207c..349de90 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -64,7 +64,7 @@ static void __init omap_serial_reset(struct
plat_serial8250_port *p)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase= OMAP_UART1_BASE,
+ .mapbase= OMAP1_UART1_BASE,
Is it possible to use the same approach as mach-omap2/ for physical address
assignments?
I like that approach.
Refer this part from mach-omap2:
+ serial_platform_data0[0].mapbase = omap2_globals-uart1_phys;
+ serial_platform_data1[0].mapbase = omap2_globals-uart2_phys;
+ serial_platform_data2[0].mapbase = omap2_globals-uart3_phys;
.irq= INT_UART1,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
snip
diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
b/arch/arm/mach-omap2/include/mach/debug-
macro.S
index e9f255d..0c96e1c 100644
--- a/arch/arm/mach-omap2/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
@@ -11,6 +11,10 @@
*
*/
+#include linux/serial_reg.h
+
+#include plat/serial.h
+
.macro addruart,rx
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
@@ -44,15 +48,10 @@
.endm
.macro busyuart,rd,rx
-1001: ldrb\rd, [\rx, #(0x5 2)] @ OMAP-1510 and friends
- and \rd, \rd, #0x60
- teq \rd, #0x60
- beq 1002f
- ldrb\rd, [\rx, #(0x5 0)] @ OMAP-730 only
- and \rd, \rd, #0x60
- teq \rd, #0x60
+1001: ldrb\rd, [\rx, #(UART_LSR OMAP_PORT_SHIFT)]
Zoom2/3 kind of boards have external debug Serial port.
For those boards and maybe others, the shift value is 1 and not
OMAP_PORT_SHIFT(2).
This solution is not extensible to zoom2/3 boards with external debug board
uarts.
How do we address that?
+ and \rd, \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
+ teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
bne 1001b
-1002:
.endm
.macro waituart,rd,rx
snip
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
snip
@@ -269,11 +278,15 @@ static struct omap_globals omap343x_globals = {
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
+ .uart1_phys = OMAP3_UART1_BASE,
+ .uart2_phys = OMAP3_UART2_BASE,
+ .uart3_phys = OMAP3_UART3_BASE,
OMAP3630 also has 4 UARTS and this same global is getting used for both 34xx
and 36xx.
This is not right.
For 3630 uart4_phys = 0x49042000
};
void __init omap2_set_globals_343x(void)
{
__omap2_set_globals(omap343x_globals);
+ omap2_set_globals_uart(omap343x_globals);
}
#endif
@@ -285,6 +298,10 @@ static struct omap_globals omap4_globals = {
.prm= OMAP2_L4_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP4430_CM_BASE),
.cm2= OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE),
+ .uart1_phys = OMAP4_UART1_BASE,
+ .uart2_phys = OMAP4_UART2_BASE,
+ .uart3_phys = OMAP4_UART3_BASE,
+ .uart4_phys = OMAP4_UART4_BASE,
};
void __init omap2_set_globals_443x(void)
@@ -292,6 +309,7 @@ void __init omap2_set_globals_443x(void)
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
+ omap2_set_globals_uart(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 32c2227..a8fa0d7 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -47,6 +47,10 @@ struct omap_globals {
void __iomem*prm; /* Power and Reset Management */
void __iomem*cm;/* Clock Management */
void __iomem*cm2;
+ unsigned long uart1_phys;
+ unsigned long uart2_phys;
+ unsigned long uart3_phys;
+ unsigned long uart4_phys;
};
void omap2_set_globals_242x(void);
@@ -59,6
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony
Lindgren
Sent: Friday, January 15, 2010 7:35 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
UART_SCR- this is the scratchpad register
UART_OMAP_SCR - This is TI-only Supplementary control register
You probably confused the two (as rightly so since SCR is same name).
So there is no need to save/restore the UART_SCR register as you have done, see
inlined --
Define arch_decomp_setup() the same way as some other
architectures do. Use arch_id to configure the debug uart
based on the machine_is by storing it into the uart
scratchpad register for DEBUG_LL code to use.
Signed-off-by: Tony Lindgren t...@atomide.com
snip
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -161,11 +161,22 @@ static inline void serial_write_reg(struct
plat_serial8250_port *p, int offset,
static inline void __init omap_uart_reset(struct omap_uart_state *uart)
{
struct plat_serial8250_port *p = uart-p;
+ u8 scratchpad = 0;
+
+ /*
+ * Save UART1 scratchpad register value for UART1 for DEBUG_LL.
+ * See also include/plat/uncompress.h and include/mach/debug-macro.S.
+ */
+ if (p-mapbase == OMAP2_UART1_BASE) /* OMAP2/3/4UART1_BASE */
+ scratchpad = serial_read_reg(p, UART_SCR);
No need to save and restore the UART_SCR register.
This never gets used in this function.
What gets used is UART_OMAP_SCR which is OMAP specific supplimantry control
register
and not scratchpad.
serial_write_reg(p, UART_OMAP_MDR1, 0x07);
serial_write_reg(p, UART_OMAP_SCR, 0x08);
serial_write_reg(p, UART_OMAP_MDR1, 0x00);
serial_write_reg(p, UART_OMAP_SYSC, (0x02 3) | (1 2) | (1 0));
+
+ if (p-mapbase == OMAP2_UART1_BASE) /* OMAP2/3/4UART1_BASE */
+ serial_write_reg(p, UART_SCR, scratchpad);
Remove this as well. No need.
snip
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-
omap/include/plat/uncompress.h
index 13c305d..479bac8 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -19,62 +19,36 @@
#include linux/types.h
#include linux/serial_reg.h
+
+#include asm/mach-types.h
+
#include plat/serial.h
-unsigned int system_rev;
+static volatile u8 *uart1_base;
+static volatile u8 *uart_base;
+static volatile int uart_shift;
Just like uart_base is stored in scratchpad,
Somehow the uart_shift also needs to be stored so that boards with different
uart_shift requirements can be addressed. Where can we store this another
variable?
snip
/*
+ * Macros to configure UART1 and debug UART
+ */
+#define _DEBUG_LL_ENTRY(mach, uart1, dbg_uart, shift, dbg_id, reset_fn)
\
+ if (machine_is_##mach()) { \
+ uart1_base = (volatile u8 *)(uart1);\
+ uart_base = (volatile u8 *)(dbg_uart); \
+ uart_shift = (shift); \
+ port = (dbg_id);\
+ reset_fn; \
+ break; \
+ }
Nice Idea... you are the man !!
snip
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
[PATCH] DSPBRIDGE: Fix wrong condition on NODE_GetUUIDProps
Fix wrong condition because of a wrong patch included.
Discovered-by: Ernesto Ramos Falcon erne...@ti.com
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/rmgr/node.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 72c2411..e8ba0dd 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -3252,7 +3252,7 @@ DSP_STATUS NODE_GetUUIDProps(DSP_HPROCESSOR hProcessor,
pNodeId, pNodeProps);
status = PROC_GetDevObject(hProcessor, hDevObject);
- if (!hDevObject) {
+ if (hDevObject) {
status = DEV_GetNodeManager(hDevObject, hNodeMgr);
if (hNodeMgr == NULL) {
status = DSP_EHANDLE;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, January 16, 2010 2:00 PM To: Russell King - ARM Linux Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] omap: Make uncompress code and DEBUG_LL code generic * Russell King - ARM Linux li...@arm.linux.org.uk [100116 11:31]: On Sat, Jan 16, 2010 at 11:18:20AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100116 01:33]: On Fri, Jan 15, 2010 at 05:35:15PM -0800, Tony Lindgren wrote: diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach- omap1/include/mach/debug-macro.S index 23e4724..0174858 100644 --- a/arch/arm/mach-omap1/include/mach/debug-macro.S +++ b/arch/arm/mach-omap1/include/mach/debug-macro.S @@ -15,18 +15,71 @@ #include plat/serial.h +omap_uart_phys: .word 0x0 +omap_uart_virt: .word 0x0 I assume that you have no plans for XIP kernel support on OMAP, since these will be placed in the .text section, and is therefore read-only on XIP kernels. Did not think of that.. Maybe some addruart_premable solution here would. Or adding \tmp register for addruart and just do the detection for each character. How does doing it per-character help? The code is: ENTRY(printascii) addruart r3 b 2f 1: waituart r2, r3 senduart r1, r3 busyuart r2, r3 teq r1, #'\n' moveq r1, #'\r' beq 1b 2: teq r0, #0 ldrneb r1, [r0], #1 teqne r1, #0 bne 1b mov pc, lr Your wait/send/busy macros are just using the already provided base address which comes via r3 from addruart. That much is fine. I'm at a loss to understand why you think moving the address-getting functionality out of addruart into the individual wait/send/busy macros is going to help in any way. Sorry, I meant doing the detection each time addruart is run, not for each character. Why not do something like this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 Also We may need a: omap_uart_shift: .word 0 Since shift also varies depending on different omap boards (external debug board shift=1, internal omap has shift=2) Bingo..I think this was the key solution to the problem. I had posted long ago similar kind of implementation [1] and I wish rmk had given this nice idea then :) [1] http://marc.info/?l=linux-omapm=125269221820632w=2 See this part: + .align + .type __phy_uart_addr, #object +__phy_uart_addr: .word 0xFF + .type __virt_uart_addr, #object +__virt_uart_addr: .word 0xFF .popsection .macro addruart, rx ... + ldreq \rx, =omap_uart_phys@ physical base address + ldrne \rx, =omap_uart_virt@ virtual base ldr \rx, [\rx] + cmp \rx, #0 @ is port configured? + bne 99f @ already configured ... ? Sounds good to me. Will play with them and post refreshed patches. 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 -- To unsubscribe from this list: send the line unsubscribe 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 wrong condition on NODE_GetUUIDProps
From: Ramirez Luna, Omar Sent: Monday, January 18, 2010 7:58 PM To: linux-omap Cc: Ameya Palande; Hiroshi Doyu; Felipe Contreras; Menon, Nishanth; Ramirez Luna, Omar Subject: [PATCH] DSPBRIDGE: Fix wrong condition on NODE_GetUUIDProps Fix wrong condition because of a wrong patch included. Discovered-by: Ernesto Ramos Falcon erne...@ti.com Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/dsp/bridge/rmgr/node.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) As this a fix from a previous patch, pushed to dspbridge. - 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: [PATCHV5 2/4] OMAP3: Remove FreqSel for 3630
Vishwanath,
more comments.
On Mon, 18 Jan 2010, Vishwanath BS wrote:
DPLL_FREQSEL field in CLKEN_PLL register is no longer valid for OMAP3630. So
remove
references to that.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/dpll.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index 87a5529..f872d10 100755
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -346,8 +346,9 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
/* 3430 ES2 TRM: 4.7.6.9 DPLL Programming Sequence */
_omap3_noncore_dpll_bypass(clk);
- /* Set jitter correction */
- if (!cpu_is_omap44xx()) {
+ /* Set jitter correction. No jitter correction for OMAP4 and 3630
+ since freqsel is field is no longer present */
Again, please follow Documentation/CodingStyle for your comment format.
+ if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
v = __raw_readl(dd-control_reg);
v = ~dd-freqsel_mask;
v |= freqsel __ffs(dd-freqsel_mask);
@@ -430,8 +431,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (dd-last_rounded_rate == 0)
return -EINVAL;
- /* No freqsel on OMAP4 */
- if (!cpu_is_omap44xx()) {
+ /* No freqsel on OMAP4 and OMAP3630 */
+ if (!cpu_is_omap44xx() !cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
if (!freqsel)
--
1.5.6.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
- 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: [PATCHV2 2/2] OMAP3630: Clock: Fixing HSDivider Limitation
On Mon, 2010-01-18 at 19:04 +0100, ext Paul Walmsley wrote:
Vijayakumar, Mike,
Without this workaround the divider value goes
to its reset state after the corresponding PWRDN bit is set from the
CM_CLKEN_PLL register. The correct divider value can be restored by
writing a dummy value to the register different than what is in there, and
then re-writing the desired value.
This Work around is applicable for below HS Dividers.
1. DPLL3_M3
2. DPLL4_M2
3. DPLL4_M3
4. DPLL4_M4
5. DPLL4_M5
6. DPLL4_M6
Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Vijaykumar GN vijaykumar...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 36
++
arch/arm/mach-omap2/clock34xx.h |1 +
arch/arm/mach-omap2/clock34xx_data.c | 15 ++
3 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index 0d30e53..e5213f8 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -146,6 +146,42 @@ const struct clkops clkops_omap3430es2_hsotgusb_wait =
{
.find_companion = omap2_clk_dflt_find_companion,
};
+/** omap3_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider problem.
The '/**' needs to be on its own line. I appreciate the useful comments,
but please make sure they conform to
Documentation/kernel-doc-nano-HOWTO.txt
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
dpll4_m5_ck
+ * dpll4_m6_ck dividers get lost after their respective PWRDN bits are
set.
+ * Any write to the corresponding CM_CLKSEL register will refresh the
+ * dividers. Only x2 clocks are affected, so it is safe to trust the
parent
+ * clock information to refresh the CM_CLKSEL registers.
+ */
+int omap3_pwrdn_clk_enable_with_hsdiv_restore(struct clk *clk)
+{
+ u32 v;
+ int ret;
+
+ /* enable the clock */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Restore the dividers */
+ if (!ret) {
+ v = __raw_readl(clk-parent-clksel_reg);
+ v += (1 clk-parent-clksel_shift);
Using += here could affect many bits in the register if the add carries.
This doesn't seem like what you want.
Also, isn't there a risk of side-effects here, that if this bit was not
already set, that everything further down the clock tree from this could
be affected? Wouldn't it be best to just rewrite the correct clksel
value?
The assumption is that the divider is correct in the register so I guess
the clock tree should be fine? The proper clksel/divider has been
earlier set but for some reason HW loses the divider if PWRDN is
toggled.
Our experiments with this issue show that just read/write of same value
is not enough to refresh the HW. The clksel has to be written with a
different divider first and then write the original divider back.
--
Ari
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
