1. 14 6月, 2012 3 次提交
    • 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: OMAP: Remove unnecessary clk structure · b8fd7331
      Jon Hunter 提交于
      In the plat/dmtimer.h there is a structure named "clk" declared. This structure
      is not used and appears to be left over from previous code. Hence, remove this
      unused structure.
      
      Verified that both omap1 and omap2plus kernel configurations build with this
      change.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b8fd7331
  2. 11 5月, 2012 1 次提交
  3. 08 5月, 2012 1 次提交
  4. 13 4月, 2012 1 次提交
    • P
      ARM: OMAP: fix 'using plain integer as NULL pointer' sparse warnings · a7022d60
      Paul Walmsley 提交于
      sparse warns when 0 is passed to a function expecting a pointer argument.
      Resolve these warnings by replacing the 0 with NULL.
      
      arch/arm/plat-omap/include/plat/dmtimer.h:319:34: warning: Using plain integer as NULL pointer
      arch/arm/plat-omap/include/plat/dmtimer.h:324:35: warning: Using plain integer as NULL pointer
      arch/arm/mach-omap2/irq.c:294:22: warning: Using plain integer as NULL pointer
      arch/arm/mach-omap1/board-palmz71.c:292:50: warning: Using plain integer as NULL pointer
      arch/arm/mach-omap1/board-palmz71.c:295:73: warning: Using plain integer as NULL pointer
      arch/arm/mach-omap1/ams-delta-fiq.c:105:63: warning: Using plain integer as NULL pointer
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      a7022d60
  5. 05 11月, 2011 1 次提交
  6. 22 9月, 2011 8 次提交
  7. 20 9月, 2011 1 次提交
  8. 10 7月, 2011 1 次提交
  9. 28 6月, 2011 1 次提交
  10. 20 6月, 2011 5 次提交
  11. 28 2月, 2011 1 次提交
  12. 09 10月, 2010 1 次提交
    • M
      OMAP: mach-omap2: Fix static declaration warnings · 38815733
      Manjunath Kondaiah G 提交于
      This patch fixes sparse warnings due to non declaration of
      static structures and variables.
      
      Sparse warning logs fixed:
      arch/arm/mach-omap2/control.c:88:6: warning: symbol 'omap3_secure_ram_storage' was not declared. Should it be static?
      n
      arch/arm/mach-omap2/timer-gp.c:50:22: warning: symbol 'gptimer_wakeup' was not declared. Should it be static?
      arch/arm/mach-omap2/timer-gp.c:240:18: warning: symbol 'omap_timer' was not declared. Should it be static?
      arch/arm/mach-omap2/prcm.c:121:24: warning: symbol 'prcm_context' was not declared. Should it be static?
      arch/arm/mach-omap2/mux2420.c:510:29: warning: symbol 'omap2420_pop_ball' was not declared. Should it be static?
      arch/arm/mach-omap2/mux2430.c:589:29: warning: symbol 'omap2430_pop_ball' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:934:28: warning: symbol 'omap3_cus_subset' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:1080:29: warning: symbol 'omap3_cus_ball' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:1272:28: warning: symbol 'omap3_cbb_subset' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:1393:29: warning: symbol 'omap3_cbb_ball' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:1603:28: warning: symbol 'omap36xx_cbp_subset' was not declared. Should it be static?
      arch/arm/mach-omap2/mux34xx.c:1821:29: warning: symbol 'omap36xx_cbp_ball' was not declared. Should it be static?
      arch/arm/mach-omap2/pm-debug.c:165:15: warning: symbol 'pm_dbg_dir' was not declared. Should it be static?
      arch/arm/mach-omap2/board-omap3evm.c:587:30: warning: symbol 'ads7846_config' was not declared. Should it be static?
      arch/arm/mach-omap2/board-omap3evm.c:606:23: warning: symbol 'omap3evm_spi_board_info' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-sdram.c:46:25: warning: symbol 'rx51_sdrc_params' was not declared. Should it be static?
      arch/arm/mach-omap2/board-rx51-sdram.c:211:25: warning: symbol 'rx51_get_sdram_timings' was not declared. Should it be static?
      arch/arm/mach-omap2/board-omap3touchbook.c:64:15: warning: symbol 'touchbook_revision' was not declared. Should it be static?
      arch/arm/mach-omap2/board-am3517evm.c:350:24: warning: symbol 'am3517_evm_dss_device' was not declared. Should it be static?
      arch/arm/mach-omap2/board-omap3stalker.c:567:23: warning: symbol 'omap3stalker_spi_board_info' 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>
      38815733
  13. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  14. 24 4月, 2009 1 次提交
    • P
      OMAP2/3 GPTIMER: allow system tick GPTIMER to be changed in board-*.c files · f248076c
      Paul Walmsley 提交于
      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: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: Kalle Valo <kalle.valo@nokia.com>
      f248076c
  15. 07 8月, 2008 1 次提交
  16. 03 7月, 2008 1 次提交
    • R
      ARM: OMAP: DMTimer: Optimize by adding load and start · 3fddd09e
      Richard Woodruff 提交于
      This patch optimizes the timer load and start sequence.  By combining the
      load and start a needless posted wait can be removed from the system timer
      execution path.
      
      * Before patch register writes are taking up .078% @ 500MHz during idle.
      
       Address                 |total  |min  |max      |avr     |count|ratio%
       old\process\default_idle|7.369s |0.0us|999.902ms|14.477ms|509. |62.661%
       ld\Global\cpu_v7_do_idle|4.265s |0.0us|375.786ms|24.374ms|175. |36.270%
                      (UNKNOWN)|17.503ms|0.us|531.080us|5.119us|3419. |0.148%
       r\omap_dm_timer_set_load|8.135ms|0.0us|79.887us|15.065us|540.  |0.069% <--
       \vmlinux-old\Global\_end|2.023ms|0.0us|4.000us|0.560us|3613.   |0.017%
       -old\Global\__raw_readsw|1.962ms|0.0us|108.610us|9.167us|214.  |0.016%
       old\smc91x\smc_interrupt|1.353ms|0.0us|10.212us|2.348us|576.   |0.011%
       s/namei\__link_path_walk|1.161ms|0.0us|4.310us|0.762us|  1524. |0.009%
       \omap_dm_timer_write_reg|1.085ms|0.0us|126.150us|2.153us|504.  |0.009% <--
      
      * After patch timer functions do not show up in top listings for long captures.
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      3fddd09e
  17. 04 10月, 2006 1 次提交
  18. 25 9月, 2006 1 次提交
  19. 27 6月, 2006 2 次提交
  20. 03 4月, 2006 1 次提交
  21. 08 9月, 2005 1 次提交