1. 26 7月, 2012 1 次提交
  2. 09 7月, 2012 1 次提交
  3. 06 7月, 2012 1 次提交
    • T
      ARM: OMAP2+: dmtimer: cleanup fclk usage · ae6df418
      Tarun Kanti DebBarma 提交于
      With omap_hwmod_get_main_clk() now available, this can be passed to
      clk_get() to extract the fclk and thus avoid construction of fclk name.
      Corrected the timer fck name mis-match between clock44xx_data.c and
      omap_hwmod_44xx_data.c. For other platforms this is already taken care.
      
      Cc: Cousson, Benoit <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTarun Kanti DebBarma <tarun.kanti@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ae6df418
  4. 14 6月, 2012 7 次提交
    • J
      ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver · 2b2d3523
      Jon Hunter 提交于
      OMAP1 uses an architecture specific function for setting the dmtimer clock
      source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
      device should also use the clock framework and hence we should not any
      architecture specific functions.
      
      For now move the OMAP2+ function for configuring the clock source into the
      dmtimer driver. Therefore, we do no longer need to specify an architecture
      specific function for setting the clock source for OMAP2+ devices. This will
      simplify device tree migration of the dmtimers for OMAP2+ devices.
      
      From now on, only OMAP1 devices should specify an architecture specific
      function for setting the clock source via the platform data set_dmtimer_src()
      function pointer.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2b2d3523
    • J
      ARM: OMAP: Remove timer function pointer for context loss counter · 0b30ec1c
      Jon Hunter 提交于
      For OMAP2+ devices, a function pointer that returns the number of times a timer
      power domain has lost context is passed to the dmtimer driver. This function
      pointer is only populated for OMAP2+ devices and it is pointing to a platform
      function. Given that this is a platform function, we can simplify the code by
      removing the function pointer and referencing the function directly. We can use
      the OMAP_TIMER_ALWON flag to determine if we need to call this function for
      OMAP1 and OMAP2+ devices.
      
      The benefit of this change is the we can remove the function pointer from the
      platform data and simplifies the dmtimer migration to device-tree.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      0b30ec1c
    • J
      ARM: OMAP: Remove loses_context variable from timer platform data · 1c2d076b
      Jon Hunter 提交于
      The platform data variable loses_context is used to determine if the timer may
      lose its logic state during power transitions and so needs to be restored. This
      information is also provided in the HWMOD device attributes for OMAP2+ devices
      via the OMAP_TIMER_ALWON flag. When this flag is set the timer will not lose
      context. So use the HWMOD device attributes to determine this.
      
      For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
      flag for OMAP1 timers to ensure that code is equivalent.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1c2d076b
    • J
      ARM: OMAP2+: Fix external clock support for dmtimers · 67d2e760
      Jon Hunter 提交于
      Currently, the dmtimer determines whether an timer can support an external
      clock source (sys_altclk) for driving the timer by the IP version. Only
      OMAP24xx devices can support an external clock source, but the IP version
      between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
      that OMAP3 devices can use an external clock source.
      
      Rather than use the IP version, just let the clock framework handle this.
      If the "alt_ck" does not exist for a timer then the clock framework will fail
      to find the clock and hence will return an error. By doing this we can eliminate
      the "timer_ip_version" variable passed as part of the platform data and simplify
      the code.
      
      We can also remove the timer IP version from the HWMOD data because the dmtimer
      driver uses the TIDR register to determine the IP version.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      67d2e760
    • J
      ARM: OMAP: Add DMTIMER capability variable to represent timer features · d1c1691b
      Jon Hunter 提交于
      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: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      d1c1691b
    • J
      ARM: OMAP2+: Add dmtimer platform function to reserve systimers · b7b4ff76
      Jon Hunter 提交于
      During early boot, one or two dmtimers are reserved by the kernel as system
      timers (for clocksource and clockevents). These timers are marked as reserved
      and the dmtimer driver is notified which timers have been reserved via the
      platform data information.
      
      For OMAP2+ devices the timers reserved may vary depending on device and compile
      flags. Therefore, it is not easy to assume which timers we be reserved for the
      system timers. In order to migrate the dmtimer driver to support device-tree we
      need a way to pass the timers reserved for system timers to the dmtimer driver.
      Using the platform data structure will not work in the same way as it is
      currently used because the platform data structure will be stored statically in
      the dmtimer itself and the platform data will be selected via the device-tree
      match device function (of_match_device).
      
      There are a couple ways to workaround this. One option is to store the system
      timers reserved for the kernel in the device-tree and query them on boot.
      The downside of this approach is that it adds some delay to parse the DT blob
      to search for the system timers. Secondly, for OMAP3 devices we have a
      dependency on compile time flags and the device-tree would not be aware of that
      kernel compile flags and so we would need to address that.
      
      The second option is to add a function to the dmtimer code to reserved the
      system timers during boot and so the dmtimer knows exactly which timers are
      being used for system timers. This also allows us to remove the "reserved"
      member from the timer platform data. This seemed like the simpler approach and
      so was implemented here.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b7b4ff76
    • J
      ARM: OMAP2+: Remove unused max number of timers definition · 26fe4e45
      Jon Hunter 提交于
      The OMAP2+ timer code has a definition for the maximum number of timers that
      OMAP2+ devices have. This defintion is not used anywhere in the code and
      appears to be left over. Furthermore the definition is not accurate for OMAP4
      devices that only have 11 timers available because the 12th timer is reserved
      as a secure timer and for OMAP3 devices the 12th timer is not available on
      secure devices. Therefore, remove this definition.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      26fe4e45
  5. 05 6月, 2012 1 次提交
  6. 10 5月, 2012 2 次提交
    • V
      ARM: OMAP: Make OMAP clocksource source selection using kernel param · 1fe97c8f
      Vaibhav Hiremath 提交于
      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: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin 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: NTony Lindgren <tony@atomide.com>
      1fe97c8f
    • V
      ARM: OMAP2+: Replace space with underscore in the name field of system timers · f36921be
      Vaibhav Hiremath 提交于
      Depending on the bootloader, passing command-line arguments
      with spaces may have issues. Some bootloaders doesn't seem
      to pass along the quotes, passing only 'gp' part of the string,
      which leads to wrong override configuration.
      
      The only affected kernel parameter configuration for OMAP family
      is "clocksource=", used to override kernel clocksource.
      
      So this patch changes "gp timer" => "gp_timer", for clockevent,
      clocksource and timer irq_handler.
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      f36921be
  7. 08 5月, 2012 1 次提交
  8. 19 4月, 2012 1 次提交
  9. 13 3月, 2012 1 次提交
  10. 27 1月, 2012 1 次提交
    • V
      ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter · dbc3982a
      Vaibhav Hiremath 提交于
      Commit 2f0778af (ARM: 7205/2: sched_clock: allow sched_clock to be
      selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
      is not set.
      
      In dmtimer_read_sched_clock(), wrong argument was getting passed to
      __omap_dm_timer_read_counter() function call; instead of "&clksrc",
      we were passing "clksrc.io_base", which results into kernel crash.
      
      To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
      option (and DEBUG_LL) and build/boot the kernel.
      This will use dmtimer as a kernel clocksource and lead to kernel
      crash during boot  -
      
      [    0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
      [    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
      165191ms
      [    0.000000] Unable to handle kernel paging request at virtual address
      00030ef1
      [    0.000000] pgd = c0004000
      [    0.000000] [00030ef1] *pgd=00000000
      [    0.000000] Internal error: Oops: 5 [#1] SMP
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (3.3.0-rc1-11574-g0c76665-dirty #3)
      [    0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
      [    0.000000] LR is at update_sched_clock+0x10/0x84
      [    0.000000] pc : [<c00243b8>]    lr : [<c0018684>]    psr: 200001d3
      [    0.000000] sp : c0641f38  ip : c0641e18  fp : 0000000a
      [    0.000000] r10: 151c3303  r9 : 00000026  r8 : 76276259
      [    0.000000] r7 : 00028547  r6 : c065ac80  r5 : 431bde82  r4 : c0655968
      [    0.000000] r3 : 00030ef1  r2 : fb032000  r1 : 00000028  r0 : 00000001
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      [tony@atomide.com: updated comments]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc3982a
  11. 19 12月, 2011 1 次提交
  12. 18 11月, 2011 1 次提交
  13. 05 11月, 2011 1 次提交
  14. 22 9月, 2011 4 次提交
  15. 20 9月, 2011 1 次提交
  16. 10 8月, 2011 1 次提交
  17. 28 6月, 2011 4 次提交
  18. 20 6月, 2011 3 次提交
  19. 01 3月, 2011 1 次提交
    • P
      OMAP2+: clockevent: set up GPTIMER clockevent hwmod right before timer init · 38698bef
      Paul Walmsley 提交于
      Set up the GPTIMER hwmod used for the clockevent source immediately
      before it is used.  This avoids the need to set up all of the hwmods
      until the boot process is further along.  (In general, we want to defer
      as much as possible until late in the boot process.)
      
      This second version fixes a bug pointed out by Santosh Shilimkar
      <santosh.shilimkar@ti.com>, that would cause the kernel to use an
      incorrect timer hwmod name if the selected GPTIMER was not 1 or 12 -
      thanks Santosh.  Also, Tarun Kanti DebBarma <tarun.kanti@ti.com>
      pointed out that the original patch did not apply cleanly; this has
      now been fixed.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
      38698bef
  20. 25 2月, 2011 1 次提交
    • P
      OMAP2+: clocksource: fix crash on boot when !CONFIG_OMAP_32K_TIMER · cbc94380
      Paul Walmsley 提交于
      
      OMAP2+ kernels built without CONFIG_OMAP_32K_TIMER crash on boot after the
      2.6.38 sched_clock changes:
      
      [    0.000000] OMAP clockevent source: GPTIMER1 at 13000000 Hz
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    0.000000] pgd = c0004000
      [    0.000000] [00000000] *pgd=00000000
      [    0.000000] Internal error: Oops: 80000005 [#1] SMP
      [    0.000000] last sysfs file:
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Not tainted  (2.6.38-rc5-00057-g04aa67de #152)
      [    0.000000] PC is at 0x0
      [    0.000000] LR is at sched_clock_poll+0x2c/0x3c
      
      Without CONFIG_OMAP_32K_TIMER, the kernel has an clockevent and
      clocksource resolution about three orders of magnitude higher than
      with CONFIG_OMAP_32K_TIMER set.  The tradeoff is that the lowest
      power consumption states are not available.
      
      Fix by calling init_sched_clock() from the GPTIMER clocksource init code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      cbc94380
  21. 19 1月, 2011 1 次提交
    • P
      OMAP: counter_32k: init clocksource as part of machine timer init · d8328f3b
      Paul Walmsley 提交于
      After commit dc548fbb ("ARM: omap: convert
      sched_clock() to use new infrastructure"), OMAPs that use the 32KiHz
      "synchronization timer" as their clocksource crash during boot:
      
      [    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
      [    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [    0.000000] pgd = c0004000
      [    0.000000] [00000000] *pgd=00000000
      [    0.000000] Internal error: Oops: 80000005 [#1] SMP
      [    0.000000] last sysfs file:
      [    0.000000] Modules linked in:
      [    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
      [    0.000000] PC is at 0x0
      [    0.000000] LR is at sched_clock_poll+0x2c/0x3c
      [    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
      [    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
      [    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
      [    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
      [    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
      [    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      [    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017
      
      This is due to the recent ARM init_sched_clock() changes and the late
      initialization of the counter_32k clock source.  More information here:
      
         http://marc.info/?l=linux-omap&m=129513468605208&w=2
      
      Fix by initializing the counter_32k clocksource during the machine timer
      initialization.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NThomas Weber <weber@corscience.de>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      d8328f3b
  22. 23 12月, 2010 1 次提交
  23. 25 11月, 2010 1 次提交
  24. 09 10月, 2010 1 次提交
    • M
      OMAP2plus: Fix static function warnings · 04aeae77
      Manjunath Kondaiah G 提交于
      This patch fixes sparse warnings due non declarations of static functions.
      
      arch/arm/mach-omap2/timer-gp.c:115:12: warning: symbol 'omap2_gp_clockevent_set_gptimer' was not declared. Should it be static?
      arch/arm/mach-omap2/powerdomain.c:993:5: warning: symbol 'pwrdm_set_lowpwrstchange' was not declared. Should it be static?
      arch/arm/mach-omap2/board-flash.c:141:8: warning: symbol 'board_nand_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-n8x0.c:416:6: warning: symbol 'n8x0_mmc_slot1_cover_handler' was not declared. Should it be static?
      arch/arm/mach-omap2/board-n8x0.c:544:13: warning: symbol 'n8x0_mmc_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-peripherals.c:902:13: warning: symbol 'rx51_peripherals_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-video.c:107:13: warning: symbol 'rx51_video_mem_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-zoom-debugboard.c:155:12: warning: symbol 'zoom_debugboard_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-zoom-peripherals.c:280:13: warning: symbol 'zoom_peripherals_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-igep0020.c:110:13: warning: symbol 'igep2_flash_init' was not declared. Should it be static?
      arch/arm/mach-omap2/board-am3517evm.c:109:6: warning: symbol 'am3517_evm_ethernet_init' was not declared. Should it be static?
      drivers/mtd/onenand/omap2.c:577:5: warning: symbol 'omap2_onenand_rephase' was not declared. Should it be static?
      Signed-off-by: NManjunath Kondaiah G <manjugk@ti.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Nishanth Menon <nm@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      04aeae77
  25. 21 9月, 2010 1 次提交