1. 25 2月, 2010 2 次提交
    • K
      OMAP: omap_device: when 'called from invalid state', print state · 24d82e34
      Kevin Hilman 提交于
      The omap_device_[enable|idle|shutdown] functions print a warning
      when called from an invalid state.  Print the invalid state in
      the warning messages.  This also uses __func__ to get the function
      name.
      
      Also, move the entire print string onto a single line to facilitate
      grepping or error messages.  Recent discussions on LKML show
      strong preference for grep-able code vs. strict 80 column limit.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      24d82e34
    • K
      OMAP: omap_device: add omap_device_is_valid() · 0007122a
      Kevin Hilman 提交于
      The omap_device struct contains a 'struct platform_device'.  Normally,
      converting a platform_device pointer to an omap_device pointer
      consists of simply doing a container_of(), as is done currently by the
      to_omap_device() macro.
      
      However, if this is attempted when using platform_device that has not
      been created as part of the omap_device creation, the container_of()
      will point to a memory location before the platform_device pointer
      which will contain random data.
      
      Therefore, we need a way to detect valid omap_device pointers.  This
      patch solves this by using the simple magic number approach.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      0007122a
  2. 04 2月, 2010 1 次提交
  3. 27 1月, 2010 1 次提交
    • K
      OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies · 9799aca2
      Kevin Hilman 提交于
      First, this patch adds new worst-case latency values to the
      omap_device_pm_latency struct.  Here the worst-case measured latencies
      for the activate and deactivate hooks are stored.
      
      In addition, add an option to auto-adjust the latency values used for
      device activate/deactivate.
      
      By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the
      omap_device_pm_latency struct, the omap_device layer automatically
      adjusts the activate/deactivate latencies to the worst-case measured
      values.
      
      Anytime a new worst-case value is found, it is printed to the console.
      Here is an example log during boot using UART2 s an example.  After
      boot, the OPP is manually changed to the 125MHz OPP:
      
      [...]
      Freeing init memory: 128K
      omap_device: serial8250.2: new worst case deactivate latency 0: 30517
      omap_device: serial8250.2: new worst case activate latency 0: 30517
      omap_device: serial8250.2: new worst case activate latency 0: 218139648
      omap_device: serial8250.2: new worst case deactivate latency 0: 61035
      omap_device: serial8250.2: new worst case activate latency 0: 278076171
      omap_device: serial8250.2: new worst case activate latency 0: 298614501
      omap_device: serial8250.2: new worst case activate latency 0: 327331542
      
      / # echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
      
      omap_device: serial8250.2: new worst case deactivate latency 0: 91552
      
      Motivation: this can be used as a technique to automatically determine
      the worst case latency values.  The current method of printing a
      warning on every violation is too noisy to actually interact the
      console in order to set low OPP to discover latencies.
      
      Another motivation for this patch is that the activate/deactivate
      latenices can vary depending on the idlemode of the device.  While
      working on the UARTs, I noticed that when using no-idle, the activate
      latencies were as high as several hundred msecs as shown above.  When
      the UARTs are in smart-idle, the max latency is well under 100 usecs.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      9799aca2
  4. 12 12月, 2009 4 次提交
  5. 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
  6. 20 10月, 2009 1 次提交
  7. 04 9月, 2009 1 次提交
    • P
      OMAP2/3/4 core: create omap_device layer · b04b65ab
      Paul Walmsley 提交于
      The omap_device code provides a mapping of omap_hwmod structures into
      the platform_device system, and includes some details on external
      (board-level) integration.  This allows drivers to enable, idle, and
      shutdown on-chip device resources, including clocks, regulators, etc.
      The resources enabled and idled are dependent on the device's maximum
      wakeup latency constraint (if present).
      
      At the moment, omap_device functions are intended to be called from
      platform_data function pointers.  Ideally in the future these
      functions will be called from either subarchitecture-specific
      platform_data activate, deactivate functions, or via an custom
      bus/device type for OMAP.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      Cc: Vikram Pandita <vikram.pandita@ti.com>
      Cc: Sakari Poussa <sakari.poussa@nokia.com>
      Cc: Anand Sawant <sawant@ti.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Eric Thomas <ethomas@ti.com>
      Cc: Richard Woodruff <r-woodruff2@ti.com>
      b04b65ab