linux_dsm_epyc7002/arch/arm/plat-omap/counter_32k.c

124 lines
3.6 KiB
C
Raw Normal View History

/*
* OMAP 32ksynctimer/counter_32k-related code
*
* Copyright (C) 2009 Texas Instruments
* Copyright (C) 2010 Nokia Corporation
* Tony Lindgren <tony@atomide.com>
* Added OMAP4 support - Santosh Shilimkar <santosh.shilimkar@ti.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* NOTE: This timer is not the same timer as the old OMAP1 MPU timer.
*/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/io.h>
#include <linux/clocksource.h>
#include <linux/sched_clock.h>
#include <asm/mach/time.h>
#include <plat/counter-32k.h>
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 00:07:05 +07:00
/* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */
#define OMAP2_32KSYNCNT_REV_OFF 0x0
#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30
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 00:07:05 +07:00
/*
* 32KHz clocksource ... always available, on pretty most chips except
* OMAP 730 and 1510. Other timers could be used as clocksources, with
* higher resolution in free-running counter modes (e.g. 12 MHz xtal),
* but systems won't necessarily want to spend resources that way.
*/
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 00:07:05 +07:00
static void __iomem *sync32k_cnt_reg;
static u64 notrace omap_32k_read_sched_clock(void)
{
return sync32k_cnt_reg ? readl_relaxed(sync32k_cnt_reg) : 0;
}
/**
* omap_read_persistent_clock - Return time from a persistent clock.
*
* Reads the time from a source which isn't disabled during PM, the
* 32k sync timer. Convert the cycles elapsed since last read into
* nsecs and adds to a monotonically increasing timespec.
*/
static struct timespec persistent_ts;
static cycles_t cycles;
static unsigned int persistent_mult, persistent_shift;
static DEFINE_SPINLOCK(read_persistent_clock_lock);
static void omap_read_persistent_clock(struct timespec *ts)
{
unsigned long long nsecs;
cycles_t last_cycles;
unsigned long flags;
spin_lock_irqsave(&read_persistent_clock_lock, flags);
last_cycles = cycles;
cycles = sync32k_cnt_reg ? readl_relaxed(sync32k_cnt_reg) : 0;
nsecs = clocksource_cyc2ns(cycles - last_cycles,
persistent_mult, persistent_shift);
timespec_add_ns(&persistent_ts, nsecs);
*ts = persistent_ts;
spin_unlock_irqrestore(&read_persistent_clock_lock, flags);
}
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 00:07:05 +07:00
/**
* omap_init_clocksource_32k - setup and register counter 32k as a
* kernel clocksource
* @pbase: base addr of counter_32k module
* @size: size of counter_32k to map
*
* Returns 0 upon success or negative error code upon failure.
*
*/
int __init omap_init_clocksource_32k(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 00:07:05 +07:00
int ret;
/*
* 32k sync Counter IP register offsets vary between the
* highlander version and the legacy ones.
* The 'SCHEME' bits(30-31) of the revision register is used
* to identify the version.
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 00:07:05 +07:00
*/
if (readl_relaxed(vbase + OMAP2_32KSYNCNT_REV_OFF) &
OMAP2_32KSYNCNT_REV_SCHEME)
sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH;
else
sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW;
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 00:07:05 +07:00
/*
* 120000 rough estimate from the calculations in
* __clocksource_updatefreq_scale.
*/
clocks_calc_mult_shift(&persistent_mult, &persistent_shift,
32768, NSEC_PER_SEC, 120000);
ret = clocksource_mmio_init(sync32k_cnt_reg, "32k_counter", 32768,
250, 32, clocksource_mmio_readl_up);
if (ret) {
pr_err("32k_counter: can't register clocksource\n");
return ret;
}
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 00:07:05 +07:00
sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
arm-soc: cleanups, part 2 More cleanups, continuing an earlier set with omap and samsung specific cleanups. These could not go into the first set because they have dependencies on various other series that in turn depend on the first cleanups. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJPuewtAAoJEIwa5zzehBx3J+gQAJKLV8ga5P3adkPAWEceewhX pBjCgwgegs3V5GWhW3Svwhxpll5Djzzt891sAiZjh5eDZCfWy+CnxDJzyuh4mXok zRIfEVLZOopTVV3B31Uq7e7cYEy61Hm6QY4yLGknjxKrrc4CG3G1puvrbLvm1RiL tlFBdbCwwiLM6pnCyi6BTGKfvrbCgqpdaKSNmVjiwiKjAIvB8v++BsRxXXGWAbVR fq8uyiClIB+xhghhsUBLQ6V+pxF+XrjRnoNtl5tQE4VqUUl81UdbJVDfU3L67Q/V hFBNLf0uwO4ecu7Alyx+/c6Eax0N9tQ5VVtAkSRekKzID2/CoGp9w5JBwjctZNrm LuPvzaq11q/GzkmcVjrJ/U3FIxgFta+v6cY2CYtZAAfmxw4oAgr25eMRKTUHDGoy 1F7SD3KOEqT1OFgrHVM9XLYAHL+5i27dnGsk0Nk4qGYZLYVLJ1nxUUNvxV8jfXyJ AtqlYwm06vQxYLM86nV8g9xHssWBrOrCLEJ51rvjHfG+B5m5BifQlImGsHP1Xhut gnLvak3r4Xkc6ipeROikY0wH/Ss8aE/F0fP0TZMXH9e45eA0EVQEp+qnJOcld5o4 CR63OTD6u9j9TbIbJXmleItkADfcrk2dCHs1tF42+KA9VJJsWxRjj1+S+NfLVihU ScTFTiSPHPXAxWAwJIL1 =7UKB -----END PGP SIGNATURE----- Merge tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull arm-soc cleanups (part 2) from Olof Johansson: "More cleanups, continuing an earlier set with omap and samsung specific cleanups. These could not go into the first set because they have dependencies on various other series that in turn depend on the first cleanups." Fixed up conflicts in arch/arm/plat-omap/counter_32k.c due to commit bd0493eaaf5c: "move read_{boot,persistent}_clock to the architecture level" that changed how the persistent clocks were handled. And trivial conflicts in arch/arm/mach-omap1/common.h due to just independent changes close to each other. * tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (35 commits) ARM: SAMSUNG: merge plat-s5p into plat-samsung ARM: SAMSUNG: move options for common s5p into plat-samsung/Kconfig ARM: SAMSUNG: move setup code for s5p mfc and mipiphy into plat-samsung ARM: SAMSUNG: move platform device for s5p uart into plat-samsung ARM: SAMSUNG: move hr timer for common s5p into plat-samsung ARM: SAMSUNG: move pm part for common s5p into plat-samsung ARM: SAMSUNG: move interrupt part for common s5p into plat-samsung ARM: SAMSUNG: move clock part for common s5p into plat-samsung ARM: S3C24XX: Use common macro to define resources on dev-uart.c ARM: S3C24XX: move common clock init into common.c ARM: S3C24XX: move common power-management code to mach-s3c24xx ARM: S3C24XX: move plat-s3c24xx/dev-uart.c into common.c ARM: S3C24XX: move plat-s3c24xx/cpu.c ARM: OMAP2+: Kconfig: convert SOC_OMAPAM33XX to SOC_AM33XX ARM: OMAP2+: Kconfig: convert SOC_OMAPTI81XX to SOC_TI81XX GPMC: add ECC control definitions ARM: OMAP2+: dmtimer: remove redundant sysconfig context restore ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xx ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505 ARM: OMAP1: Pass dma request lines in platform data to MMC driver ...
2012-05-27 02:31:49 +07:00
register_persistent_clock(NULL, omap_read_persistent_clock);
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 00:07:05 +07:00
pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
return 0;
}