1. 23 Feb, 2010 2 commits
    • Kevin Hilman's avatar
      OMAP3: cpuidle: configure latencies/thresholds from board file · bb4de3df
      Kevin Hilman authored
      
      
      The CPUidle C state latencies and thresholds are dependent on various
      board specific details.  This patch makes it possible to configure
      these values from the respective board files.
      
      omap3_pm_init_cpuidle() can now be optionally called from board files
      to pass board specific cpuidle parameters.  If the board files do not
      use this function to pass the params default values are used which
      might cause higher consumption dur to wrong state selection by the
      governor.
      
      This patch only updates the 3430sdp board files to use
      omap3_pm_init_cpuidle().
      
      From Kalle, in addition to original patch from Rajendra:
      
      Building without CONFIG_CPU_IDLE or CONFIG_PM causes build to fail if
      cpu idle parameters are tried to pass using omap3_pm_init_cpuidle
      function.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Signed-off-by: default avatarKalle Jokiniemi <kalle.jokiniemi@digia.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      bb4de3df
    • Sanjeev Premi's avatar
      OMAP3: cpuidle: Update statistics for correct state · 6af83b38
      Sanjeev Premi authored
      
      
      When 'enable_off_mode' is 0, the target power state for MPU
      and CORE was locally changed to PWRDM_POWER_RET but, the
      statistics are updated for idle state originally selected
      by the governor.
      
      This patch 'invalidates' the idle states that lead either of
      MPU or Core to PWRDM_POWER_OFF state when 'enable_off_mode'
      is '0'. The states are valid once 'enable_off_mode' is set
      to '1'.
      
      Added function next_valid_state() to check if current state
      is valid; else get the next valid state. It is called from
      omap3_enter_idle_bm().
      Signed-off-by: default avatarSanjeev Premi <premi@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      6af83b38
  2. 17 Feb, 2010 2 commits
    • Tony Lindgren's avatar
      80c20d54
    • Ranjith Lohithakshan's avatar
      omap: Remove DEBUG_FS dependency for mux name checking · b72c7d54
      Ranjith Lohithakshan authored
      
      
      The check for a valid mux name should be performed regardless of whether
      DEBUG_FS is enabled or not. Otherwise without DEBUG_FS, we get:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: Oops: 5 [#1]
      last sysfs file:
      Modules linked in:
      CPU: 0    Not tainted  (2.6.33-rc8 #10)
      PC is at strcmp+0x18/0x40
      LR is at omap_mux_init_signal+0x68/0x14c
      ...
      
      This fixes the issue currently seen with boards not booting up
      if DEBUG_FS is not enabled in defconfig.
      
      Note that the earlier ifndef + ifdef now becomes simpler ifdef else:
      If CONFIG_OMAP_MUX is selected, we use pin names. If it's not selected,
      we only want the GPIO to mux register mapping.
      Signed-off-by: default avatarRanjith Lohithakshan <ranjithl@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      b72c7d54
  3. 15 Feb, 2010 36 commits