1. 23 Apr, 2013 1 commit
  2. 11 Apr, 2013 1 commit
    • Rob Herring's avatar
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init · 0583fe47
      Rob Herring authored
      This converts arm and arm64 to use CLKSRC_OF DT based initialization for
      the arch timer. A new function arch_timer_arch_init is added to allow for
      arch specific setup.
      This has a side effect of enabling sched_clock on omap5 and exynos5. There
      should not be any reason not to use the arch timers for sched_clock.
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
  3. 01 Apr, 2013 7 commits
    • Jon Hunter's avatar
      ARM: OMAP4+: Fix sparse warning in system timers · 4615943c
      Jon Hunter authored
      Commit 6bb27d73
       (ARM: delete struct sys_timer) changed the function
      created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void.
      For OMAP4+ devices this created the following sparse warning ...
      arch/arm/mach-omap2/timer.c:585:1: warning: symbol
      	'omap4_sync32k_timer_init' was not declared. Should it be static?
      The function omap4_sync32k_timer_init() is not referenced outside of the
      file timer.c and so make this function static.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP2+: Store ID of system timers in timer structure · 8f6924dc
      Jon Hunter authored
      Currently, the timer ID is being passed to the function
      omap_dm_timer_init_one(). Instead of passing the ID separately, store it
      in the omap_dm_timer structure, that is also passed, and access the ID
      from this structure.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP3: Update clocksource timer selection · 2eb03937
      Jon Hunter authored
      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
      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: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
    • Jon Hunter's avatar
      ARM: OMAP2+: Simplify system timers definitions · 00ea4d56
      Jon Hunter authored
      There is a lot of redundancy in the definitions for the various system
      timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
      function is the same as the omap3_gp_gptimer_timer_init() function and the
      function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
      Therefore, consolidate the definitions to simplify the code.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
    • Jon Hunter's avatar
      ARM: OMAP2+: Simplify system timer clock definitions · 7bdc83f7
      Jon Hunter authored
      In commit c59b537d
       (ARM: OMAP2+: Simplify dmtimer clock aliases), new
      clock aliases for dmtimers were added to simplify the code. These clock
      aliases can also be used when configuring the system timers and allow us
      to remove the current definitions, simplifying the code.
      Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
      no clock alias for "timer_sys_ck" with NULL as the device name. Therefore
      we still need to use the alias "sys_clkin_ck" for these devices.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP2+: Remove hard-coded test on timer ID · a7990a19
      Jon Hunter authored
      Currently, when configuring the clock-events and clock-source timers
      for OMAP2+ devices, we check whether the timer ID is 12 before
      attempting to set the parent clock for the timer.
      This test was added for OMAP3 general purpose devices (no security
      features enabled) that a 12th timer available but unlike the other
      timers only has a single functional clock source. Calling
      clk_set_parent() for this 12th timer would always return an error
      because there is only one choice for a parent clock. Therefore,
      this hard-coded timer ID test was added.
      To avoid this timer ID test, simply check to see if the timer's current
      parent clock is the desired parent clock and only call clk_set_parent()
      if this is not the case.
      Also if clk_get() fails, then use PTR_ERR() to return the error code.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP2+: Display correct system timer name · e95ea43a
      Jon Hunter authored
      Currently on boot, when displaying the name of the gptimer used for
      clockevents and clocksource timers, the timer ID is shown. However,
      when booting with device-tree, the timer ID is not used to select a
      gptimer but a timer property. Hence, it is possible that the timer
      selected when booting with device-tree does not match the ID shown.
      Therefore, instead display the HWMOD name of the gptimer and use
      the HWMOD name as the name of clockevent and clocksource timer (if a
      gptimer is used).
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
  4. 19 Mar, 2013 1 commit
  5. 13 Mar, 2013 1 commit
    • Russell King's avatar
      ARM: OMAP: use consistent error checking · 71856843
      Russell King authored
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      	return gpmc_cs_set_timings(cs, t);
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  6. 11 Mar, 2013 1 commit
  7. 01 Feb, 2013 1 commit
  8. 26 Jan, 2013 1 commit
    • Paul Walmsley's avatar
      ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code · c1d1cd59
      Paul Walmsley authored
      Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c.  This
      mostly consists of removing the first attempt at device PM latency
      handling.  This was never really used, has been replaced by the common
      dev_pm_qos code, and needs to go away as part of the DT conversion.
      Also, the early platform_device creation code has been removed, as it
      appears to be unused.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
  9. 21 Jan, 2013 1 commit
    • Pantelis Antoniou's avatar
      ARM: OMAP2+: DT node Timer iteration fix · 034bf091
      Pantelis Antoniou authored
      The iterator correctly handles of_node_put() calls.
      Remove it before continue'ing the loop.
      Without this patch you get the following with
      ERROR: Bad of_node_put() on /ocp/timer@44e31000!
      [<c001329c>] (unwind_backtrace+0x0/0xe0) from [<c03dd8f0>] (of_node_release+0x2c/0xa0)!
      [<c03dd8f0>] (of_node_release+0x2c/0xa0) from [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90)!
      [<c03ddea0>] (of_find_matching_node_and_match+0x78/0x90) from [<c06d349c>] (omap_get_timer_dt+0x78/0x90)!
      [<c06d349c>] (omap_get_timer_dt+0x78/0x90) from [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
      [<c06d3664>] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
      [<c06d3a2c>] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from [<c06cca58>] (time_init+0x20/0x30)!
      [<c06cca58>] (time_init+0x20/0x30) from [<c06c9690>] (start_kernel+0x1a8/0x2fc)!
      Signed-off-by: default avatarPantelis Antoniou <panto@antoniou-consulting.com>
      Acked-by: default avatarJon Hunter <jon-hunter@ti.com>
      [tony@atomide.com: updated description per Jon]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  10. 14 Jan, 2013 1 commit
  11. 11 Jan, 2013 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP2+: Use omap initcalls · b76c8b19
      Tony Lindgren authored
      This way the initcalls don't run on other SoCs on multiplatform
      kernels. Otherwise we'll get something like this when booting
      on vexpress:
      omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
      WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
      _init_omap_device: could not find omap_hwmod for mpu
      omap-dma-engine omap-dma-engine: OMAP DMA engine driver
      Tested-by: default avatarEzequiel Garcia <ezequiel.garcia@free-electrons.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  12. 24 Dec, 2012 1 commit
  13. 20 Dec, 2012 1 commit
  14. 14 Dec, 2012 2 commits
    • Vaibhav Hiremath's avatar
      ARM: OMAP2+: Fix sparse warnings in timer.c · bf85f205
      Vaibhav Hiremath authored
      Sparse generates the following warnings when compiling mach-omap2/timer.c.
        CHECK   arch/arm/mach-omap2/timer.c
        arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
        was not declared. Should it be static?
        arch/arm/mach-omap2/timer.c:213:12: warning: symbol
        'omap_dm_timer_get_errata' was not declared. Should it be static?
      Add static to function declaration to fix warnings.
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
    • Jon Hunter's avatar
      ARM: AM335x: Fix warning in timer.c · e0c3e27c
      Jon Hunter authored
      When compiling the kernel with configuration options ...
       # CONFIG_ARCH_OMAP2 is not set
       # CONFIG_ARCH_OMAP3 is not set
       # CONFIG_ARCH_OMAP4 is not set
       # CONFIG_SOC_OMAP5 is not set
       ... the following build warning is seen.
        CC      arch/arm/mach-omap2/timer.o
        arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
        	defined but not used [-Wunused-function]
      This issue was introduced by commit 6f80b3bb
       (ARM: OMAP2+: timer: remove
      CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
      longer referenced by the timer initialisation function for the AM335x
      device as it has no 32k-sync timer.
      Fix this by adding the "__maybe_unused" compiler directive to the
      omap2_sync32k_clocksource_init() function to indicate that this function
      may be used for certain configurations.
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
  15. 30 Nov, 2012 1 commit
    • Olof Johansson's avatar
      ARM: omap: fix typo on timer cleanup · 73f14f6d
      Olof Johansson authored
      Fix 32 vs 32k typo:
      arch/arm/mach-omap2/timer.c: In function 'omap4_local_timer_init':
      arch/arm/mach-omap2/timer.c:633:2: error: implicit declaration of function 'omap4_sync32_timer_init' [-Werror=implicit-function-declaration]
      arch/arm/mach-omap2/timer.c: At top level:
      arch/arm/mach-omap2/timer.c:610:2: warning: 'omap4_sync32k_timer_init' defined but not used [-Wunused-function]
      Also, mark the omap4_local_timer_init() stub as __init (and take off
      the explicit inline and let the compiler do the work instead).
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
  16. 21 Nov, 2012 2 commits
    • Igor Grinberg's avatar
      ARM: OMAP3: cm-t3517: use GPTIMER for system clock · 26f01998
      Igor Grinberg authored
      cm-t3517 starting from revision 1.2 does not have the 32K oscilator
      wired to the AM3517 SoC.
      Therefore switch to use the GPTIMER for system clock.
      Signed-off-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
    • Igor Grinberg's avatar
      ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER · 6f80b3bb
      Igor Grinberg authored
      CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
      Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
      To remove the dependancy, several conversions/additions had to be done:
      1) Timer initialization functions are named by the platform
         name and the clock source in use.
         This also makes it possible to define and use the GPTIMER as the
         clock source instead of the 32K timer on platforms that do not have
         the 32K timer ip block or the 32K timer is not wired on the board.
         Currently, the the timer is chosen in the machine_desc structure on
         per board basis. Later, DT should be used to choose the timer.
      2) Settings under the CONFIG_OMAP_32K_TIMER option are used as defaults
         and those under !CONFIG_OMAP_32K_TIMER are removed.
         This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
      3) Since we have all the timers defined inside machine_desc structure
         and we no longer need the fallback to gp_timer clock source in case
         32k_timer clock source is unavailable (namely on AM33xx), we no
         longer need the #ifdef around omap2_sync32k_clocksource_init()
         function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
         omap2_sync32k_clocksource_init() function.
      Signed-off-by: default avatarIgor Grinberg <grinberg@compulab.co.il>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Vaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: default avatarJon Hunter <jon-hunter@ti.com>
  17. 16 Nov, 2012 4 commits
  18. 12 Nov, 2012 4 commits
    • Jon Hunter's avatar
      ARM: OMAP: Remove __omap_dm_timer_set_source function · b1538832
      Jon Hunter authored
      The __omap_dm_timer_set_source() function is only used by the system timer
      (clock-events and clock-source) code for OMAP2+ devices. Therefore, we can
      remove this code from the dmtimer driver and move it to the system timer
      code for OMAP2+ devices.
      The current __omap_dm_timer_set_source() function calls clk_disable() before
      calling clk_set_parent() and clk_enable() afterwards. We can avoid these calls
      to clk_disable/enable by moving the calls to omap_hwmod_setup_one() and
      omap_hwmod_enable() to after the call to clk_set_parent() in
      The function omap_hwmod_setup_one() will enable the timers functional clock
      and therefore increment the use-count of the functional clock to 1.
      clk_set_parent() will fail if the use-count is not 0 when called. Hence, if
      omap_hwmod_setup_one() is called before clk_set_parent(), we will need to call
      clk_disable() before calling clk_set_parent() to decrement the use-count.
      Hence, avoid these extra calls to disable and enable the functional clock by
      moving the calls to omap_hwmod_setup_one() and omap_hwmod_enable() to after
      We can also remove the delay from the __omap_dm_timer_set_source() function
      because enabling the clock will now be handled via the HWMOD framework by
      calling omap_hwmod_setup_one(). Therefore, by moving the calls to
      omap_hwmod_setup_one() and omap_hwmod_enable() to after the call to
      clk_set_parent(), we can simply replace __omap_dm_timer_set_source() with
      It should be safe to move these hwmod calls to later in the
      omap_dm_timer_init_one() because other calls to the hwmod layer that occur
      before are just requesting resource information.
      Testing includes boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 Blaze
      with the following configurations:
      1. CONFIG_OMAP_32K_TIMER=y
      2. CONFIG_OMAP_32K_TIMER=y and boot parameter "clocksource=gp_timer"
      3. CONFIG_OMAP_32K_TIMER not set
      4. CONFIG_OMAP_32K_TIMER not set and boot parameter "clocksource=gp_timer"
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP2+: Don't use __omap_dm_timer_reset() · 10759e82
      Jon Hunter authored
      Currently OMAP2+ devices are using the function __omap_dm_timer_reset() to
      configure the clock-activity, idle, wakeup-enable and auto-idle fields in the
      timer OCP_CFG register. The name of the function is mis-leading because this
      function does not actually perform a reset of the timer.
      For OMAP2+ devices, HWMOD is responsible for reseting and configuring the
      timer OCP_CFG register. Therefore, do not use __omap_dm_timer_reset() for
      OMAP2+ devices and rely on HWMOD. Furthermore, some timer instances do not
      have the fields clock-activity, wakeup-enable and auto-idle and so this
      function could configure the OCP_CFG register incorrectly.
      Currently HWMOD is not configuring the clock-activity field in the OCP_CFG
      register for timers that have this field. Commit 0f0d0807
       (ARM: OMAP: DMTimer:
      Use posted mode) configures the clock-activity field to keep the f-clk enabled
      so that the wake-up capability is enabled. Therefore, add the appropriate flags
      to the timer HWMOD structures to configure this field in the same way.
      For OMAP2/3 devices all dmtimers have the clock-activity field, where as for
      OMAP4 devices, only dmtimer 1, 2 and 10 have the clock-activity field.
      Verified on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
      configuring the dmtimer OCP_CFG register as expected for clock-events timer.
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP3+: Implement timer workaround for errata i103 and i767 · bfd6d021
      Jon Hunter authored
      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
      GPTimer non-posted synchronization mode is not impacted by this
      1). Disable posted mode
      2). Use static dependency between timer clock domain and MPUSS clock
      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);
      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
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP: Add DMTIMER definitions for posted mode · 971d0254
      Jon Hunter authored
      For OMAP2+ devices, when using DMTIMERs for system timers (clock-events and
      clock-source) the posted mode configuration of the timers is used. To allow
      the compiler to optimise the functions for configuring and reading the system
      timers, the posted flag variable is hard-coded with the value 1. To make it
      clear that posted mode is being used add some definitions so that it is more
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
  19. 02 Nov, 2012 3 commits
    • Jon Hunter's avatar
      ARM: OMAP2+: Add device-tree support for 32kHz counter · 9883f7c8
      Jon Hunter authored
      For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
      However, this is not the only possible clock-source the kernel can use for OMAP
      When booting with device-tree, if the 32kHz counter is the desired clock-source
      for the kernel, then parse the device-tree blob to ensure that the counter is
      present and if so map memory for the counter using the device-tree of_iomap()
      function so we are no longer reliant on the OMAP HWMOD framework to do this for
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP: Add DT support for timer driver · 9725f445
      Jon Hunter authored
      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
      3. If DT blob is present, then let device-tree create the timer devices
      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
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
    • Jon Hunter's avatar
      ARM: OMAP3: Dynamically disable secure timer nodes for secure devices · ad24bde8
      Jon Hunter authored
      OMAP3 devices may or may not have security features enabled. Security enabled
      devices are known as high-secure (HS) and devices without security are known as
      general purpose (GP).
      For OMAP3 devices there are 12 general purpose timers available. On secure
      devices the 12th timer is reserved for secure usage and so cannot be used by
      the kernel, where as for a GP device it is available. We can detect the OMAP
      device type, secure or GP, at runtime via an on-chip register. Today, when not
      using DT, we do not register the 12th timer as a linux device if the device is
      When using device tree, device tree is going to register all the timer devices
      it finds in the device tree blob. To prevent device tree from registering 12th
      timer on a secure OMAP3 device we can add a status property to the timer
      binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
      device has a property "ti,timer-secure" to indicate that it will not be
      available on a secure device and so for secure OMAP3 devices, we search for
      timers with this property and then disable them. Using the prom_add_property()
      function to dynamically add a property was a recommended approach suggested by
      Rob Herring [1].
      I have tested this on an OMAP3 GP device and faking it to pretend to be a
      secure device to ensure that any timers marked with "ti,timer-secure" are not
      registered on boot. I have also made sure that all timers are registered as
      expected on a GP device by default.
      [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
      Signed-off-by: default avatarJon Hunter <jon-hunter@ti.com>
  20. 31 Oct, 2012 2 commits
    • Tony Lindgren's avatar
      ARM: OMAP: Remove plat-omap/common.h · 5c2e8852
      Tony Lindgren authored
      Most of the prototypes in plat-omap/common.h are not
      common to omap1 and omap2+, they are local to omap2+
      and should not be in plat-omap/common.h.
      The only shared function prototype in this file is
      omap_init_clocksource_32k(), let's put that into
      Note that the new plat/counter-32k.h must not be
      included from drivers, that will break omap2+ build
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
    • Tony Lindgren's avatar
      ARM: OMAP: Move omap-pm-noop.c local to mach-omap2 · 6e740f9a
      Tony Lindgren authored
      This code should be private to mach-omap2.
      The only use for it in for omap1 has been in dmtimer.c
      to check for context loss. However, omap1 does not
      lose context during idle, so the code is not needed.
      Further, omap1 timer has OMAP_TIMER_ALWON set, so omap1
      was not hitting omap_pm_get_dev_context_loss_count()
      Cc: Jon Hunter <jon-hunter@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  21. 18 Oct, 2012 2 commits
  22. 17 Oct, 2012 1 commit