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. 16 2月, 2010 31 次提交
  3. 04 2月, 2010 2 次提交
  4. 30 1月, 2010 2 次提交
  5. 27 1月, 2010 3 次提交
    • K
      OMAP: hwmod: add API for slave idlemode setting · 46273e6f
      Kevin Hilman 提交于
      Some HW blocks have errata which requires specific slave idle mode
      under certain conditions.
      
      This patch adds an hwmod API to allow setting slave idlemode
      ensuring that any SYSCONFIG register updates go through hwmod.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      46273e6f
    • 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
    • P
      OMAP clockdomain/powerdomain: improve documentation · f0271d65
      Paul Walmsley 提交于
      This patch only affects documentation; no functional changes are
      included.
      
      Clean up comments in the current clockdomain, powerdomain code and
      header files.  This mostly involves conversion to kerneldoc format,
      although some clarifications are also included.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      f0271d65