RE: [PATCH-V2 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Fri, Mar 30, 2012 at 21:04:40, Hunter, Jon wrote:
Hi Vaibhav,
On 3/30/2012 8:54, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86
-
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
[...]
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+* First check for availability for 32k-sync timer.
+*
+* In case of failure in finding 32k_counter module or
+* registering it as clocksource, execution will fallback to
+* gp-timer.
+*/
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
+ size = oh-slaves[0]-addr-pa_end -
+ oh-slaves[0]-addr-pa_start;
+ res = omap_init_clocksource_32k(pbase, size);
+ if (!res)
+ return;
If omap_init_clocksource_32k() fails should we also call BUG_ON here?
I don't think we should do that, for following reasons,
- There will be platforms without 32k_counter modules, like am33xx.
For them, this BUG_ON will miss-leading.
- pr_err is already used to provide failure in this function.
- We have safe fallback option here.
+ }
+ /* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
- pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
- gptimer_id, clksrc.rate);
-
__omap_dm_timer_load_start(clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
@@ -294,8 +299,10 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
+ else
+ pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
+ gptimer_id, clksrc.rate);
}
-#endif
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,
\
clksrc_nr, clksrc_src) \
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index 5068fe5..c1af18c 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -35,8 +35,6 @@
*/
static void __iomem *timer_32k_base;
-#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410
-
static u32 notrace omap_32k_read_sched_clock(void)
{
return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
@@ -68,54 +66,42 @@ void read_persistent_clock(struct timespec *ts)
*ts = *tsp;
}
-int __init
Re: [PATCH-V2 1/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote: Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com CC: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei tom.leim...@gmail.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2 2/3] ARM: OMAP2+: hwmod data: Add 32k-sync timer data to hwmod database
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote: Add 32k-sync timer hwmod data to omap2 3 hwmod table and also enable existing hwmod data for omap4 (was disabled before). Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com CC: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei tom.leim...@gmail.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap1: mux: add missing include
On 04/01/2012 06:30 PM, Aaro Koskinen wrote: Fix the following build breakage in v3.4-rc1: arch/arm/mach-omap1/mux.c:89:1: error: 'FUNC_MUX_CTRL_9' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:89:1: error: 'PULL_DWN_CTRL_2' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:93:1: error: 'FUNC_MUX_CTRL_C' undeclared here (not in a function) etc. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/mach-omap1/mux.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) (happens with omap1_defconfig if CONFIG_OMAP_MUX=y) Acked-by: Jarkko Nikula jarkko.nik...@bitmer.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
L2 cache stability workaround for 4460 ES1.0
Hi Santosh,
I came across the attached patch from you. I also came across this post
stating that it was decided not to send this patch upstream.
http://www.digipedia.pl/usenet/thread/18885/8437/#post8496
The problem is that we have to keep porting this patch each time we
update the kernel.
Do you know if the root cause has been found? If not can we have this
patch upstream till the root cause is found?
It seems the patch at least makes the kernel usable on ES1.0.
regards,
-roger
From 68ab20c60335eef5aceb9c5f978b8d6ef4b11d9b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Tue, 27 Mar 2012 11:20:09 -0400
Subject: [PATCH 1/3] OMAP4460: L2X0: work-around for stability.
OMAP4460 ES1.0 seems to suffer from stability with L2 cache enabled.
The root-cause analysis is ongoing but in meantime this chabe is
to enable a software WA with L2 cache enabled build. The WA consist
of locking certain cache ways based on their positions on the
physical memory layout.
Downside of this WA is that effective L2 cache size will be 512 KB
instead of 1 MB.
clalancette: Changed so that the workaround is only activated
for ES1.0, and not ES1.1.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Chris Lalancette clalance...@gmail.com
---
arch/arm/include/asm/hardware/cache-l2x0.h |5 +
arch/arm/mach-omap2/omap4-common.c | 18 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 7df239b..8e3f8f2 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -56,6 +56,11 @@
#define L2X0_LOCKDOWN_STRIDE 0x08
#define L2X0_ADDR_FILTER_START 0xC00
#define L2X0_ADDR_FILTER_END 0xC04
+#define L2X0_LOCKDOWN_WAY_D0 0x900
+#define L2X0_LOCKDOWN_WAY_D1 0x908
+#define L2X0_LOCKDOWN_WAY_I0 0x904
+#define L2X0_LOCKDOWN_WAY_I1 0x90C
+
#define L2X0_TEST_OPERATION 0xF00
#define L2X0_LINE_DATA 0xF10
#define L2X0_LINE_TAG 0xF30
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 70de277..4e190c8 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -129,6 +129,7 @@ static void omap4_l2x0_set_debug(unsigned long val)
static int __init omap_l2_cache_init(void)
{
u32 aux_ctrl = 0;
+ u32 lockdown = 0;
/*
* To avoid code running on other OMAPs in
@@ -164,6 +165,23 @@ static int __init omap_l2_cache_init(void)
if (omap_rev() != OMAP4430_REV_ES1_0)
omap_smc1(0x109, aux_ctrl);
+ /*
+ * WA for OMAP4460 ES1.0 L2 cache corruption issue.
+ * Lock-down specific L2 cache ways which makes effective
+ * L2 size as 512 KB instead of 1 MB
+ *
+ * The L2 cache in the ES1.1 doesn't have this issue, so only enable
+ * the workaround for ES1.0.
+ */
+ if (omap_rev() == OMAP4460_REV_ES1_0) {
+ printk(KERN_INFO OMAP4460 ES1.0 detected, enabling L2 cache stability workaround\n);
+ lockdown = 0xa5a5;
+ writel_relaxed(lockdown, l2cache_base + L2X0_LOCKDOWN_WAY_D0);
+ writel_relaxed(lockdown, l2cache_base + L2X0_LOCKDOWN_WAY_D1);
+ writel_relaxed(lockdown, l2cache_base + L2X0_LOCKDOWN_WAY_I0);
+ writel_relaxed(lockdown, l2cache_base + L2X0_LOCKDOWN_WAY_I1);
+ }
+
/* Enable PL310 L2 Cache controller */
omap_smc1(0x102, 0x1);
--
1.7.9.1
Re: [PATCH-V2 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Friday 30 March 2012 07:24 PM, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
Thanks for the change log update Vaibhav.
Some more comments.
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86 -
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index a2e6d07..3f96a00 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -72,6 +72,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc410
Shouldn't you just update OMAP1_32K_TIMER_BASE ?
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR 0x00
#define OMAP1_32K_TIMER_TCR 0x04
@@ -185,7 +186,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
If pbase is NULL, you might not want to call the init.
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5c9acea..f35db1a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+ * First check for availability for 32k-sync timer.
+ *
+ * In case of failure in finding 32k_counter module or
+ * registering it as clocksource, execution will fallback to
+ * gp-timer.
+ */
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
Don't hardcode the offset here. This is error prone when the IP
changes so use the register define.
+ size = oh-slaves[0]-addr-pa_end -
+ oh-slaves[0]-addr-pa_start;
+ res = omap_init_clocksource_32k(pbase, size);
+ if (!res)
+ return;
+ }
If 'OMAP_32K_TIMER' is not selected, does omap_init_clocksource_32k()
fails too ?
+ /* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
-
Re: L2 cache stability workaround for 4460 ES1.0
On Mon, Apr 2, 2012 at 12:25 PM, Roger Quadros rog...@ti.com wrote: Hi Santosh, I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream. http://www.digipedia.pl/usenet/thread/18885/8437/#post8496 The problem is that we have to keep porting this patch each time we update the kernel. Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found? Yes and fixed in OMAP4460 ES1.2. It seems the patch at least makes the kernel usable on ES1.0. I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0 Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: L2 cache stability workaround for 4460 ES1.0
On 04/02/2012 10:38 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 12:25 PM, Roger Quadros rog...@ti.com wrote: Hi Santosh, I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream. http://www.digipedia.pl/usenet/thread/18885/8437/#post8496 The problem is that we have to keep porting this patch each time we update the kernel. Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found? Yes and fixed in OMAP4460 ES1.2. Did you mean ES1.1? Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690 It seems the patch at least makes the kernel usable on ES1.0. I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0 Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix. What do you say? regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: L2 cache stability workaround for 4460 ES1.0
On 04/02/2012 10:58 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 1:25 PM, Roger Quadros rog...@ti.com wrote: On 04/02/2012 10:38 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 12:25 PM, Roger Quadros rog...@ti.com wrote: Hi Santosh, I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream. http://www.digipedia.pl/usenet/thread/18885/8437/#post8496 The problem is that we have to keep porting this patch each time we update the kernel. Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found? Yes and fixed in OMAP4460 ES1.2. Did you mean ES1.1? yep. Sorry for the typo. Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690 It seems the patch at least makes the kernel usable on ES1.0. I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0 Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix. What do you say? My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it. OK Santosh. seems like cache is broken bad on ES1.0. Is it possible to disable the cache for ES1.0 and print a warning message about it? regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: L2 cache stability workaround for 4460 ES1.0
On Mon, Apr 2, 2012 at 1:25 PM, Roger Quadros rog...@ti.com wrote: On 04/02/2012 10:38 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 12:25 PM, Roger Quadros rog...@ti.com wrote: Hi Santosh, I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream. http://www.digipedia.pl/usenet/thread/18885/8437/#post8496 The problem is that we have to keep porting this patch each time we update the kernel. Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found? Yes and fixed in OMAP4460 ES1.2. Did you mean ES1.1? yep. Sorry for the typo. Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690 It seems the patch at least makes the kernel usable on ES1.0. I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0 Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix. What do you say? My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: L2 cache stability workaround for 4460 ES1.0
On Mon, Apr 2, 2012 at 1:32 PM, Roger Quadros rog...@ti.com wrote: On 04/02/2012 10:58 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 1:25 PM, Roger Quadros rog...@ti.com wrote: On 04/02/2012 10:38 AM, Shilimkar, Santosh wrote: On Mon, Apr 2, 2012 at 12:25 PM, Roger Quadros rog...@ti.com wrote: Hi Santosh, I came across the attached patch from you. I also came across this post stating that it was decided not to send this patch upstream. http://www.digipedia.pl/usenet/thread/18885/8437/#post8496 The problem is that we have to keep porting this patch each time we update the kernel. Do you know if the root cause has been found? If not can we have this patch upstream till the root cause is found? Yes and fixed in OMAP4460 ES1.2. Did you mean ES1.1? yep. Sorry for the typo. Could you please point me to the errata ID? The only cache related errata I can see is Errata ID: i690 It seems the patch at least makes the kernel usable on ES1.0. I know but that still is not enough. It's like 80 % WA of the issue seen on ES1.0. We are not suppose to have many boards with ES1.0 Even better if there are not many boards. It seems most of the boards will be with TI. I think we should have the fix in even if it is not 100% fix. What do you say? My request is to get rid of ES1.0 board because the WA just not completely correct. Don't feel patching kernel for silicon which is not suppose to be used nether has complete WA to support it. OK Santosh. seems like cache is broken bad on ES1.0. Is it possible to disable the cache for ES1.0 and print a warning message about it? Let's not add that support. See there are very few boards in TI where ES1.0 is used so I suggest those users keep using whatever works for them. Disable or the partial WA. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8][git pull] mmc: omap: Assorted fixes for 3.4 merge window
Hi, On Mon, Apr 02 2012, S, Venkatraman wrote: I've rebased patches 3-8 into a new branch (See below). I'll send you 1-2 on top of 3.4-rc2 once it's out. Is it Ok ? Yes, thanks. == The following changes since commit a4dfa827bb5b9a984d4000ffb80134b9495e4d8a: mmc: sdio: Use empty system suspend/resume callbacks at the bus level (2012-04-01 00:35:06 -0400) are available in the git repository at: git://github.com/svenkatr/linux.git omap-mmc-fixes-3.4 for you to fetch changes up to 80f833a2f77b8d6464209c0bb00a39ad835356a0: mmc: omap4: hsmmc: fix module re-insertion (2012-04-02 12:26:47 +0530) Balaji T K (3): mmc: omap: use runtime put sync in probe error patch mmc: omap: context save after enabling runtime pm mmc: omap4: hsmmc: fix module re-insertion Felipe Balbi (3): mmc: host: omap_hsmmc: trivial cleanups mmc: host: omap_hsmmc: make it behave well as a module mmc: host: omap_hsmmc: convert to module_platform_driver Pushed to mmc-next for 3.4, and I normalized the commit message first lines to: mmc: omap_hsmmc: description Thanks very much, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe 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/5] mtd: plat_nand: Add default partition parser and use it
On Wed, 2012-03-28 at 11:12 -0700, H Hartley Sweeten wrote: This patch series adds cmdlinepart as the default partition parser for the plat_nand driver and updates all the arch setup code to use it. Arch setup code that requires other partition parsers can still pass that information as chip.part_probe_types. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Pushed the series to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: Suspend broken on 3.3?
-Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk, Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Mon, 2 Apr 2012 16:13:13 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 5:54 PM, Raja, Govindraj govindraj.r...@ti.com wrote: On Fri, Mar 30, 2012 at 4:34 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Fri, 30 Mar 2012 15:45:19 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward j...@terrafix.co.uk wrote: ...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. Sorry I forgot to specify this is needed for latest mainline. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. I tried it on my 3430sdp but strangely I don't see a 0x00 char read after disabling uart wakeups and waking up by keypad press. Probably as a quick try we can try doing uart_insert_char only if data was read from rx fifo (Attached patch) Sadly the patch makes no difference. I'm suprised you aren't seeing similar effects. I've done more testing, and a simplified test case is as follows: - take a stock 3.3 kernel and apply your patch to allow disabling of wake-from-suspend for the serial ports. - disable wake-from-suspend for the console tty: echo disable /sys/devices/platform/omap/omap_uart.2/power/wakeup - perform a suspend (you'll need a button or something to wake you now that the console wont). echo mem /sys/power/state At this point the console is noticable/painfully slow. No characters are lost, but it's obvious something isn't right! Yes I see this behavior with console now it becomes very slow after we disable module level wakeups. One difference to note is : in 3.2 = full system PM is prevented in idle path if uart is active i.e, MPU will not hit retention in 3.3 = MPU will hit retention independently of uart is active or not. I think the way to get MPU qos for uart port activity while in irq mode is to use PM_WKEN1 reg settings, meaning enabling module level wakeup event generation. Disabling it is causing this slow response. Checking if we can workaround this scenario. As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Does that get us back to the same behaviour as in 3.2? If thats the best we can do, then I guess that'll have to do. Will similar problems exist when in DMA-mode (as we I set the DMA flag it seemed to work ok)? It does seem a little strange from my naive point of view: surely what peripherals/pins are used to wake the device from suspend should not affect how the device chooses to enable/disable clocks/power-domains to save power when running? Cheers, Joe -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/3] OMAPDSS: DISPC: Enable predecimation for DMA and VRFB
Hi everyone, the following patch set directs to enable predecimation for DMA and VRFB which consists of two pacthes. The first patch is based on code written by Lajos Molnar la...@ti.com in Android Kernel, which updates the code with predecimation logic thereby increasing the downscaling ability of the DISPC module. The second patch is based on code written by Ville Syrjälä ville.syrj...@nokia.com which aims to avoid synclost errors occurring in OMAP3 due to some undocumented horizontal position and timing related limitations which I faced during testing of the previous patch. The third patch corrects the usage of dispc fclk in scaling checks by replacing it with dispc_core_clk as per suggestions of Ville Syrjälä. Modifications in V3 series: * In 1st patch a check for decim_x_min has been added to avoid assigning of decim_x less than possible leading to assignment of scaling more than 4 times * In 2nd patch - check_horiz_timing() has been changed to check_horiz_timing_omap3() and function description in code has been added - clean up code of dispc_mgr_lclk_rate() has been removed * In 3rd patch dispc_core_clk_rate() is introduced. I have tested these patches successfully on OMAP2, OMAP3 AND OMAP4 on the mainline kernel v3.4rc1. Horizontal and vertical predecimation worked fine but skewed images were seen on OMAP2 and OMAP3 on HDMI tv during horizontal predecimation which will be addressed in the future patches. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (3): OMAPDSS: DISPC: Enable predecimation OMAPDSS: DISPC: Handle synclost errors in OMAP3 OMAPDSS: DISPC: Correct DISPC functional clock usage drivers/video/omap2/dss/dispc.c | 354 +- drivers/video/omap2/dss/dss.h |1 + 2 files changed, 271 insertions(+), 84 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
[PATCH V3 2/3] OMAPDSS: DISPC: Handle synclost errors in OMAP3
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrjälä ville.syrj...@nokia.com in Linux OMAP kernel. Ville
Syrjälä ville.syrj...@nokia.com had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 72 +--
1 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ab5433..17ffa71 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1664,6 +1664,63 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
}
}
+/*
+ * This function is used to avoid synclosts in OMAP3, because of some
+ * undocumented horizontal position and timing related limitations.
+ */
+static int check_horiz_timing_omap3(enum omap_channel channel, u16 pos_x,
+ u16 width, u16 height, u16 out_width, u16 out_height)
+{
+ int DS = DIV_ROUND_UP(height, out_height);
+ struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
+ struct omap_video_timings t = dssdev-panel.timings;
+ unsigned long nonactive, lclk, pclk;
+ static const u8 limits[3] = { 8, 10, 20 };
+ u64 val, blank;
+ int i;
+
+ nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ pclk = dispc_mgr_pclk_rate(channel);
+ if (dispc_mgr_is_lcd(channel))
+ lclk = dispc_mgr_lclk_rate(channel);
+ else
+ lclk = dispc_fclk_rate();
+
+ i = 0;
+ if (out_height height)
+ i++;
+ if (out_width width)
+ i++;
+ blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ DSSDBG(blanking period + ppl = %llu (limit = %u)\n, blank, limits[i]);
+ if (blank = limits[i])
+ return -EINVAL;
+
+ /*
+* Pixel data should be prepared before visible display point starts.
+* So, atleast DS-2 lines must have already been fetched by DISPC
+* during nonactive - pos_x period.
+*/
+ val = div_u64((u64)(nonactive - pos_x) * lclk, pclk);
+ DSSDBG((nonactive - pos_x) * pcd = %llu max(0, DS - 2) * width = %d\n,
+ val, max(0, DS - 2) * width);
+ if (val max(0, DS - 2) * width)
+ return -EINVAL;
+
+ /*
+* All lines need to be refilled during the nonactive period of which
+* only one line can be loaded during the active period. So, atleast
+* DS - 1 lines should be loaded during nonactive period.
+*/
+ val = div_u64((u64)nonactive * lclk, pclk);
+ DSSDBG(nonactive * pcd = %llu, max(0, DS - 1) * width = %d\n,
+ val, max(0, DS - 1) * width);
+ if (val max(0, DS - 1) * width)
+ return -EINVAL;
+
+ return 0;
+}
+
static unsigned long calc_fclk_five_taps(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
@@ -1748,7 +1805,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim)
+ int *x_predecim, int *y_predecim, u16 pos_x)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -1824,6 +1881,9 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk_five_taps(channel, in_width, in_height,
out_width, out_height, color_mode);
+ error = check_horiz_timing_omap3(channel, pos_x,
+ in_width, in_height, out_width, out_height);
+
if (in_width maxsinglelinewidth)
if (in_height out_height
in_height out_height * 2)
@@ -1831,7 +1891,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (!*five_taps)
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
- error = (in_width maxsinglelinewidth * 2 ||
+ error = (error || in_width maxsinglelinewidth * 2 ||
Re: [PATCH v2] OMAP2+: UART: Remove cpu checks for populating errata flags
Hi Govindraj,
Looks good, one minor comment ...
On 4/2/2012 3:48, Govindraj.R wrote:
From: Govindraj.R govindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 75
-
3 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..6affdd4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata = omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index 0121486..7d218c6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#include plat/dmtimer.h
#include plat/omap-serial.h
+#define UART_BUILD_REVISION(x, y)(((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -53,6 +60,18 @@
#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK (0x3 6)
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK0x0f
+
+#define OMAP_UART_MVR_MAJ_MASK 0x7
I think that you need to be consistent in how you define the mask and
shifts here. For Legacy major the mask is the actual bits in the
register representing the major number but for non-legacy the mask is
simply the bits minus the shift. So may be change the above define to ...
#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT 8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
+
I think you can remove one of the above lines of white space.
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1346,6 +1365,59 @@ static void uart_tx_dma_callback(int lch, u16
ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr OMAP_UART_MVR_SCHEME_SHIFT;
+
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
+ major = (mvr OMAP_UART_LEGACY_MVR_MAJ_MASK)
+ OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
+ minor = (mvr OMAP_UART_LEGACY_MVR_MIN_MASK);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr OMAP_UART_MVR_MAJ_SHIFT)
+ OMAP_UART_MVR_MAJ_MASK;
By changing the mask
Re: [PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
Hi Santosh, Santosh Shilimkar santosh.shilim...@ti.com writes: The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. Thanks for rebasing this. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase This branch by itself seems to work fine. However, when combining with other stuff that has merged for v3.4, it hangs during boot. I haven't yet isolated the problem, but it's easy to reproduce by combining your branch with v3.4-rc1: git checkout -b test/coupled-v3.4 v3.4-rc1 git merge -s recursive -X ours santosh/for_3.5/omap4_coupled_cpuidle-rebase [1] This hangs on boot, and it seems like a coupled state deadlock because commenting out the coupled states in the C-state creation of cpuidle44xx.c makes it boot just fine. Kevin [1] There were a couple conflicts in your branch with ACPI stuff from v3.4-rc1 (maybe Len updated his branch?), so I just threw them away with a recursive/ours merge. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] Input: omap-keypad: dynamically handle register offsets
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Test Info
- Tested on omap4 sdp with 3.4-rc1
- Tested on omap5430evm with 3.1 custom kernel.
drivers/input/keyboard/Kconfig|6 +-
drivers/input/keyboard/omap4-keypad.c | 120 ++--
2 files changed, 100 insertions(+), 26 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..9a0e1a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -511,10 +511,10 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..742e1e3 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,6 +68,11 @@
#define OMAP4_MASK_IRQSTATUSDISABLE0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
@@ -76,11 +81,66 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base + offset);
+}
+
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 offset, u32 value)
+{
+ return __raw_writel(value, keypad_data-base + offset);
+}
+
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ return __raw_readl(keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ return __raw_readl(keypad_data-base + offset + 0x10);
+
+ return -ENODEV;
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
+{
+ if (keypad_data-revision == KBD_REVISION_OMAP4)
+ __raw_writel(value, keypad_data-base + offset);
+ else if (keypad_data-revision == KBD_REVISION_OMAP5)
+ __raw_writel(value, keypad_data-base + offset + 0x10);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -ENODEV;
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +151,11 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
-keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, keypad_data-irqenable,
+ OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +180,13 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqstatus(keypad_data,
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Tue, Apr 3, 2012 at 12:05 AM, Kevin Hilman khil...@ti.com wrote: Shilimkar, Santosh santosh.shilim...@ti.com writes: [...] I don't personally like to add features which hardly anybody use and fundamentally broken with full kernel. Let's keep sane defaults, but not make it unreasonable to tweak eaither. Exactly. Thanks for echoing the concern. I suggest what has already been mentioned. Register both timers, but have the sync timer have a higher rating. On AMxxx where there is no sync timer, GPtimer will be used. Technically it's a hack just from clock precision point of view but I don't mind this. For those who want to use GPtimer, they can boot using clocksource= to override the default. Sounds good to me. Santosh is right, GPtimer will not work on a PM enabled kernel, but there are lots of ways to use the cmdline to get a non-working kernel, so that's OK by me. Let's just ensure that the boot-defaults are sane. Absolutely. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/3] spi: omap2-mcspi: driver updates
Hi Grant On Tue, Apr 3, 2012 at 1:10 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Sat, 31 Mar 2012 17:06:55 +0530, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following cleanups - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series - The tmp variable is used to write this can be optimised as it is not needed if the value is directly written. Acknowledge Tarun for the suggestion. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi_next Rebased to Grant's spi/next branch. Merged, thanks. Thanks , BTW, it's easier to pull if you put the branch after the git URL (I can cut and paste all at once): git://gitorious.org/linus-tree/linus-tree.git spi_next git request-pull can be your friend here. OK good idea will do that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
