1. 25 2月, 2010 3 次提交
    • T
      OMAP: HWMOD: Add support for early device register into omap device layer · c23a97d3
      Thara Gopinath 提交于
      This patch adds support in omap device layer to register devices
      as early platform devices. Certain devices needed during system boot up
      like timers, gpio etc can be registered as early devices. This will
      allow for them to be probed very early on during system boot up.
      This patch adds a parameter is_early_device in omap_device_build.
      Depending on this parameter a call to early_platform_add_devices
      or platform_register_device is made.
      Signed-off-by: NThara Gopinath <thara@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      c23a97d3
    • 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