* [PATCH V3 01/13] ARM: OMAP: Add DMTIMER definitions for posted mode
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
clock-source) the posted mode configuration of the timers is used. To allow
the compiler to optimise the functions for configuring and reading the system
timers, the posted flag variable is hard-coded with the value 1. To make it
clear that posted mode is being used add some definitions so that it is more
readable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/timer.c | 17 ++++++++++-------
arch/arm/plat-omap/include/plat/dmtimer.h | 4 ++++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 684d2fc..a135d28 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -108,7 +108,7 @@ static int omap2_gp_timer_set_next_event(unsigned long cycles,
struct clock_event_device *evt)
{
__omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_ST,
- 0xffffffff - cycles, 1);
+ 0xffffffff - cycles, OMAP_TIMER_POSTED);
return 0;
}
@@ -118,7 +118,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
{
u32 period;
- __omap_dm_timer_stop(&clkev, 1, clkev.rate);
+ __omap_dm_timer_stop(&clkev, OMAP_TIMER_POSTED, clkev.rate);
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
@@ -126,10 +126,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
period -= 1;
/* Looks like we need to first set the load value separately */
__omap_dm_timer_write(&clkev, OMAP_TIMER_LOAD_REG,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
__omap_dm_timer_load_start(&clkev,
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
- 0xffffffff - period, 1);
+ 0xffffffff - period, OMAP_TIMER_POSTED);
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
@@ -359,7 +359,8 @@ static bool use_gptimer_clksrc;
*/
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
- return (cycle_t)__omap_dm_timer_read_counter(&clksrc, 1);
+ return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
}
static struct clocksource clocksource_gpt = {
@@ -373,7 +374,8 @@ static struct clocksource clocksource_gpt = {
static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
- return __omap_dm_timer_read_counter(&clksrc, 1);
+ return __omap_dm_timer_read_counter(&clksrc,
+ OMAP_TIMER_POSTED);
return 0;
}
@@ -455,7 +457,8 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
- OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
+ OMAP_TIMER_POSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index f8943c8..1bee0ac 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,6 +55,10 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW 0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE 0x02
+/* posted mode types */
+#define OMAP_TIMER_NONPOSTED 0x00
+#define OMAP_TIMER_POSTED 0x01
+
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x80000000
#define OMAP_TIMER_ALWON 0x40000000
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 02/13] ARM: OMAP3+: Implement timer workaround for errata i103 and i767
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)
Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.
GPTimer non-posted synchronization mode is not impacted by this
limitation.
Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is active
Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.
Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.
For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.
__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);
Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.
Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/timer.c | 49 ++++++++++++++++++++++-----
arch/arm/plat-omap/dmtimer.c | 3 +-
arch/arm/plat-omap/include/plat/dmtimer.h | 52 +++++++++++++++++++++++++++--
3 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a135d28..63229c5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -222,10 +222,24 @@ void __init omap_dmtimer_init(void)
}
}
+/**
+ * omap_dm_timer_get_errata - get errata flags for a timer
+ *
+ * Get the timer errata flags that are specific to the OMAP device being used.
+ */
+u32 __init omap_dm_timer_get_errata(void)
+{
+ if (cpu_is_omap24xx())
+ return 0;
+
+ return OMAP_TIMER_ERRATA_I103_I767;
+}
+
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int gptimer_id,
const char *fck_source,
- const char *property)
+ const char *property,
+ int posted)
{
char name[10]; /* 10 = sizeof("gptXX_Xck0") */
const char *oh_name;
@@ -311,10 +325,15 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
- timer->posted = 1;
- timer->rate = clk_get_rate(timer->fclk);
+ if (posted)
+ __omap_dm_timer_enable_posted(timer);
+
+ /* Check that the intended posted configuration matches the actual */
+ if (posted != timer->posted)
+ return -EINVAL;
+ timer->rate = clk_get_rate(timer->fclk);
timer->reserved = 1;
return res;
@@ -326,7 +345,17 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property);
+ clkev.errata = omap_dm_timer_get_errata();
+
+ /*
+ * For clock-event timers we never read the timer counter and
+ * so we are not impacted by errata i103 and i767. Therefore,
+ * we can safely ignore this errata for clock-event timers.
+ */
+ __omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
+
+ res = omap_dm_timer_init_one(&clkev, gptimer_id, fck_source, property,
+ OMAP_TIMER_POSTED);
BUG_ON(res);
omap2_gp_timer_irq.dev_id = &clkev;
@@ -360,7 +389,7 @@ static bool use_gptimer_clksrc;
static cycle_t clocksource_read_cycles(struct clocksource *cs)
{
return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
}
static struct clocksource clocksource_gpt = {
@@ -375,7 +404,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
{
if (clksrc.reserved)
return __omap_dm_timer_read_counter(&clksrc,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
return 0;
}
@@ -453,12 +482,15 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
{
int res;
- res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL);
+ clksrc.errata = omap_dm_timer_get_errata();
+
+ res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source, NULL,
+ OMAP_TIMER_NONPOSTED);
BUG_ON(res);
__omap_dm_timer_load_start(&clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
- OMAP_TIMER_POSTED);
+ OMAP_TIMER_NONPOSTED);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
@@ -696,6 +728,7 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
if (timer_dev_attr)
pdata->timer_capability = timer_dev_attr->timer_capability;
+ pdata->timer_errata = omap_dm_timer_get_errata();
pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 9dca23e..381a612 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -128,8 +128,8 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
}
__omap_dm_timer_reset(timer, 0, 0);
+ __omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);
- timer->posted = 1;
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
@@ -797,6 +797,7 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
timer->capability |= OMAP_TIMER_SECURE;
} else {
timer->id = pdev->id;
+ timer->errata = pdata->timer_errata;
timer->capability = pdata->timer_capability;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
timer->get_context_loss_count = pdata->get_context_loss_count;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 1bee0ac..ac16f1e 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -66,6 +66,16 @@
#define OMAP_TIMER_NEEDS_RESET 0x10000000
#define OMAP_TIMER_HAS_DSP_IRQ 0x08000000
+/*
+ * timer errata flags
+ *
+ * Errata i103/i767 impacts all OMAP3/4/5 devices including AM33xx. This
+ * errata prevents us from using posted mode on these devices, unless the
+ * timer counter register is never read. For more details please refer to
+ * the OMAP3/4/5 errata documents.
+ */
+#define OMAP_TIMER_ERRATA_I103_I767 0x80000000
+
struct omap_timer_capability_dev_attr {
u32 timer_capability;
};
@@ -97,6 +107,7 @@ struct timer_regs {
struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
+ u32 timer_errata;
u32 timer_capability;
int (*get_context_loss_count)(struct device *);
};
@@ -273,6 +284,7 @@ struct omap_dm_timer {
int ctx_loss_count;
int revision;
u32 capability;
+ u32 errata;
struct platform_device *pdev;
struct list_head node;
};
@@ -344,10 +356,46 @@ static inline void __omap_dm_timer_reset(struct omap_dm_timer *timer,
l |= 1 << 2;
__raw_writel(l, timer->io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+}
+
+/*
+ * __omap_dm_timer_enable_posted - enables write posted mode
+ * @timer: pointer to timer instance handle
+ *
+ * Enables the write posted mode for the timer. When posted mode is enabled
+ * writes to certain timer registers are immediately acknowledged by the
+ * internal bus and hence prevents stalling the CPU waiting for the write to
+ * complete. Enabling this feature can improve performance for writing to the
+ * timer registers.
+ */
+static inline void __omap_dm_timer_enable_posted(struct omap_dm_timer *timer)
+{
+ if (timer->posted)
+ return;
+
+ if (timer->errata & OMAP_TIMER_ERRATA_I103_I767)
+ return;
- /* Match hardware reset default of posted mode */
__omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
- OMAP_TIMER_CTRL_POSTED, 0);
+ OMAP_TIMER_CTRL_POSTED, 0);
+ timer->context.tsicr = OMAP_TIMER_CTRL_POSTED;
+ timer->posted = OMAP_TIMER_POSTED;
+}
+
+/**
+ * __omap_dm_timer_override_errata - override errata flags for a timer
+ * @timer: pointer to timer handle
+ * @errata: errata flags to be ignored
+ *
+ * For a given timer, override a timer errata by clearing the flags
+ * specified by the errata argument. A specific erratum should only be
+ * overridden for a timer if the timer is used in such a way the erratum
+ * has no impact.
+ */
+static inline void __omap_dm_timer_override_errata(struct omap_dm_timer *timer,
+ u32 errata)
+{
+ timer->errata &= ~errata;
}
static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 03/13] ARM: OMAP: Fix timer posted mode support
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Currently the dmtimer posted mode is being enabled when the function
omap_dm_timer_enable_posted() is called. This function is only being called
for OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the "timer->posted" variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.
This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which was before the
omap_dm_timer_enable_posted() function was introduced. Although this is a
regression from the original code it only impacts performance and so is not
needed for stable.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 381a612..10ec31b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,21 +121,16 @@ static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- omap_dm_timer_enable(timer);
if (timer->pdev->id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
__omap_dm_timer_reset(timer, 0, 0);
- __omap_dm_timer_enable_posted(timer);
- omap_dm_timer_disable(timer);
}
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- int ret;
-
/*
* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
* do not call clk_get() for these devices.
@@ -149,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
}
}
+ omap_dm_timer_enable(timer);
+
if (timer->capability & OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
- ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ __omap_dm_timer_enable_posted(timer);
+ omap_dm_timer_disable(timer);
- timer->posted = 1;
- return ret;
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
}
static inline u32 omap_dm_timer_reserved_systimer(int id)
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 04/13] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.
For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index abe66ce..fac2550 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -153,28 +153,13 @@ static struct omap_hwmod omap3xxx_debugss_hwmod = {
};
/* timer class */
-static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
- .rev_offs = 0x0000,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
- SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields = &omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
- .name = "timer",
- .sysc = &omap3xxx_timer_1ms_sysc,
-};
-
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.rev_offs = 0x0000,
.sysc_offs = 0x0010,
.syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
- SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
};
@@ -224,7 +209,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
},
.dev_attr = &capability_alwon_dev_attr,
- .class = &omap3xxx_timer_1ms_hwmod_class,
+ .class = &omap3xxx_timer_hwmod_class,
};
/* timer2 */
@@ -241,7 +226,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .class = &omap3xxx_timer_1ms_hwmod_class,
+ .class = &omap3xxx_timer_hwmod_class,
};
/* timer3 */
@@ -383,7 +368,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
},
.dev_attr = &capability_pwm_dev_attr,
- .class = &omap3xxx_timer_1ms_hwmod_class,
+ .class = &omap3xxx_timer_hwmod_class,
};
/* timer11 */
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 05/13] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a0116d0..067fd0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -58,7 +58,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index fac2550..fcce693 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -159,7 +159,8 @@ static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.syss_offs = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
- SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+ SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields = &omap_hwmod_sysc_type1,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 06/13] ARM: OMAP2+: Don't use __omap_dm_timer_reset()
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
timer OCP_CFG register. The name of the function is mis-leading because this
function does not actually perform a reset of the timer.
For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
have the fields clock-activity, wakeup-enable and auto-idle and so this
function could configure the OCP_CFG register incorrectly.
Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
register for timers that have this field. Commit 0f0d080 (ARM: OMAP: DMTimer:
Use posted mode) configures the clock-activity field to keep the f-clk enabled
so that the wake-up capability is enabled. Therefore, add the appropriate flags
to the timer HWMOD structures to configure this field in the same way.
For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +++++++++++++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 ++++
arch/arm/mach-omap2/timer.c | 1 -
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 067fd0a..0db8f45 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -60,6 +60,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc = {
SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields = &omap_hwmod_sysc_type1,
};
@@ -268,6 +269,7 @@ struct omap_hwmod omap2xxx_timer1_hwmod = {
},
.dev_attr = &capability_alwon_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer2 */
@@ -286,6 +288,7 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
},
},
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer3 */
@@ -304,6 +307,7 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
},
},
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer4 */
@@ -322,6 +326,7 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
},
},
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer5 */
@@ -341,6 +346,7 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer6 */
@@ -360,6 +366,7 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer7 */
@@ -379,6 +386,7 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer8 */
@@ -398,6 +406,7 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer9 */
@@ -417,6 +426,7 @@ struct omap_hwmod omap2xxx_timer9_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer10 */
@@ -436,6 +446,7 @@ struct omap_hwmod omap2xxx_timer10_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer11 */
@@ -455,6 +466,7 @@ struct omap_hwmod omap2xxx_timer11_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer12 */
@@ -474,6 +486,7 @@ struct omap_hwmod omap2xxx_timer12_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap2xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* wd_timer2 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index fcce693..addc1c2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -162,6 +162,7 @@ static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields = &omap_hwmod_sysc_type1,
};
@@ -211,6 +212,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
.dev_attr = &capability_alwon_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer2 */
@@ -228,6 +230,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
},
},
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer3 */
@@ -245,6 +248,7 @@ static struct omap_hwmod omap3xxx_timer3_hwmod = {
},
},
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer4 */
@@ -262,6 +266,7 @@ static struct omap_hwmod omap3xxx_timer4_hwmod = {
},
},
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer5 */
@@ -280,6 +285,7 @@ static struct omap_hwmod omap3xxx_timer5_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer6 */
@@ -298,6 +304,7 @@ static struct omap_hwmod omap3xxx_timer6_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer7 */
@@ -316,6 +323,7 @@ static struct omap_hwmod omap3xxx_timer7_hwmod = {
},
.dev_attr = &capability_dsp_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer8 */
@@ -334,6 +342,7 @@ static struct omap_hwmod omap3xxx_timer8_hwmod = {
},
.dev_attr = &capability_dsp_pwm_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer9 */
@@ -352,6 +361,7 @@ static struct omap_hwmod omap3xxx_timer9_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer10 */
@@ -370,6 +380,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer11 */
@@ -388,6 +399,7 @@ static struct omap_hwmod omap3xxx_timer11_hwmod = {
},
.dev_attr = &capability_pwm_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/* timer12 */
@@ -411,6 +423,7 @@ static struct omap_hwmod omap3xxx_timer12_hwmod = {
},
.dev_attr = &capability_secure_dev_attr,
.class = &omap3xxx_timer_hwmod_class,
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2b4bd21..8e1d84c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3075,6 +3075,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = {
SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
SYSS_HAS_RESET_STATUS),
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .clockact = CLOCKACT_TEST_ICLK,
.sysc_fields = &omap_hwmod_sysc_type1,
};
@@ -3128,6 +3129,7 @@ static struct omap_hwmod omap44xx_timer1_hwmod = {
.name = "timer1",
.class = &omap44xx_timer_1ms_hwmod_class,
.clkdm_name = "l4_wkup_clkdm",
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
.mpu_irqs = omap44xx_timer1_irqs,
.main_clk = "timer1_fck",
.prcm = {
@@ -3150,6 +3152,7 @@ static struct omap_hwmod omap44xx_timer2_hwmod = {
.name = "timer2",
.class = &omap44xx_timer_1ms_hwmod_class,
.clkdm_name = "l4_per_clkdm",
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
.mpu_irqs = omap44xx_timer2_irqs,
.main_clk = "timer2_fck",
.prcm = {
@@ -3324,6 +3327,7 @@ static struct omap_hwmod omap44xx_timer10_hwmod = {
.name = "timer10",
.class = &omap44xx_timer_1ms_hwmod_class,
.clkdm_name = "l4_per_clkdm",
+ .flags = HWMOD_SET_DEFAULT_CLOCKACT,
.mpu_irqs = omap44xx_timer10_irqs,
.main_clk = "timer10_fck",
.prcm = {
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 63229c5..19765bd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -324,7 +324,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
}
}
__omap_dm_timer_init_regs(timer);
- __omap_dm_timer_reset(timer, 1, 1);
if (posted)
__omap_dm_timer_enable_posted(timer);
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 07/13] ARM: OMAP: Fix dmtimer reset for timer1
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
In commit e32f7ec2 (ARM: OMAP: Fix 32 kHz timer and modify GP timer to use GPT1)
a fix was added to prevent timer1 being reset in the function
omap_dm_timer_reset() because timer1 was being used as the system timer for
OMAP2 devices. Although timer1 is still used by most OMAP2+ devices as a system
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 10ec31b..d4f9541 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -121,11 +121,8 @@ static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
- if (timer->pdev->id != 1) {
- omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
- omap_dm_timer_wait_for_reset(timer);
- }
-
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
+ omap_dm_timer_wait_for_reset(timer);
__omap_dm_timer_reset(timer, 0, 0);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 08/13] ARM: OMAP: Don't restore of DMTIMER TISTAT register
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 3 ---
arch/arm/plat-omap/include/plat/dmtimer.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index d4f9541..320d103 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,9 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- if (timer->revision == 1)
- __raw_writel(timer->context.tistat, timer->sys_stat);
-
__raw_writel(timer->context.tisr, timer->irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer->context.twer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index ac16f1e..2f9fd1d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tistat;
u32 tisr;
u32 tier;
u32 twer;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 09/13] ARM: OMAP: Don't restore DMTIMER interrupt status register
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Restoring the timer interrupt status is not possible because writing a 1 to any
bit in the register clears that bit if set and writing a 0 has no affect.
Furthermore, if an interrupt is pending when someone attempts to disable a
timer, the timer will fail to transition to the idle state and hence it's
context will not be lost. Users should take care to service all interrupts
before disabling the timer.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 5 +----
arch/arm/plat-omap/include/plat/dmtimer.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 320d103..f0a3c4c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -83,7 +83,6 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg,
static void omap_timer_restore_context(struct omap_dm_timer *timer)
{
- __raw_writel(timer->context.tisr, timer->irq_stat);
omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG,
timer->context.twer);
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG,
@@ -440,7 +439,6 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
*/
timer->context.tclr =
omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- timer->context.tisr = __raw_readl(timer->irq_stat);
omap_dm_timer_disable(timer);
return 0;
}
@@ -684,8 +682,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
return -EINVAL;
__omap_dm_timer_write_status(timer, value);
- /* Save the context */
- timer->context.tisr = value;
+
return 0;
}
EXPORT_SYMBOL_GPL(omap_dm_timer_write_status);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 2f9fd1d..0c07e37 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -84,7 +84,6 @@ struct omap_dm_timer;
struct timer_regs {
u32 tidr;
- u32 tisr;
u32 tier;
u32 twer;
u32 tclr;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 10/13] ARM: OMAP: Fix spurious interrupts when using timer match feature
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
The OMAP DMTIMERs can generate an interrupt when the timer counter value
matches the value stored in the timer's match register. When using this
feature spurious interrupts were seen, because the compare logic is being
enabled before the match value is loaded and according to the documentation
the match value must be loaded before the compare logic is enable.
The reset value for the timer counter and match registers is 0 and hence,
by enabling the compare logic before the actual match value is loaded a
spurious interrupt can be generated as the reset values match.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index f0a3c4c..a38e896 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -584,8 +584,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
l |= OMAP_TIMER_CTRL_CE;
else
l &= ~OMAP_TIMER_CTRL_CE;
- omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
omap_dm_timer_write_reg(timer, OMAP_TIMER_MATCH_REG, match);
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
/* Save the context */
timer->context.tclr = l;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 11/13] ARM: OMAP: Add dmtimer interrupt disable function
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because the same interrupt
enable register is used to disable interrupts. However, some timer instances
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
This change is required for OMAP4+ devices. For OMAP4, all timers apart from 1,
2 and 10 need this function and for OMAP5 all timers need this function.
Please note that the interrupt disable function has been written so that it
can be used by all OMAP devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 31 +++++++++++++++++++++++++++++
arch/arm/plat-omap/include/plat/dmtimer.h | 3 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index a38e896..b4e6634 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -661,6 +661,37 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
}
EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_enable);
+/**
+ * omap_dm_timer_set_int_disable - disable timer interrupts
+ * @timer: pointer to timer handle
+ * @mask: bit mask of interrupts to be disabled
+ *
+ * Disables the specified timer interrupts for a timer.
+ */
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
+{
+ u32 l = mask;
+
+ if (unlikely(!timer))
+ return -EINVAL;
+
+ omap_dm_timer_enable(timer);
+
+ if (timer->revision == 1)
+ l = __raw_readl(timer->irq_ena) & ~mask;
+
+ __raw_writel(l, timer->irq_dis);
+ l = omap_dm_timer_read_reg(timer, OMAP_TIMER_WAKEUP_EN_REG) & ~mask;
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_WAKEUP_EN_REG, l);
+
+ /* Save the context */
+ timer->context.tier &= ~mask;
+ timer->context.twer &= ~mask;
+ omap_dm_timer_disable(timer);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_dm_timer_set_int_disable);
+
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
{
unsigned int l;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 0c07e37..769efb6 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -135,6 +135,7 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, int toggle, i
int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int value);
+int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value);
@@ -321,7 +322,7 @@ static inline void __omap_dm_timer_init_regs(struct omap_dm_timer *timer)
OMAP_TIMER_V1_SYS_STAT_OFFSET;
timer->irq_stat = timer->io_base + OMAP_TIMER_V1_STAT_OFFSET;
timer->irq_ena = timer->io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
- timer->irq_dis = NULL;
+ timer->irq_dis = timer->io_base + OMAP_TIMER_V1_INT_EN_OFFSET;
timer->pend = timer->io_base + _OMAP_TIMER_WRITE_PEND_OFFSET;
timer->func_base = timer->io_base;
} else {
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 12/13] ARM: OMAP: Remove unnecessary call to clk_get()
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
Whenever we call the function omap_dm_timer_set_source() to set the clock
source of a dmtimer we look-up the dmtimer functional clock source by
calling clk_get(). This is not necessary because on requesting a dmtimer
we look-up the functional clock source and store it in the omap_dm_timer
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/dmtimer.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index b4e6634..305faf5 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -448,7 +448,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
{
int ret;
char *parent_name = NULL;
- struct clk *fclk, *parent;
+ struct clk *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -467,11 +467,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
if (pdata && pdata->set_timer_src)
return pdata->set_timer_src(timer->pdev, source);
- fclk = clk_get(&timer->pdev->dev, "fck");
- if (IS_ERR_OR_NULL(fclk)) {
- pr_err("%s: fck not found\n", __func__);
+ if (!timer->fclk)
return -EINVAL;
- }
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
@@ -490,18 +487,15 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
parent = clk_get(&timer->pdev->dev, parent_name);
if (IS_ERR_OR_NULL(parent)) {
pr_err("%s: %s not found\n", __func__, parent_name);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
- ret = clk_set_parent(fclk, parent);
+ ret = clk_set_parent(timer->fclk, parent);
if (IS_ERR_VALUE(ret))
pr_err("%s: failed to set %s as parent\n", __func__,
parent_name);
clk_put(parent);
-out:
- clk_put(fclk);
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 13/13] ARM: OMAP: Remove __omap_dm_timer_set_source function
From: Jon Hunter @ 2012-11-12 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352744444-2633-1-git-send-email-jon-hunter@ti.com>
The __omap_dm_timer_set_source() function is only used by the system timer
(clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
remove this code from the dmtimer driver and move it to the system timer
code for OMAP2+ devices.
The current __omap_dm_timer_set_source() function calls clk_disable() before
calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
omap_hwmod_enable() to after the call to clk_set_parent() in
omap_dm_timer_init_one().
The function omap_hwmod_setup_one() will enable the timers functional clock
and therefore increment the use-count of the functional clock to 1.
clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
clk_disable() before calling clk_set_parent() to decrement the use-count.
Hence, avoid these extra calls to disable and enable the functional clock by
moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
clk_set_parent().
We can also remove the delay from the __omap_dm_timer_set_source() function
because enabling the clock will now be handled via the HWMOD framework by
calling omap_hwmod_setup_one(). Therefore, by moving the calls to
omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
clk_set_parent().
It should be safe to move these hwmod calls to later in the
omap_dm_timer_init_one() because other calls to the hwmod layer that occur
before are just requesting resource information.
Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
with the following configurations:
1. CONFIG_OMAP_32K_TIMER=y
2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer"
3. CONFIG_OMAP_32K_TIMER not set
4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer"
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/timer.c | 9 ++++-----
arch/arm/plat-omap/dmtimer.c | 1 +
arch/arm/plat-omap/include/plat/dmtimer.h | 19 -------------------
3 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 19765bd..099e406 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -274,9 +274,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
oh_name = name;
}
- omap_hwmod_setup_one(oh_name);
oh = omap_hwmod_lookup(oh_name);
-
if (!oh)
return -ENODEV;
@@ -306,8 +304,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
if (IS_ERR(timer->fclk))
return -ENODEV;
- omap_hwmod_enable(oh);
-
/* FIXME: Need to remove hard-coded test on timer ID */
if (gptimer_id != 12) {
struct clk *src;
@@ -316,13 +312,16 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
if (IS_ERR(src)) {
res = -EINVAL;
} else {
- res = __omap_dm_timer_set_source(timer->fclk, src);
+ res = clk_set_parent(timer->fclk, src);
if (IS_ERR_VALUE(res))
pr_warn("%s: %s cannot set source\n",
__func__, oh->name);
clk_put(src);
}
}
+
+ omap_hwmod_setup_one(oh_name);
+ omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
if (posted)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 305faf5..9deeb30 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -35,6 +35,7 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include <linux/clk.h>
#include <linux/module.h>
#include <linux/io.h>
#include <linux/device.h>
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h
index 769efb6..05a36e1 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -32,7 +32,6 @@
* 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/platform_device.h>
@@ -397,24 +396,6 @@ static inline void __omap_dm_timer_override_errata(struct omap_dm_timer *timer,
timer->errata &= ~errata;
}
-static inline int __omap_dm_timer_set_source(struct clk *timer_fck,
- struct clk *parent)
-{
- int ret;
-
- clk_disable(timer_fck);
- ret = clk_set_parent(timer_fck, parent);
- clk_enable(timer_fck);
-
- /*
- * When the functional clock disappears, too quick writes seem
- * to cause an abort. XXX Is this still necessary?
- */
- __delay(300000);
-
- return ret;
-}
-
static inline void __omap_dm_timer_stop(struct omap_dm_timer *timer,
int posted, unsigned long rate)
{
--
1.7.9.5
^ permalink raw reply related
* common clk fixes for 3.7-rc6
From: Mike Turquette @ 2012-11-12 18:33 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:
Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)
are available in the git repository at:
git://git.linaro.org/people/mturquette/linux.git tags/clk-fixes-for-linus
for you to fetch changes up to 3d930678034e756d0960d214412d344772b21109:
clk: ux500: Register slimbus clock lookups for u8500 (2012-11-12 10:20:23 -0800)
----------------------------------------------------------------
Missing clkdev entries are causing regressions on the U8500 platform.
This pull request contains those missing clkdev entries which are needed
to boot that platform.
----------------------------------------------------------------
Ulf Hansson (5):
clk: ux500: Register i2c clock lookups for u8500
clk: ux500: Register ssp clock lookups for u8500
clk: ux500: Register msp clock lookups for u8500
clk: ux500: Update rtc clock lookup for u8500
clk: ux500: Register slimbus clock lookups for u8500
drivers/clk/ux500/u8500_clk.c | 50 +++++++++++++++++++++++++++++++++++++----
1 file changed, 46 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 0/5] clk: ux500: Add clock lookups for u8500
From: Mike Turquette @ 2012-11-12 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda4iFYga=AKn_ZHGmQSnCW9-DxmYF25HnBA1iuZ5PD3AQ@mail.gmail.com>
Quoting Linus Walleij (2012-11-11 10:42:59)
> On Sat, Nov 10, 2012 at 2:07 AM, Mike Turquette <mturquette@ti.com> wrote:
> > Quoting Lee Jones (2012-10-25 00:51:38)
> >> On Mon, 22 Oct 2012, Ulf Hansson wrote:
> >>
> >> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >> >
> >> > Step by step, clock lookups for u8500 are being added in this set
> >> > of patches.
> >> >
> >> > These patches will require additional patches for sound/soc/ux500/
> >> > driver as well as drivers/i2c/busses/i2c-nomadik driver to prevent
> >> > the boot for ux500 from break. Those patches are being merged through
> >> > separate trees.
> >> >
> >> > Ulf Hansson (5):
> >> > clk: ux500: Register i2c clock lookups for u8500
> >> > clk: ux500: Register ssp clock lookups for u8500
> >> > clk: ux500: Register msp clock lookups for u8500
> >> > clk: ux500: Update rtc clock lookup for u8500
> >> > clk: ux500: Register slimbus clock lookups for u8500
> >>
> >> Acked-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> Can I also mention that these need to go into the -rcs at the
> >> earliest opportunity please, as it is preventing ~50% of the
> >> devices from functioning on all of the ST-Ericsson development
> >> boards.
> >>
> >> This is a massive blocker for us!
> >>
> >
> > I've taken these patches into clk-next. Do you need them in as a late
> > fix in the 3.7 cycle or is your urgent need only for 3.8 development?
>
> It is regressing the above drivers (i2c, ssp, etc) so they need to
> go into v3.7-rc:s...
>
Pull request sent for the fixes. I'll remove these from clk-next once
they are merged into 3.7-rc6.
Regards,
Mike
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH 0/2] clk: ux500: Make mtu driver use apb_pclock
From: Mike Turquette @ 2012-11-12 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbGnvywcQWRN9v_=1nkmaqgJK92Zs1S5HSLgppa49bQqw@mail.gmail.com>
Quoting Linus Walleij (2012-11-11 10:47:46)
> On Sat, Nov 10, 2012 at 2:24 AM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Linus Walleij (2012-10-24 10:25:26)
> >> On Wed, Oct 24, 2012 at 2:13 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> >>
> >> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >> >
> >> > The apb clock was before the "common" clock driver for ux500 was merged,
> >> > handled internally by the clock driver. Now this clock needs to be managed
> >> > from the mtu driver as a separate clock.
> >> >
> >> > This patches is based in 3.7 rc2.
> >> >
> >> > It is important the "ARM nomadik patch" is merged together with the
> >> > clock patch to not break boot. Therefore I suggest this series to go
> >> > through Mike Turquettes clock tree.
> >>
> >> OK go ahead:
> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > I've taken these into clk-next. While the patches are trivial I'd still
> > prefer a changelog in the future. For instance, it would be nice to
> > explain why removing the block comment is OK in the first patch.
>
> So there may be some collision in linux-next due to this,
> because I've moved the nomadik timer to
> drivers/clksrc and deleted the entire plat-nomadik
> directory.
>
> I don't know quite how ingenious git is in detecting
> patches on moved files, but if it's causing trouble
> I think it's better if you could ACK them and we
> could reubmit them to ARM SoC on the multiplatform
> branch. i.e. this one:
> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=shortlog;h=refs/heads/next/multiplatform
>
Those patches have my ACK. Do you want to wait to see if something goes
boom or would you rather I drop them from clk-next preemptively?
Regards,
Mike
> Yours,
> Linus Walleij
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/6] Move rest of omap-iommu to live in drivers/iommu
From: Omar Ramirez Luna @ 2012-11-12 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbYR8UMyDjySJLRC0tEbJO3FaFgjWxceNwMyVdMgEgwPig@mail.gmail.com>
Hi,
On 11 November 2012 03:39, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren <tony@atomide.com> wrote:
>> We need to move the iommu code to live under drivers
>> for arm common zImage support.
>
> For the iommu changes in the entire series:
>
> Acked-by: Ohad Ben-Cohen <ohad@wizery.com>
>
> Joerg, it might relieve some pain if this will go through Tony's tree,
> as there are some OMAP platform iommu changes coming in from Omar as
> well (part of which might have already been merged in the omap
> branches). Hope it's ok with both of you guys?
>
> Omar, do you still have any iommu changes coming in ?
Yes, I have the hwmod and runtime pm changes for iommu, I was waiting
for Tony to publish a branch with these changes to submit (as per
Tony's suggestion), but I already have the patches rebased onto these.
I will submit them.
Cheers,
Omar
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Anton Vorontsov @ 2012-11-12 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112181947.GS24583@lunn.ch>
On Mon, Nov 12, 2012 at 07:19:47PM +0100, Andrew Lunn wrote:
[..]
> > >>> Given appropriate devicetree bindings, this driver registers a
> > >>> pm_power_off function to set a GPIO line high/low to power down
> > >>> your board.
> >
> > >>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
> > >>
> > >>> +Required properties:
> > >>> +- compatible : should be "gpio-poweroff".
> > >>> +- gpios : The GPIO to set high/low, see "gpios property" in
> > >>> + Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
> > >>> + low to power down the board set it to "Active Low", otherwise set
> > >>> + gpio to "Active High".
> > >>
> > >> Unfortunately, not all GPIO bindings support active high/low flags in
> > >> the GPIO specifier. As such, the flags there are basically useless.
> > >> Other bindings (e.g. IIRC the fixed-regulator binding) have added a
> > >> separate active-high property to indicate the GPIO polarity. This
> > >> binding should probably follow suite.
Should the gpio driver fix its bindings then?.. Polarity is a quite
generic concept of a GPIO, and flags are there for a reason. I'd rather
prefer having
stuff-gpios = <0 0
1 0
2 1
3 0>;
Rather than
stuff-gpios = <0 1 2 3>;
stuff-polarity-gpio-map = <0 0 1 0>;
The first scheme existed like for years already. Has it been discussed
that it is no longer preferred?
> > > Humm, so are you saying of_get_named_gpio_flags() is deprecated?
> >
> > I don't know if it's deprecated, but it's certainly not useful in
> > generic code.
>
> Hi Linus, Anton
>
> How do you see this?
>
> I'm happy to implement an enable-active-high property, but it seems to
> go against the purpose of of_get_named_gpio_flags(). Is that function
> deprecated?
Never heard of any deprecation, and I disagree that it is "not useful in
generic code". :)
Thanks,
Anton.
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Stephen Warren @ 2012-11-12 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112184340.GA15643@lizard>
On 11/12/2012 11:43 AM, Anton Vorontsov wrote:
> On Mon, Nov 12, 2012 at 07:19:47PM +0100, Andrew Lunn wrote:
> [..]
>>>>>> Given appropriate devicetree bindings, this driver registers a
>>>>>> pm_power_off function to set a GPIO line high/low to power down
>>>>>> your board.
>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
>>>>>
>>>>>> +Required properties:
>>>>>> +- compatible : should be "gpio-poweroff".
>>>>>> +- gpios : The GPIO to set high/low, see "gpios property" in
>>>>>> + Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be
>>>>>> + low to power down the board set it to "Active Low", otherwise set
>>>>>> + gpio to "Active High".
>>>>>
>>>>> Unfortunately, not all GPIO bindings support active high/low flags in
>>>>> the GPIO specifier. As such, the flags there are basically useless.
>>>>> Other bindings (e.g. IIRC the fixed-regulator binding) have added a
>>>>> separate active-high property to indicate the GPIO polarity. This
>>>>> binding should probably follow suite.
>
> Should the gpio driver fix its bindings then?.. Polarity is a quite
> generic concept of a GPIO, and flags are there for a reason. I'd rather
> prefer having
There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
and unfortunately, some of the GPIO binding authors chose not to include
any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
there are probably more).
> stuff-gpios = <0 0
> 1 0
> 2 1
> 3 0>;
>
> Rather than
>
> stuff-gpios = <0 1 2 3>;
> stuff-polarity-gpio-map = <0 0 1 0>;
>
> The first scheme existed like for years already. Has it been discussed
> that it is no longer preferred?
>
>>>> Humm, so are you saying of_get_named_gpio_flags() is deprecated?
>>>
>>> I don't know if it's deprecated, but it's certainly not useful in
>>> generic code.
>>
>> Hi Linus, Anton
>>
>> How do you see this?
>>
>> I'm happy to implement an enable-active-high property, but it seems to
>> go against the purpose of of_get_named_gpio_flags(). Is that function
>> deprecated?
>
> Never heard of any deprecation, and I disagree that it is "not useful in
> generic code". :)
Put more specifically, I meant: It would be useful to have such a
feature. However, since such a feature doesn't exist in all cases, it's
not possible to rely on the feature, and hence trying to isn't useful.
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-12 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509F6CE3.50806@compulab.co.il>
On 11/11/2012 03:16 AM, Igor Grinberg wrote:
> On 11/08/12 18:20, Tony Lindgren wrote:
>> * Igor Grinberg <grinberg@compulab.co.il> [121107 23:15]:
>>> On 11/07/12 19:33, Tony Lindgren wrote:
>>>>
>>>> I think this should be the default for the timers as that counter
>>>> does not stop during deeper idle states.
>>>
>>> Well, it is the default as you can see from the patch.
>>> The problem is that for boards that for some reason do not have
>>> the 32k wired and rely on MPU/GP timer source, the default will not work
>>> and currently there is no way for board to specify which timer source
>>> it can use.
>>
>> Yes. I was just wondering if we can avoid patching all the board
>> files by doing it the other way around by introducing a new
>> omap_gp_timer rather than renaming all the existing ones?
>
> Is the renaming that bad? One line per machine_desc structure?
> Of course we can skip the renaming, but then it will be less consistent
> and will not reflect the actual timer source used.
> I tried to make it flexible as much as possible and self explanatory.
> So above are my considerations, but at this point in time I don't really
> care if we rename them or just add a new one, but we have to get rid of
> the ugly fall back.
I am not sure if you guys disagree, but does it make sense to start
thinking about this with regard to device-tree? With device-tree all the
boards files will become obsolete and so we need to be able to handle
this during boot time and not compile time.
>>
>>> We have discussed this in San Diego (remember?) and you actually proposed
>>> this way as a solution. Well, may be I took it a bit further than you
>>> thought, but this is because the board code cannot know which timer source
>>> should be used at runtime and the fall back described below, does not work.
>>
>> Yes thanks I agree we should get rid of that Kconfig option for sure.
>>
>>>>> --- a/arch/arm/mach-omap2/board-2430sdp.c
>>>>> +++ b/arch/arm/mach-omap2/board-2430sdp.c
>>>>> @@ -284,6 +284,6 @@ MACHINE_START(OMAP_2430SDP, "OMAP2430 sdp2430 board")
>>>>> .handle_irq = omap2_intc_handle_irq,
>>>>> .init_machine = omap_2430sdp_init,
>>>>> .init_late = omap2430_init_late,
>>>>> - .timer = &omap2_timer,
>>>>> + .timer = &omap2_sync32k_timer,
>>>>> .restart = omap_prcm_restart,
>>>>> MACHINE_END
>>>>> --- a/arch/arm/mach-omap2/board-3430sdp.c
>>>>> +++ b/arch/arm/mach-omap2/board-3430sdp.c
>>>>> @@ -596,6 +596,6 @@ MACHINE_START(OMAP_3430SDP, "OMAP3430 3430SDP board")
>>>>> .handle_irq = omap3_intc_handle_irq,
>>>>> .init_machine = omap_3430sdp_init,
>>>>> .init_late = omap3430_init_late,
>>>>> - .timer = &omap3_timer,
>>>>> + .timer = &omap3_sync32k_timer,
>>>>> .restart = omap_prcm_restart,
>>>>> MACHINE_END
>>>> ...
>>>>
>>>> Can't we assume that the default timer is omap[234]_sync32k_timer to
>>>> avoid renaming the timer entries in all the board files?
>>>
>>> Hmmm...
>>> How will this work with the macros defining the sys_timer structure?
>>> I would also not want to hide the exact timer used under the default name.
>>
>> Can't you just add a new sys_timer (or a new macro) for GP only setups?
>
> Of course I can... but I tried to create a flexible generic code, so
> no meter how a board will be wired, you just need to specify which timer source
> it uses and be done with it.
If you are concerned about how a board is wired up (if the 32k is
present), then I think that that is best handled via device-tree and we
should query device-tree on boot to see what our options are.
What do you guys think?
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
From: Jon Hunter @ 2012-11-12 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509F8BEF.90008@compulab.co.il>
On 11/11/2012 05:28 AM, Igor Grinberg wrote:
>
>
> On 11/08/12 21:16, Jon Hunter wrote:
>>
>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote:
>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote:
>>>>
>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>>>>
>>>> [snip]
>>>>
>>>>> There is no reliable way to determine which source should be used in runtime
>>>>> for boards that do not have the 32k oscillator wired.
>>>>
>>>> So thinking about this some more and given that we are moving away from
>>>> board files, if a board does not provide a 32kHz clock source, then this
>>>> should be reflected in the device-tree source file for that board.
>>>> Hence, at boot time we should be able to determine if a 32kHz clock
>>>> source can be used.
>>>>
>>>
>>> Let me feed some more thoughts here :)
>>>
>>> The way it is being detected currently is based on timer idle status bit.
>>> I am worried that, this is the only option we have.
>>
>> Why not use device-tree to indicate the presence of a 32k clock source?
>> This seems like a board level configuration and so device-tree seems to
>> be the perfect place for this IMO.
>
> Well, that is what my commit message says...
Sorry, but that was not clear to me from whats in the commit message.
Should we be doing this now instead of adding all these static timer
init functions?
Are there any boards today (supported in the kernel that is), that don't
support a 32k?
If not, then this becomes simpler for the non-DT case and given that
boards such as the AM335x will only support DT boot then we can figure
out how to detect the presence of the 32k for DT only.
Jon
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Anton Vorontsov @ 2012-11-12 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A146E7.2040608@wwwdotorg.org>
On Mon, Nov 12, 2012 at 11:58:47AM -0700, Stephen Warren wrote:
[...]
> >>>>> Unfortunately, not all GPIO bindings support active high/low flags in
> >>>>> the GPIO specifier. As such, the flags there are basically useless.
> >>>>> Other bindings (e.g. IIRC the fixed-regulator binding) have added a
> >>>>> separate active-high property to indicate the GPIO polarity. This
> >>>>> binding should probably follow suite.
> >
> > Should the gpio driver fix its bindings then?.. Polarity is a quite
> > generic concept of a GPIO, and flags are there for a reason. I'd rather
> > prefer having
>
> There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
> and unfortunately, some of the GPIO binding authors chose not to include
> any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
> there are probably more).
They didn't read this? :)
int of_gpio_simple_xlate(struct gpio_chip *gc,
const struct of_phandle_args *gpiospec, u32 *flags)
{
/*
* We're discouraging gpio_cells < 2, since that way you'll have to
* write your own xlate function (that will have to retrive the GPIO
* number and the flags from a single gpio cell -- this is possible,
* but not recommended).
*/
if (gc->of_gpio_n_cells < 2) {
WARN_ON(1);
return -EINVAL;
}
They should have gotten the WARN_ON().
If not, if they do have the second cell, then they still can encode the
flags. Just change the bindings in a backwards-compatible way.
And even if they have just one cell, just as the comment above says, they
still can add the polarity flag -- add it into the gpio number specifier.
0x0001 -- GPIO 1, 0x1001 -- GPIO 1, polarity inverted. In the gpio driver
they have to mask the flags (by implementing their own xlate), of course.
A few "broken" (but fixable) drivers/bindings is not the reason change the
whole concept, or declare a long-standing API as 'not suitable for generic
code'. At least it was meant exactly to be suitable for a generic code. :)
Thanks,
Anton.
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Russell King - ARM Linux @ 2012-11-12 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352495853-9790-1-git-send-email-rob.clark@linaro.org>
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> From: Rob Clark <rob@ti.com>
>
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
NAK.
(I did write a better email explaining all the ins and outs of why this
won't work and why 64-bit get_user isn't possible, but my editor crapped
out and lost all that well written message; I don't fancy typing it all
out again.)
Nevertheless,
int test_ptr(unsigned int **v, unsigned int **p)
{
return get_user(*v, p);
}
produces a warning, and you can't get away from that if you stick 64-bit
support into get_user().
Sorry, 64-bit get_user() is a no-no.
^ permalink raw reply
* OMAP baseline test results for v3.7-rc5
From: Paul Walmsley @ 2012-11-12 19:30 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.7-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc5/20121111081034/
Passing tests
-------------
Boot to userspace (9/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone
PM ret/off, suspend + dynamic idle (2/4): 3730beaglexm, 37xxevm
Failing tests: fixed by posted patches
--------------------------------------
Boot tests:
* 3530ES3 Beagle: I2C timeouts during userspace init
- Intermittent, appears on 5 out of 6 boots here
- Aaro Koskinen observes this also on N900
- Appears to be caused by commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
- http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
- http://marc.info/?l=linux-omap&m=135197877112220&w=2
- Revert posted, pending I2C maintainers:
- http://marc.info/?l=linux-arm-kernel&m=135221953727077&w=2
PM tests:
* 3530es3beagle: hangs during off-mode dynamic idle test
- Appears to be caused by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c:
- http://marc.info/?l=linux-omap&m=135075364705188&w=2
- Fixed by http://www.spinics.net/lists/arm-kernel/msg202116.html
Other:
* 2420N800: powers down 30 seconds after boot
- Presumably due to missing CBUS patches for watchdog control
- http://lkml.org/lkml/2012/9/3/265
* 4430es2panda: omap_hwmod: mcpdm: cannot be enabled for reset (3)
- clock source is from an external I2C-controlled source
- must skip reset until the switchover to hwmod late init
- http://www.spinics.net/lists/arm-kernel/msg178138.html
Failing tests: needing investigation
------------------------------------
Boot tests:
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
* CM-T3517: boot hangs with MMC boot
- Due to missing MMC setup in board file
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter reports this does not appear with the same X-loader/bootloader
on his 4430ES2.3 Panda, so could be ES-level dependent
Failing tests: needing local investigation (may be due to testbed issues)
-------------------------------------------------------------------------
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omap&m=135082257727502&w=2
- Not yet part of the automated test suite
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
* 4460pandaes: boot fails early
- Appears to be due to X-loader problems here
- Need to note the X-loader version so we know it's broken
PM tests:
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock gate ("debug ignore_loglevel")
- Not shown in the current test logs; cause unknown
- Pending re-test
vmlinux object size
(delta in bytes from test_v3.7-rc4 (3d70f8c617a436c7146ecb81df2265b4626dfe89)):
text data bss total kernel
+500 -8 0 +492 am33xx_only
+456 +16 0 +472 n800_multi_omap2xxx
+424 +16 0 +440 n800_only_a
+164 0 0 +164 omap1_defconfig
+164 0 0 +164 omap1_defconfig_1510innovator_only
+164 0 0 +164 omap1_defconfig_5912osk_only
+940 -8 0 +932 omap2plus_defconfig
+796 -8 0 +788 omap2plus_defconfig_2430sdp_only
+940 +24 0 +964 omap2plus_defconfig_cpupm
+940 -8 0 +932 omap2plus_defconfig_no_pm
+940 +16 0 +956 omap2plus_defconfig_omap2_4_only
+820 +16 0 +836 omap2plus_defconfig_omap3_4_only
+20 +8 +48 +76 rmk_omap3430_ldp_allnoconfig
+124 0 0 +124 rmk_omap3430_ldp_oldconfig
+20 +8 +48 +76 rmk_omap4430_sdp_allnoconfig
+124 +8 0 +132 rmk_omap4430_sdp_oldconfig
- Paul
^ permalink raw reply
* [PATCH] ARM: add get_user() support for 8 byte types
From: Rob Clark @ 2012-11-12 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112192727.GB28341@n2100.arm.linux.org.uk>
On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
>> From: Rob Clark <rob@ti.com>
>>
>> A new atomic modeset/pageflip ioctl being developed in DRM requires
>> get_user() to work for 64bit types (in addition to just put_user()).
>
> NAK.
>
> (I did write a better email explaining all the ins and outs of why this
> won't work and why 64-bit get_user isn't possible, but my editor crapped
> out and lost all that well written message; I don't fancy typing it all
> out again.)
>
> Nevertheless,
> int test_ptr(unsigned int **v, unsigned int **p)
> {
> return get_user(*v, p);
> }
>
> produces a warning, and you can't get away from that if you stick 64-bit
> support into get_user().
Actually, it seems like using 'register typeof(x) __r2 asm("r2");'
does avoid that warning..
I don't know if that was the only argument against 64-bit get_user().
But it will at least be inconvenient that get_user() works for 64bit
on x86 but not arm..
BR,
-R
> Sorry, 64-bit get_user() is a no-no.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox