2005-11-10 22:26:51 +08:00
|
|
|
/*
|
2011-03-30 06:54:50 +08:00
|
|
|
* linux/arch/arm/mach-omap2/timer.c
|
2005-11-10 22:26:51 +08:00
|
|
|
*
|
|
|
|
* OMAP2 GP timer support.
|
|
|
|
*
|
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12. Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management. GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management. GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator. But on HS devices, it
may not be available for Linux use.
It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12.
This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.
Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.
Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>
2009-04-24 11:11:10 +08:00
|
|
|
* Copyright (C) 2009 Nokia Corporation
|
|
|
|
*
|
2007-11-13 15:24:02 +08:00
|
|
|
* Update to use new clocksource/clockevent layers
|
|
|
|
* Author: Kevin Hilman, MontaVista Software, Inc. <source@mvista.com>
|
|
|
|
* Copyright (C) 2007 MontaVista Software, Inc.
|
|
|
|
*
|
|
|
|
* Original driver:
|
2005-11-10 22:26:51 +08:00
|
|
|
* Copyright (C) 2005 Nokia Corporation
|
|
|
|
* Author: Paul Mundt <paul.mundt@nokia.com>
|
2007-10-20 05:21:04 +08:00
|
|
|
* Juha Yrjölä <juha.yrjola@nokia.com>
|
2006-06-27 07:16:12 +08:00
|
|
|
* OMAP Dual-mode timer framework support by Timo Teras
|
2005-11-10 22:26:51 +08:00
|
|
|
*
|
|
|
|
* Some parts based off of TI's 24xx code:
|
|
|
|
*
|
2009-05-29 05:16:04 +08:00
|
|
|
* Copyright (C) 2004-2009 Texas Instruments, Inc.
|
2005-11-10 22:26:51 +08:00
|
|
|
*
|
|
|
|
* Roughly modelled after the OMAP1 MPU timer code.
|
2009-05-29 05:16:04 +08:00
|
|
|
* Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com>
|
2005-11-10 22:26:51 +08:00
|
|
|
*
|
|
|
|
* This file is subject to the terms and conditions of the GNU General Public
|
|
|
|
* License. See the file "COPYING" in the main directory of this archive
|
|
|
|
* for more details.
|
|
|
|
*/
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/time.h>
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/err.h>
|
2006-01-08 00:15:52 +08:00
|
|
|
#include <linux/clk.h>
|
2006-06-27 07:16:12 +08:00
|
|
|
#include <linux/delay.h>
|
2006-12-07 09:14:00 +08:00
|
|
|
#include <linux/irq.h>
|
2007-11-13 15:24:02 +08:00
|
|
|
#include <linux/clocksource.h>
|
|
|
|
#include <linux/clockchips.h>
|
2011-09-20 19:30:18 +08:00
|
|
|
#include <linux/slab.h>
|
2012-07-04 21:02:32 +08:00
|
|
|
#include <linux/of.h>
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
#include <linux/of_address.h>
|
|
|
|
#include <linux/of_irq.h>
|
2012-09-29 00:34:49 +08:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/platform_data/dmtimer-omap.h>
|
2013-06-02 14:39:40 +08:00
|
|
|
#include <linux/sched_clock.h>
|
2006-01-08 00:15:52 +08:00
|
|
|
|
2005-11-10 22:26:51 +08:00
|
|
|
#include <asm/mach/time.h>
|
2012-01-11 03:44:19 +08:00
|
|
|
#include <asm/smp_twd.h>
|
2012-08-28 08:43:01 +08:00
|
|
|
|
2012-10-03 08:41:35 +08:00
|
|
|
#include "omap_hwmod.h"
|
2012-10-03 08:25:48 +08:00
|
|
|
#include "omap_device.h"
|
2012-10-30 07:45:47 +08:00
|
|
|
#include <plat/counter-32k.h>
|
2012-08-28 08:43:01 +08:00
|
|
|
#include <plat/dmtimer.h>
|
2012-10-04 07:36:40 +08:00
|
|
|
#include "omap-pm.h"
|
2011-09-20 19:30:24 +08:00
|
|
|
|
2012-09-01 01:59:07 +08:00
|
|
|
#include "soc.h"
|
2012-08-28 08:43:01 +08:00
|
|
|
#include "common.h"
|
2015-01-06 07:45:45 +08:00
|
|
|
#include "control.h"
|
2011-09-20 19:30:24 +08:00
|
|
|
#include "powerdomain.h"
|
2013-10-10 15:43:48 +08:00
|
|
|
#include "omap-secure.h"
|
2005-11-10 22:26:51 +08:00
|
|
|
|
2012-08-13 16:54:24 +08:00
|
|
|
#define REALTIME_COUNTER_BASE 0x48243200
|
|
|
|
#define INCREMENTER_NUMERATOR_OFFSET 0x10
|
|
|
|
#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
|
|
|
|
#define NUMERATOR_DENUMERATOR_MASK 0xfffff000
|
|
|
|
|
2011-03-30 06:54:48 +08:00
|
|
|
/* Clockevent code */
|
|
|
|
|
|
|
|
static struct omap_dm_timer clkev;
|
2007-11-13 15:24:02 +08:00
|
|
|
static struct clock_event_device clockevent_gpt;
|
2005-11-10 22:26:51 +08:00
|
|
|
|
2013-10-12 08:28:04 +08:00
|
|
|
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
|
2013-10-10 15:43:48 +08:00
|
|
|
static unsigned long arch_timer_freq;
|
|
|
|
|
|
|
|
void set_cntfreq(void)
|
|
|
|
{
|
|
|
|
omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
|
|
|
|
}
|
2013-10-12 08:28:04 +08:00
|
|
|
#endif
|
2005-11-10 22:26:51 +08:00
|
|
|
|
2006-10-07 01:53:39 +08:00
|
|
|
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
|
2005-11-10 22:26:51 +08:00
|
|
|
{
|
2007-11-13 15:24:02 +08:00
|
|
|
struct clock_event_device *evt = &clockevent_gpt;
|
|
|
|
|
2011-09-17 06:44:20 +08:00
|
|
|
__omap_dm_timer_write_status(&clkev, OMAP_TIMER_INT_OVERFLOW);
|
2005-11-10 22:26:51 +08:00
|
|
|
|
2007-11-13 15:24:02 +08:00
|
|
|
evt->event_handler(evt);
|
2005-11-10 22:26:51 +08:00
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct irqaction omap2_gp_timer_irq = {
|
2012-05-10 01:07:05 +08:00
|
|
|
.name = "gp_timer",
|
2013-09-07 15:19:25 +08:00
|
|
|
.flags = IRQF_TIMER | IRQF_IRQPOLL,
|
2005-11-10 22:26:51 +08:00
|
|
|
.handler = omap2_gp_timer_interrupt,
|
|
|
|
};
|
|
|
|
|
2007-11-13 15:24:02 +08:00
|
|
|
static int omap2_gp_timer_set_next_event(unsigned long cycles,
|
|
|
|
struct clock_event_device *evt)
|
2005-11-10 22:26:51 +08:00
|
|
|
{
|
2011-09-17 06:44:20 +08:00
|
|
|
__omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_ST,
|
2012-09-28 00:49:45 +08:00
|
|
|
0xffffffff - cycles, OMAP_TIMER_POSTED);
|
2007-11-13 15:24:02 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-02-27 16:09:52 +08:00
|
|
|
static int omap2_gp_timer_shutdown(struct clock_event_device *evt)
|
|
|
|
{
|
|
|
|
__omap_dm_timer_stop(&clkev, OMAP_TIMER_POSTED, clkev.rate);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int omap2_gp_timer_set_periodic(struct clock_event_device *evt)
|
2007-11-13 15:24:02 +08:00
|
|
|
{
|
|
|
|
u32 period;
|
|
|
|
|
2012-09-28 00:49:45 +08:00
|
|
|
__omap_dm_timer_stop(&clkev, OMAP_TIMER_POSTED, clkev.rate);
|
2007-11-13 15:24:02 +08:00
|
|
|
|
2015-02-27 16:09:52 +08:00
|
|
|
period = clkev.rate / HZ;
|
|
|
|
period -= 1;
|
|
|
|
/* Looks like we need to first set the load value separately */
|
|
|
|
__omap_dm_timer_write(&clkev, OMAP_TIMER_LOAD_REG, 0xffffffff - period,
|
|
|
|
OMAP_TIMER_POSTED);
|
|
|
|
__omap_dm_timer_load_start(&clkev,
|
|
|
|
OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
|
|
|
|
0xffffffff - period, OMAP_TIMER_POSTED);
|
|
|
|
return 0;
|
2007-11-13 15:24:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct clock_event_device clockevent_gpt = {
|
2015-02-27 16:09:52 +08:00
|
|
|
.features = CLOCK_EVT_FEAT_PERIODIC |
|
|
|
|
CLOCK_EVT_FEAT_ONESHOT,
|
|
|
|
.rating = 300,
|
|
|
|
.set_next_event = omap2_gp_timer_set_next_event,
|
|
|
|
.set_state_shutdown = omap2_gp_timer_shutdown,
|
|
|
|
.set_state_periodic = omap2_gp_timer_set_periodic,
|
|
|
|
.set_state_oneshot = omap2_gp_timer_shutdown,
|
|
|
|
.tick_resume = omap2_gp_timer_shutdown,
|
2007-11-13 15:24:02 +08:00
|
|
|
};
|
|
|
|
|
2012-06-21 04:55:24 +08:00
|
|
|
static struct property device_disabled = {
|
|
|
|
.name = "status",
|
|
|
|
.length = sizeof("disabled"),
|
|
|
|
.value = "disabled",
|
|
|
|
};
|
|
|
|
|
2014-09-10 16:26:17 +08:00
|
|
|
static const struct of_device_id omap_timer_match[] __initconst = {
|
2013-03-20 01:38:18 +08:00
|
|
|
{ .compatible = "ti,omap2420-timer", },
|
|
|
|
{ .compatible = "ti,omap3430-timer", },
|
|
|
|
{ .compatible = "ti,omap4430-timer", },
|
|
|
|
{ .compatible = "ti,omap5430-timer", },
|
2015-01-15 09:37:16 +08:00
|
|
|
{ .compatible = "ti,dm814-timer", },
|
|
|
|
{ .compatible = "ti,dm816-timer", },
|
2013-03-20 01:38:18 +08:00
|
|
|
{ .compatible = "ti,am335x-timer", },
|
|
|
|
{ .compatible = "ti,am335x-timer-1ms", },
|
2012-06-21 04:55:24 +08:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
/**
|
|
|
|
* omap_get_timer_dt - get a timer using device-tree
|
|
|
|
* @match - device-tree match structure for matching a device type
|
|
|
|
* @property - optional timer property to match
|
|
|
|
*
|
|
|
|
* Helper function to get a timer during early boot using device-tree for use
|
|
|
|
* as kernel system timer. Optionally, the property argument can be used to
|
|
|
|
* select a timer with a specific property. Once a timer is found then mark
|
|
|
|
* the timer node in device-tree as disabled, to prevent the kernel from
|
|
|
|
* registering this timer as a platform device and so no one else can use it.
|
|
|
|
*/
|
2014-09-10 16:26:17 +08:00
|
|
|
static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match,
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
const char *property)
|
|
|
|
{
|
|
|
|
struct device_node *np;
|
|
|
|
|
|
|
|
for_each_matching_node(np, match) {
|
2013-01-08 21:31:42 +08:00
|
|
|
if (!of_device_is_available(np))
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
continue;
|
|
|
|
|
2013-01-08 21:31:42 +08:00
|
|
|
if (property && !of_get_property(np, property, NULL))
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
continue;
|
|
|
|
|
ARM: OMAP3: Update clocksource timer selection
When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer for clocksource that is located in a
power domain that is always on (such as the wake-up domain) so that time
can be maintained during a kernel suspend without keeping on additional
power domains unnecessarily.
In order to fix this so that we can select a gptimer located in a power
domain that is always-on, the following changes were made ...
1. Currently, only when selecting a gptimer to use for a clockevent
timer, do we pass a timer property that can be used to select a
specific gptimer. Change this so that we can pass a property when
selecting a gptimer to use for a clocksource timer too.
2. Currently, when selecting either a gptimer to use for a clockevent
timer or a clocksource timer and no timer property is passed, then
the first available timer is selected regardless of the properties
it has. Change this so that if no properties are passed, then a timer
that does not have additional features (such as always-on, dsp-irq,
pwm, and secure) is selected.
For OMAP3 and AM335x devices that use a gptimer for clocksource, change
the selection of the gptimer so that by default the gptimer located in
the always-on power domain is used for clocksource instead of
clockevents.
Please note that using a gptimer for both clocksource and clockevents
can have a system power impact during idle. The reason being is that
OMAP and AMxxx devices typically only have one gptimer in a power domain
that is always-on. Therefore when the kernel is idle both the clocksource
and clockevent timers will be active and this will keep additional power
domains on. During kernel suspend, only the clocksource timer is active
and therefore, it is better to use a gptimer in a power domain that is
always-on for clocksource.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
2013-01-29 07:53:57 +08:00
|
|
|
if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
|
|
|
|
of_get_property(np, "ti,timer-dsp", NULL) ||
|
|
|
|
of_get_property(np, "ti,timer-pwm", NULL) ||
|
|
|
|
of_get_property(np, "ti,timer-secure", NULL)))
|
|
|
|
continue;
|
|
|
|
|
2015-09-30 04:10:10 +08:00
|
|
|
if (!of_device_is_compatible(np, "ti,omap-counter32k"))
|
|
|
|
of_add_property(np, &device_disabled);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
return np;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2012-06-21 04:55:24 +08:00
|
|
|
/**
|
|
|
|
* omap_dmtimer_init - initialisation function when device tree is used
|
|
|
|
*
|
|
|
|
* For secure OMAP3 devices, timers with device type "timer-secure" cannot
|
|
|
|
* be used by the kernel as they are reserved. Therefore, to prevent the
|
|
|
|
* kernel registering these devices remove them dynamically from the device
|
|
|
|
* tree on boot.
|
|
|
|
*/
|
2012-11-29 05:56:41 +08:00
|
|
|
static void __init omap_dmtimer_init(void)
|
2012-06-21 04:55:24 +08:00
|
|
|
{
|
|
|
|
struct device_node *np;
|
|
|
|
|
|
|
|
if (!cpu_is_omap34xx())
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* If we are a secure device, remove any secure timer nodes */
|
|
|
|
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
|
2015-06-30 20:00:16 +08:00
|
|
|
of_node_put(np);
|
2012-06-21 04:55:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2012-11-29 05:56:41 +08:00
|
|
|
static u32 __init omap_dm_timer_get_errata(void)
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
{
|
|
|
|
if (cpu_is_omap24xx())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return OMAP_TIMER_ERRATA_I103_I767;
|
|
|
|
}
|
|
|
|
|
2011-03-30 06:54:48 +08:00
|
|
|
static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
|
2013-01-30 03:55:25 +08:00
|
|
|
const char *fck_source,
|
|
|
|
const char *property,
|
|
|
|
const char **timer_name,
|
|
|
|
int posted)
|
2007-11-13 15:24:02 +08:00
|
|
|
{
|
2011-03-30 06:54:48 +08:00
|
|
|
char name[10]; /* 10 = sizeof("gptXX_Xck0") */
|
2013-05-28 14:24:48 +08:00
|
|
|
const char *oh_name = NULL;
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
struct device_node *np;
|
2011-03-30 06:54:48 +08:00
|
|
|
struct omap_hwmod *oh;
|
2012-09-29 07:03:29 +08:00
|
|
|
struct resource irq, mem;
|
2013-03-13 06:17:57 +08:00
|
|
|
struct clk *src;
|
2012-11-10 07:07:39 +08:00
|
|
|
int r = 0;
|
2011-03-30 06:54:48 +08:00
|
|
|
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
if (of_have_populated_dt()) {
|
2013-01-30 04:23:11 +08:00
|
|
|
np = omap_get_timer_dt(omap_timer_match, property);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
if (!np)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
|
|
|
|
if (!oh_name)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
timer->irq = irq_of_parse_and_map(np, 0);
|
|
|
|
if (!timer->irq)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
timer->io_base = of_iomap(np, 0);
|
|
|
|
|
|
|
|
of_node_put(np);
|
|
|
|
} else {
|
2013-02-02 06:40:09 +08:00
|
|
|
if (omap_dm_timer_reserve_systimer(timer->id))
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
2013-02-02 06:40:09 +08:00
|
|
|
sprintf(name, "timer%d", timer->id);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
oh_name = name;
|
|
|
|
}
|
|
|
|
|
|
|
|
oh = omap_hwmod_lookup(oh_name);
|
2011-03-30 06:54:48 +08:00
|
|
|
if (!oh)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2013-01-30 03:55:25 +08:00
|
|
|
*timer_name = oh->name;
|
|
|
|
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
if (!of_have_populated_dt()) {
|
|
|
|
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
|
2012-09-29 07:03:29 +08:00
|
|
|
&irq);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
if (r)
|
|
|
|
return -ENXIO;
|
2012-09-29 07:03:29 +08:00
|
|
|
timer->irq = irq.start;
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
|
|
|
|
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM, NULL,
|
2012-09-29 07:03:29 +08:00
|
|
|
&mem);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
if (r)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
/* Static mapping, never released */
|
2012-09-29 07:03:29 +08:00
|
|
|
timer->io_base = ioremap(mem.start, mem.end - mem.start);
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
}
|
2011-03-30 06:54:48 +08:00
|
|
|
|
|
|
|
if (!timer->io_base)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
/* After the dmtimer is using hwmod these clocks won't be needed */
|
2012-07-05 20:40:59 +08:00
|
|
|
timer->fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
|
2011-03-30 06:54:48 +08:00
|
|
|
if (IS_ERR(timer->fclk))
|
2013-03-13 06:17:57 +08:00
|
|
|
return PTR_ERR(timer->fclk);
|
2011-03-30 06:54:48 +08:00
|
|
|
|
2013-03-13 06:17:57 +08:00
|
|
|
src = clk_get(NULL, fck_source);
|
|
|
|
if (IS_ERR(src))
|
|
|
|
return PTR_ERR(src);
|
2011-03-30 06:54:48 +08:00
|
|
|
|
2015-09-02 04:59:25 +08:00
|
|
|
WARN(clk_set_parent(timer->fclk, src) < 0,
|
|
|
|
"Cannot set timer parent clock, no PLL clock driver?");
|
2012-09-29 00:43:30 +08:00
|
|
|
|
2013-03-13 06:17:57 +08:00
|
|
|
clk_put(src);
|
|
|
|
|
2012-09-29 00:43:30 +08:00
|
|
|
omap_hwmod_setup_one(oh_name);
|
|
|
|
omap_hwmod_enable(oh);
|
2011-09-17 06:44:20 +08:00
|
|
|
__omap_dm_timer_init_regs(timer);
|
2011-03-30 06:54:48 +08:00
|
|
|
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
if (posted)
|
|
|
|
__omap_dm_timer_enable_posted(timer);
|
|
|
|
|
|
|
|
/* Check that the intended posted configuration matches the actual */
|
|
|
|
if (posted != timer->posted)
|
|
|
|
return -EINVAL;
|
2005-11-10 22:26:51 +08:00
|
|
|
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
timer->rate = clk_get_rate(timer->fclk);
|
2011-03-30 06:54:48 +08:00
|
|
|
timer->reserved = 1;
|
2011-02-23 15:14:08 +08:00
|
|
|
|
2012-11-10 07:07:39 +08:00
|
|
|
return r;
|
2011-03-30 06:54:48 +08:00
|
|
|
}
|
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12. Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management. GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management. GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator. But on HS devices, it
may not be available for Linux use.
It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12.
This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.
Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.
Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>
2009-04-24 11:11:10 +08:00
|
|
|
|
2011-03-30 06:54:48 +08:00
|
|
|
static void __init omap2_gp_clockevent_init(int gptimer_id,
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
const char *fck_source,
|
|
|
|
const char *property)
|
2011-03-30 06:54:48 +08:00
|
|
|
{
|
|
|
|
int res;
|
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12. Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management. GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management. GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator. But on HS devices, it
may not be available for Linux use.
It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12.
This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.
Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.
Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>
2009-04-24 11:11:10 +08:00
|
|
|
|
2013-02-02 06:40:09 +08:00
|
|
|
clkev.id = gptimer_id;
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
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);
|
|
|
|
|
2013-02-02 06:40:09 +08:00
|
|
|
res = omap_dm_timer_init_one(&clkev, fck_source, property,
|
2013-01-30 03:55:25 +08:00
|
|
|
&clockevent_gpt.name, OMAP_TIMER_POSTED);
|
2011-03-30 06:54:48 +08:00
|
|
|
BUG_ON(res);
|
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12. Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management. GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management. GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator. But on HS devices, it
may not be available for Linux use.
It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12.
This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.
Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.
Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>
2009-04-24 11:11:10 +08:00
|
|
|
|
2012-08-03 23:21:10 +08:00
|
|
|
omap2_gp_timer_irq.dev_id = &clkev;
|
2011-03-30 06:54:48 +08:00
|
|
|
setup_irq(clkev.irq, &omap2_gp_timer_irq);
|
2007-11-13 15:24:02 +08:00
|
|
|
|
2011-09-17 06:44:20 +08:00
|
|
|
__omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
|
2011-03-30 06:54:48 +08:00
|
|
|
|
2012-03-17 17:30:16 +08:00
|
|
|
clockevent_gpt.cpumask = cpu_possible_mask;
|
|
|
|
clockevent_gpt.irq = omap_dm_timer_get_irq(&clkev);
|
2013-01-12 19:50:05 +08:00
|
|
|
clockevents_config_and_register(&clockevent_gpt, clkev.rate,
|
|
|
|
3, /* Timer internal resynch latency */
|
|
|
|
0xffffffff);
|
2011-03-30 06:54:48 +08:00
|
|
|
|
2013-01-30 03:55:25 +08:00
|
|
|
pr_info("OMAP clockevent source: %s at %lu Hz\n", clockevent_gpt.name,
|
|
|
|
clkev.rate);
|
2007-11-13 15:24:02 +08:00
|
|
|
}
|
|
|
|
|
OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files
Add a function omap2_gp_clockevent_set_gptimer() for board-*.c files
to use in .init_irq functions to configure the system tick GPTIMER.
Practical choices at this point are GPTIMER1 or GPTIMER12. Both of
these timers are in the WKUP powerdomain, and so are unaffected by
chip power management. GPTIMER1 can use sys_clk as a source, for
applications where a high-resolution timer is more important than
power management. GPTIMER12 has the special property that it has the
secure 32kHz oscillator as its source clock, which may be less prone
to glitches than the off-chip 32kHz oscillator. But on HS devices, it
may not be available for Linux use.
It appears that most boards are fine with GPTIMER1, but BeagleBoard
should use GPTIMER12 when using a 32KiHz timer source, due to hardware bugs
in revisions B4 and below. Modify board-omap3beagle.c to use GPTIMER12.
This patch originally used a Kbuild config option to select the GPTIMER,
but was changed to allow this to be specified in board-*.c files, per
Tony's request.
Kalle Vallo <kalle.valo@nokia.com> found a bug in an earlier version of
this patch - thanks Kalle.
Tested on Beagle rev B4 ES2.1, with and without CONFIG_OMAP_32K_TIMER, and
3430SDP.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kalle.valo@nokia.com>
2009-04-24 11:11:10 +08:00
|
|
|
/* Clocksource code */
|
2011-03-30 06:54:49 +08:00
|
|
|
static struct omap_dm_timer clksrc;
|
2014-04-15 00:49:30 +08:00
|
|
|
static bool use_gptimer_clksrc __initdata;
|
2011-03-30 06:54:49 +08:00
|
|
|
|
2007-11-13 15:24:02 +08:00
|
|
|
/*
|
|
|
|
* clocksource
|
|
|
|
*/
|
2009-04-22 03:24:00 +08:00
|
|
|
static cycle_t clocksource_read_cycles(struct clocksource *cs)
|
2007-11-13 15:24:02 +08:00
|
|
|
{
|
2012-09-28 00:49:45 +08:00
|
|
|
return (cycle_t)__omap_dm_timer_read_counter(&clksrc,
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
OMAP_TIMER_NONPOSTED);
|
2007-11-13 15:24:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct clocksource clocksource_gpt = {
|
|
|
|
.rating = 300,
|
|
|
|
.read = clocksource_read_cycles,
|
|
|
|
.mask = CLOCKSOURCE_MASK(32),
|
|
|
|
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
|
|
|
|
};
|
|
|
|
|
2013-11-16 07:26:18 +08:00
|
|
|
static u64 notrace dmtimer_read_sched_clock(void)
|
2011-02-23 10:59:49 +08:00
|
|
|
{
|
2011-03-30 06:54:49 +08:00
|
|
|
if (clksrc.reserved)
|
2012-09-28 00:49:45 +08:00
|
|
|
return __omap_dm_timer_read_counter(&clksrc,
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
OMAP_TIMER_NONPOSTED);
|
2007-11-13 15:24:02 +08:00
|
|
|
|
2011-12-15 19:19:23 +08:00
|
|
|
return 0;
|
2011-03-30 06:54:49 +08:00
|
|
|
}
|
|
|
|
|
2014-09-10 16:26:17 +08:00
|
|
|
static const struct of_device_id omap_counter_match[] __initconst = {
|
2012-11-16 03:09:03 +08:00
|
|
|
{ .compatible = "ti,omap-counter32k", },
|
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2011-03-30 06:54:49 +08:00
|
|
|
/* Setup free-running counter for clocksource */
|
2012-11-28 05:24:12 +08:00
|
|
|
static int __init __maybe_unused omap2_sync32k_clocksource_init(void)
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2012-10-10 03:12:26 +08:00
|
|
|
struct device_node *np = NULL;
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
struct omap_hwmod *oh;
|
|
|
|
const char *oh_name = "counter_32k";
|
|
|
|
|
2012-10-10 03:12:26 +08:00
|
|
|
/*
|
|
|
|
* If device-tree is present, then search the DT blob
|
|
|
|
* to see if the 32kHz counter is supported.
|
|
|
|
*/
|
|
|
|
if (of_have_populated_dt()) {
|
|
|
|
np = omap_get_timer_dt(omap_counter_match, NULL);
|
|
|
|
if (!np)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
|
|
|
|
if (!oh_name)
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
/*
|
|
|
|
* First check hwmod data is available for sync32k counter
|
|
|
|
*/
|
|
|
|
oh = omap_hwmod_lookup(oh_name);
|
|
|
|
if (!oh || oh->slaves_cnt == 0)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
omap_hwmod_setup_one(oh_name);
|
|
|
|
|
|
|
|
ret = omap_hwmod_enable(oh);
|
|
|
|
if (ret) {
|
|
|
|
pr_warn("%s: failed to enable counter_32k module (%d)\n",
|
|
|
|
__func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-09-30 04:10:10 +08:00
|
|
|
if (!of_have_populated_dt()) {
|
|
|
|
void __iomem *vbase;
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
|
2015-09-30 04:10:10 +08:00
|
|
|
vbase = omap_hwmod_get_mpu_rt_va(oh);
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
|
2015-09-30 04:10:10 +08:00
|
|
|
ret = omap_init_clocksource_32k(vbase);
|
|
|
|
if (ret) {
|
|
|
|
pr_warn("%s: failed to initialize counter_32k as a clocksource (%d)\n",
|
|
|
|
__func__, ret);
|
|
|
|
omap_hwmod_idle(oh);
|
|
|
|
}
|
|
|
|
}
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init omap2_gptimer_clocksource_init(int gptimer_id,
|
ARM: OMAP3: Update clocksource timer selection
When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer for clocksource that is located in a
power domain that is always on (such as the wake-up domain) so that time
can be maintained during a kernel suspend without keeping on additional
power domains unnecessarily.
In order to fix this so that we can select a gptimer located in a power
domain that is always-on, the following changes were made ...
1. Currently, only when selecting a gptimer to use for a clockevent
timer, do we pass a timer property that can be used to select a
specific gptimer. Change this so that we can pass a property when
selecting a gptimer to use for a clocksource timer too.
2. Currently, when selecting either a gptimer to use for a clockevent
timer or a clocksource timer and no timer property is passed, then
the first available timer is selected regardless of the properties
it has. Change this so that if no properties are passed, then a timer
that does not have additional features (such as always-on, dsp-irq,
pwm, and secure) is selected.
For OMAP3 and AM335x devices that use a gptimer for clocksource, change
the selection of the gptimer so that by default the gptimer located in
the always-on power domain is used for clocksource instead of
clockevents.
Please note that using a gptimer for both clocksource and clockevents
can have a system power impact during idle. The reason being is that
OMAP and AMxxx devices typically only have one gptimer in a power domain
that is always-on. Therefore when the kernel is idle both the clocksource
and clockevent timers will be active and this will keep additional power
domains on. During kernel suspend, only the clocksource timer is active
and therefore, it is better to use a gptimer in a power domain that is
always-on for clocksource.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
2013-01-29 07:53:57 +08:00
|
|
|
const char *fck_source,
|
|
|
|
const char *property)
|
2011-03-30 06:54:49 +08:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
2013-02-02 06:40:09 +08:00
|
|
|
clksrc.id = gptimer_id;
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
clksrc.errata = omap_dm_timer_get_errata();
|
|
|
|
|
2013-02-02 06:40:09 +08:00
|
|
|
res = omap_dm_timer_init_one(&clksrc, fck_source, property,
|
2013-01-30 03:55:25 +08:00
|
|
|
&clocksource_gpt.name,
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
OMAP_TIMER_NONPOSTED);
|
2011-03-30 06:54:49 +08:00
|
|
|
BUG_ON(res);
|
2007-11-13 15:24:02 +08:00
|
|
|
|
2011-09-17 06:44:20 +08:00
|
|
|
__omap_dm_timer_load_start(&clksrc,
|
2012-09-28 00:49:45 +08:00
|
|
|
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0,
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
OMAP_TIMER_NONPOSTED);
|
2013-11-16 07:26:18 +08:00
|
|
|
sched_clock_register(dmtimer_read_sched_clock, 32, clksrc.rate);
|
2011-02-23 10:59:49 +08:00
|
|
|
|
2011-03-30 06:54:49 +08:00
|
|
|
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
|
|
|
|
pr_err("Could not register clocksource %s\n",
|
|
|
|
clocksource_gpt.name);
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
else
|
2013-01-30 03:55:25 +08:00
|
|
|
pr_info("OMAP clocksource: %s at %lu Hz\n",
|
|
|
|
clocksource_gpt.name, clksrc.rate);
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
}
|
|
|
|
|
2015-09-30 02:12:55 +08:00
|
|
|
static void __init __omap_sync32k_timer_init(int clkev_nr, const char *clkev_src,
|
|
|
|
const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
|
|
|
|
const char *clksrc_prop, bool gptimer)
|
|
|
|
{
|
|
|
|
omap_clk_init();
|
|
|
|
omap_dmtimer_init();
|
|
|
|
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
|
|
|
|
|
|
|
|
/* Enable the use of clocksource="gp_timer" kernel parameter */
|
|
|
|
if (use_gptimer_clksrc || gptimer)
|
|
|
|
omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
|
|
|
|
clksrc_prop);
|
|
|
|
else
|
|
|
|
omap2_sync32k_clocksource_init();
|
|
|
|
}
|
|
|
|
|
2015-09-30 02:26:45 +08:00
|
|
|
void __init omap_init_time(void)
|
2015-09-30 02:12:55 +08:00
|
|
|
{
|
|
|
|
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
|
|
|
|
2, "timer_sys_ck", NULL, false);
|
2015-09-30 02:15:02 +08:00
|
|
|
|
|
|
|
if (of_have_populated_dt())
|
2015-11-11 06:48:36 +08:00
|
|
|
clocksource_probe();
|
2015-09-30 02:12:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
|
|
|
|
void __init omap3_secure_sync32k_timer_init(void)
|
|
|
|
{
|
|
|
|
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
|
|
|
|
2, "timer_sys_ck", NULL, false);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_ARCH_OMAP3 */
|
|
|
|
|
|
|
|
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
|
|
|
|
void __init omap3_gptimer_timer_init(void)
|
|
|
|
{
|
|
|
|
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
|
|
|
|
1, "timer_sys_ck", "ti,timer-alwon", true);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
|
|
|
|
defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
|
|
|
|
static void __init omap4_sync32k_timer_init(void)
|
|
|
|
{
|
|
|
|
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
|
|
|
|
2, "sys_clkin_ck", NULL, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init omap4_local_timer_init(void)
|
|
|
|
{
|
|
|
|
omap4_sync32k_timer_init();
|
2015-11-11 06:48:36 +08:00
|
|
|
clocksource_probe();
|
2015-09-30 02:12:55 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
|
|
|
|
|
2012-08-13 16:54:24 +08:00
|
|
|
/*
|
|
|
|
* The realtime counter also called master counter, is a free-running
|
|
|
|
* counter, which is related to real time. It produces the count used
|
|
|
|
* by the CPU local timer peripherals in the MPU cluster. The timer counts
|
|
|
|
* at a rate of 6.144 MHz. Because the device operates on different clocks
|
|
|
|
* in different power modes, the master counter shifts operation between
|
|
|
|
* clocks, adjusting the increment per clock in hardware accordingly to
|
|
|
|
* maintain a constant count rate.
|
|
|
|
*/
|
|
|
|
static void __init realtime_counter_init(void)
|
|
|
|
{
|
2015-09-30 02:12:55 +08:00
|
|
|
#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
|
2012-08-13 16:54:24 +08:00
|
|
|
void __iomem *base;
|
|
|
|
static struct clk *sys_clk;
|
|
|
|
unsigned long rate;
|
2015-01-06 07:45:45 +08:00
|
|
|
unsigned int reg;
|
|
|
|
unsigned long long num, den;
|
2012-08-13 16:54:24 +08:00
|
|
|
|
|
|
|
base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
|
|
|
|
if (!base) {
|
|
|
|
pr_err("%s: ioremap failed\n", __func__);
|
|
|
|
return;
|
|
|
|
}
|
2013-04-04 01:47:59 +08:00
|
|
|
sys_clk = clk_get(NULL, "sys_clkin");
|
2012-10-09 06:01:41 +08:00
|
|
|
if (IS_ERR(sys_clk)) {
|
2012-08-13 16:54:24 +08:00
|
|
|
pr_err("%s: failed to get system clock handle\n", __func__);
|
|
|
|
iounmap(base);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rate = clk_get_rate(sys_clk);
|
2015-01-06 07:45:45 +08:00
|
|
|
|
|
|
|
if (soc_is_dra7xx()) {
|
|
|
|
/*
|
|
|
|
* Errata i856 says the 32.768KHz crystal does not start at
|
|
|
|
* power on, so the CPU falls back to an emulated 32KHz clock
|
|
|
|
* based on sysclk / 610 instead. This causes the master counter
|
|
|
|
* frequency to not be 6.144MHz but at sysclk / 610 * 375 / 2
|
|
|
|
* (OR sysclk * 75 / 244)
|
|
|
|
*
|
|
|
|
* This affects at least the DRA7/AM572x 1.0, 1.1 revisions.
|
|
|
|
* Of course any board built without a populated 32.768KHz
|
|
|
|
* crystal would also need this fix even if the CPU is fixed
|
|
|
|
* later.
|
|
|
|
*
|
|
|
|
* Either case can be detected by using the two speedselect bits
|
|
|
|
* If they are not 0, then the 32.768KHz clock driving the
|
|
|
|
* coarse counter that corrects the fine counter every time it
|
|
|
|
* ticks is actually rate/610 rather than 32.768KHz and we
|
|
|
|
* should compensate to avoid the 570ppm (at 20MHz, much worse
|
|
|
|
* at other rates) too fast system time.
|
|
|
|
*/
|
|
|
|
reg = omap_ctrl_readl(DRA7_CTRL_CORE_BOOTSTRAP);
|
|
|
|
if (reg & DRA7_SPEEDSELECT_MASK) {
|
|
|
|
num = 75;
|
|
|
|
den = 244;
|
|
|
|
goto sysclk1_based;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-13 16:54:24 +08:00
|
|
|
/* Numerator/denumerator values refer TRM Realtime Counter section */
|
|
|
|
switch (rate) {
|
2015-01-06 07:45:45 +08:00
|
|
|
case 12000000:
|
2012-08-13 16:54:24 +08:00
|
|
|
num = 64;
|
|
|
|
den = 125;
|
|
|
|
break;
|
2015-01-06 07:45:45 +08:00
|
|
|
case 13000000:
|
2012-08-13 16:54:24 +08:00
|
|
|
num = 768;
|
|
|
|
den = 1625;
|
|
|
|
break;
|
|
|
|
case 19200000:
|
|
|
|
num = 8;
|
|
|
|
den = 25;
|
|
|
|
break;
|
2013-09-18 19:20:11 +08:00
|
|
|
case 20000000:
|
|
|
|
num = 192;
|
|
|
|
den = 625;
|
|
|
|
break;
|
2015-01-06 07:45:45 +08:00
|
|
|
case 26000000:
|
2012-08-13 16:54:24 +08:00
|
|
|
num = 384;
|
|
|
|
den = 1625;
|
|
|
|
break;
|
2015-01-06 07:45:45 +08:00
|
|
|
case 27000000:
|
2012-08-13 16:54:24 +08:00
|
|
|
num = 256;
|
|
|
|
den = 1125;
|
|
|
|
break;
|
|
|
|
case 38400000:
|
|
|
|
default:
|
|
|
|
/* Program it for 38.4 MHz */
|
|
|
|
num = 4;
|
|
|
|
den = 25;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2015-01-06 07:45:45 +08:00
|
|
|
sysclk1_based:
|
2012-08-13 16:54:24 +08:00
|
|
|
/* Program numerator and denumerator registers */
|
2014-04-16 01:37:46 +08:00
|
|
|
reg = readl_relaxed(base + INCREMENTER_NUMERATOR_OFFSET) &
|
2012-08-13 16:54:24 +08:00
|
|
|
NUMERATOR_DENUMERATOR_MASK;
|
|
|
|
reg |= num;
|
2014-04-16 01:37:46 +08:00
|
|
|
writel_relaxed(reg, base + INCREMENTER_NUMERATOR_OFFSET);
|
2012-08-13 16:54:24 +08:00
|
|
|
|
2014-04-16 01:37:46 +08:00
|
|
|
reg = readl_relaxed(base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET) &
|
2012-08-13 16:54:24 +08:00
|
|
|
NUMERATOR_DENUMERATOR_MASK;
|
|
|
|
reg |= den;
|
2014-04-16 01:37:46 +08:00
|
|
|
writel_relaxed(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
|
2012-08-13 16:54:24 +08:00
|
|
|
|
2015-01-06 07:45:45 +08:00
|
|
|
arch_timer_freq = DIV_ROUND_UP_ULL(rate * num, den);
|
2013-10-10 15:43:48 +08:00
|
|
|
set_cntfreq();
|
|
|
|
|
2012-08-13 16:54:24 +08:00
|
|
|
iounmap(base);
|
|
|
|
#endif
|
2012-11-20 15:17:15 +08:00
|
|
|
}
|
|
|
|
|
2012-11-09 03:40:59 +08:00
|
|
|
void __init omap5_realtime_timer_init(void)
|
2012-08-13 16:54:24 +08:00
|
|
|
{
|
2013-01-12 10:23:09 +08:00
|
|
|
omap4_sync32k_timer_init();
|
2012-08-13 16:54:24 +08:00
|
|
|
realtime_counter_init();
|
2012-08-13 17:09:03 +08:00
|
|
|
|
2015-09-28 22:49:18 +08:00
|
|
|
clocksource_probe();
|
2012-08-13 16:54:24 +08:00
|
|
|
}
|
2013-10-08 16:50:33 +08:00
|
|
|
#endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
|
2012-05-02 15:37:12 +08:00
|
|
|
|
2011-09-20 19:30:18 +08:00
|
|
|
/**
|
|
|
|
* omap_timer_init - build and register timer device with an
|
|
|
|
* associated timer hwmod
|
|
|
|
* @oh: timer hwmod pointer to be used to build timer device
|
|
|
|
* @user: parameter that can be passed from calling hwmod API
|
|
|
|
*
|
|
|
|
* Called by omap_hwmod_for_each_by_class to register each of the timer
|
|
|
|
* devices present in the system. The number of timer devices is known
|
|
|
|
* by parsing through the hwmod database for a given class name. At the
|
|
|
|
* end of function call memory is allocated for timer device and it is
|
|
|
|
* registered to the framework ready to be proved by the driver.
|
|
|
|
*/
|
|
|
|
static int __init omap_timer_init(struct omap_hwmod *oh, void *unused)
|
|
|
|
{
|
|
|
|
int id;
|
|
|
|
int ret = 0;
|
|
|
|
char *name = "omap_timer";
|
|
|
|
struct dmtimer_platform_data *pdata;
|
2011-10-05 00:47:06 +08:00
|
|
|
struct platform_device *pdev;
|
2011-09-20 19:30:18 +08:00
|
|
|
struct omap_timer_capability_dev_attr *timer_dev_attr;
|
|
|
|
|
|
|
|
pr_debug("%s: %s\n", __func__, oh->name);
|
|
|
|
|
|
|
|
/* on secure device, do not register secure timer */
|
|
|
|
timer_dev_attr = oh->dev_attr;
|
|
|
|
if (omap_type() != OMAP2_DEVICE_TYPE_GP && timer_dev_attr)
|
|
|
|
if (timer_dev_attr->timer_capability == OMAP_TIMER_SECURE)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
|
|
|
|
if (!pdata) {
|
|
|
|
pr_err("%s: No memory for [%s]\n", __func__, oh->name);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extract the IDs from name field in hwmod database
|
|
|
|
* and use the same for constructing ids' for the
|
|
|
|
* timer devices. In a way, we are avoiding usage of
|
|
|
|
* static variable witin the function to do the same.
|
|
|
|
* CAUTION: We have to be careful and make sure the
|
|
|
|
* name in hwmod database does not change in which case
|
|
|
|
* we might either make corresponding change here or
|
|
|
|
* switch back static variable mechanism.
|
|
|
|
*/
|
|
|
|
sscanf(oh->name, "timer%2d", &id);
|
|
|
|
|
ARM: OMAP: Add DMTIMER capability variable to represent timer features
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is always be on.
Another example, is a timer may support different clock sources to drive the
timer. This information is passed to the dmtimer via the following platform data
structure.
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
The above structure uses multiple variables to represent the timer features.
HWMOD also stores the timer capabilities using a bit-mask that represents the
features supported. By using the same format for representing the timer
features in the platform data as used by HWMOD, we can ...
1. Use the flags defined in the plat/dmtimer.h to represent the features
supported.
2. For devices using HWMOD, we can retrieve the features supported from HWMOD.
3. Eventually, simplify the platform data structure to be ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
}
Another benefit from doing this, is that it will simplify the migration of the
dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the
"loses_context" variable is configured at runtime by calling an architecture
specific function. For device tree this creates a problem, because we would need
to call the architecture specific function from within the dmtimer driver.
However, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.
This changes a new "capability" variable to the platform data and timer
structure so we can start removing and simplifying the platform data structure.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-06-06 01:34:52 +08:00
|
|
|
if (timer_dev_attr)
|
|
|
|
pdata->timer_capability = timer_dev_attr->timer_capability;
|
2011-09-22 07:38:51 +08:00
|
|
|
|
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
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>
2012-09-28 01:47:43 +08:00
|
|
|
pdata->timer_errata = omap_dm_timer_get_errata();
|
2012-10-30 06:20:45 +08:00
|
|
|
pdata->get_context_loss_count = omap_pm_get_dev_context_loss_count;
|
|
|
|
|
2013-01-26 15:48:53 +08:00
|
|
|
pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata));
|
2011-09-20 19:30:18 +08:00
|
|
|
|
2011-10-05 00:47:06 +08:00
|
|
|
if (IS_ERR(pdev)) {
|
2011-09-20 19:30:18 +08:00
|
|
|
pr_err("%s: Can't build omap_device for %s: %s.\n",
|
|
|
|
__func__, name, oh->name);
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(pdata);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2011-09-20 19:30:20 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* omap2_dm_timer_init - top level regular device initialization
|
|
|
|
*
|
|
|
|
* Uses dedicated hwmod api to parse through hwmod database for
|
|
|
|
* given class name and then build and register the timer device.
|
|
|
|
*/
|
|
|
|
static int __init omap2_dm_timer_init(void)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
2012-05-14 23:41:37 +08:00
|
|
|
/* If dtb is there, the devices will be created dynamically */
|
|
|
|
if (of_have_populated_dt())
|
|
|
|
return -ENODEV;
|
|
|
|
|
2011-09-20 19:30:20 +08:00
|
|
|
ret = omap_hwmod_for_each_by_class("timer", omap_timer_init, NULL);
|
|
|
|
if (unlikely(ret)) {
|
|
|
|
pr_err("%s: device registration failed.\n", __func__);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-12 03:24:18 +08:00
|
|
|
omap_arch_initcall(omap2_dm_timer_init);
|
ARM: OMAP: Make OMAP clocksource source selection using kernel param
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.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AMXXXX continue to use the same code.
And, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also 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.
Also, moved low-level SoC specific init code to respective files,
(mach-omap1/timer32k.c and mach-omap2/timer.c)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10 01:07:05 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* omap2_override_clocksource - clocksource override with user configuration
|
|
|
|
*
|
|
|
|
* Allows user to override default clocksource, using kernel parameter
|
|
|
|
* clocksource="gp_timer" (For all OMAP2PLUS architectures)
|
|
|
|
*
|
|
|
|
* Note that, here we are using same standard kernel parameter "clocksource=",
|
|
|
|
* and not introducing any OMAP specific interface.
|
|
|
|
*/
|
|
|
|
static int __init omap2_override_clocksource(char *str)
|
|
|
|
{
|
|
|
|
if (!str)
|
|
|
|
return 0;
|
|
|
|
/*
|
|
|
|
* For OMAP architecture, we only have two options
|
|
|
|
* - sync_32k (default)
|
|
|
|
* - gp_timer (sys_clk based)
|
|
|
|
*/
|
|
|
|
if (!strcmp(str, "gp_timer"))
|
|
|
|
use_gptimer_clksrc = true;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("clocksource", omap2_override_clocksource);
|