1. 08 3月, 2011 1 次提交
  2. 26 2月, 2011 3 次提交
    • P
      OMAP2+: clock: autoidle as many clocks as possible if CONFIG_OMAP_RESET_CLOCKS · b80b956d
      Paul Walmsley 提交于
      Attempt to enable autoidle for as many clocks as possible in the
      OMAP2+-common CONFIG_OMAP_RESET_CLOCKS code.  Currently, this only
      enables DPLL autoidle for OMAP3/4 DPLLs; but future patches will
      enable autoidle for other clocks and the OMAP2 DPLL/APLLs.
      
      In the long run, we should probably get rid of
      CONFIG_OMAP_RESET_CLOCKS, and unconditionally run the code that it
      selects.  Otherwise, the state of the clock tree won't match the
      hardware state - this could result in clocks being enabled or disabled
      unpredictably.
      
      Based on a patch by Rajendra Nayak <rnayak@ti.com> that did this in
      the pm34xx.c/pm44xx.c code.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      b80b956d
    • R
      OMAP: clockdomain: Arch specific funcs for hwsup control of clkdm · 5cd1937b
      Rajendra Nayak 提交于
      Define the following architecture specific funtions for omap2/3/4
      .clkdm_allow_idle
      .clkdm_deny_idle
      
      Convert the platform-independent framework to call these functions.
      Also rename the api's by removing the omap2_ preamble.
      Hence call omap2_clkdm_allow_idle as clkdm_allow_idle and
      omap2_clkdm_deny_idle as clkdm_deny_idle.
      
      Make the _clkdm_add_autodeps and _clkdm_del_autodeps as non-static
      so they can be accessed from OMAP2/3 platform specific code.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      5cd1937b
    • R
      OMAP: clockdomain: Arch specific funcs for sleep/wakeup of clkdm · 68b921ad
      Rajendra Nayak 提交于
      Define the following architecture specific funtions for omap2/3/4
      .clkdm_sleep
      .clkdm_wakeup
      
      Convert the platform-independent framework to call these functions.
      Also rename the api's by removing the omap2_ preamble.
      Hence call omap2_clkdm_wakeup as clkdm_wakeup and
      omap2_clkdm_sleep as clkdm_sleep.
      Signed-off-by: NRajendra Nayak <rnayak@ti.com>
      [paul@pwsan.com: fixed omap3_clkdm_clear_all_sleepdeps() and
       omap2_clkdm_clear_all_wkdeps() to test against the correct
       loop termination condition; thanks to Kevin Hilman for finding and
       helping fix]
      Cc: Kevin Hilman <khilman@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      68b921ad
  3. 27 1月, 2011 1 次提交
    • K
      OMAP3: PM: fix save secure RAM to restore MPU power state · 617fcc98
      Kevin Hilman 提交于
      Currently, on HS/EMU devices, MPU power state forced to on during PM
      init by the save secure RAM code.  Rather than forcing the state of
      MPU powerdomain to on, simply read the current value and restore it
      after the ROM code has run.
      
      This only affects the !CPUidle case since when CPUidle is enabled, the
      MPU power state is dynamically changed by CPUidle.  In the !CPUidle
      case, MPU power state is initialized once at init and never touched.
      Acked-by: NTero Kristo <tero.kristo@nokia.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      617fcc98
  4. 26 1月, 2011 1 次提交
    • T
      console: rename acquire/release_console_sem() to console_lock/unlock() · ac751efa
      Torben Hohn 提交于
      The -rt patches change the console_semaphore to console_mutex.  As a
      result, a quite large chunk of the patches changes all
      acquire/release_console_sem() to acquire/release_console_mutex()
      
      This commit makes things use more neutral function names which dont make
      implications about the underlying lock.
      
      The only real change is the return value of console_trylock which is
      inverted from try_acquire_console_sem()
      
      This patch also paves the way to switching console_sem from a semaphore to
      a mutex.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
      Signed-off-by: NTorben Hohn <torbenh@gmx.de>
      Cc: Thomas Gleixner <tglx@tglx.de>
      Cc: Greg KH <gregkh@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ac751efa
  5. 22 12月, 2010 13 次提交
  6. 10 12月, 2010 1 次提交
    • K
      OMAP2+: PM/serial: fix console semaphore acquire during suspend · e83df17f
      Kevin Hilman 提交于
      commit 0d8e2d0d (OMAP2+: PM/serial:
      hold console semaphore while OMAP UARTs are disabled) added use of the
      console semaphore to protect UARTs from being accessed after disabled
      during idle, but this causes problems in suspend.
      
      During suspend, the console semaphore is acquired by the console
      suspend method (console_suspend()) so the try_acquire_console_sem()
      will always fail and suspend will be aborted.
      
      To fix, introduce a check so the console semaphore is only attempted
      during idle, and not during suspend.  Also use the same check so that
      the console semaphore is not prematurely released during resume.
      
      Thanks to Paul Walmsley for suggesting adding the same check during
      resume.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Tested-by: NJean Pihet <j-pihet@ti.com>
      Tested-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e83df17f
  7. 25 11月, 2010 1 次提交
    • P
      OMAP2+: PM/serial: hold console semaphore while OMAP UARTs are disabled · 0d8e2d0d
      Paul Walmsley 提交于
      The console semaphore must be held while the OMAP UART devices are
      disabled, lest a console write cause an ARM abort (and a kernel crash)
      when the underlying console device is inaccessible.  These crashes
      only occur when the console is on one of the OMAP internal serial
      ports.
      
      While this problem has been latent in the PM idle loop for some time,
      the crash was not triggerable with an unmodified kernel until commit
      6f251e9d ("OMAP: UART: omap_device
      conversions, remove implicit 8520 assumptions").  After this patch, a
      console write often occurs after the console UART has been disabled in
      the idle loop, crashing the system.  Several users have encountered
      this bug:
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg38396.html
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36602.html
      
      The same commit also introduced new code that disabled the UARTs
      during init, in omap_serial_init_port().  The kernel will also crash
      in this code when earlyconsole and extra debugging is enabled:
      
          http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36411.html
      
      The minimal fix for the -rc series is to hold the console semaphore
      while the OMAP UARTs are disabled.  This is a somewhat overbroad fix,
      since the console may not be located on an OMAP UART, as is the case
      with the GPMC UART on Zoom3.  While it is technically possible to
      determine which devices the console or earlyconsole is actually
      running on, it is not a trivial problem to solve, and the code to do
      so is not really appropriate for the -rc series.
      
      The right long-term fix is to ensure that no code outside of the OMAP
      serial driver can disable an OMAP UART.  As I understand it, code to
      implement this is under development by TI.
      
      This patch is a collaboration between Paul Walmsley <paul@pwsan.com>
      and Tony Lindgren <tony@atomide.com>.  Thanks to Ming Lei
      <tom.leiming@gmail.com> and Pramod <pramod.gurav@ti.com> for their
      feedback on earlier versions of this patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
      Cc: Ming Lei <tom.leiming@gmail.com>
      Cc: Pramod <pramod.gurav@ti.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Jean Pihet <jean.pihet@newoldbits.com>
      Cc: Govindraj.R <govindraj.raja@ti.com>
      0d8e2d0d
  8. 16 11月, 2010 1 次提交
  9. 12 10月, 2010 1 次提交
  10. 09 10月, 2010 2 次提交
    • P
      OMAP: control: move plat-omap/control.h to mach-omap2/control.h · 4814ced5
      Paul Walmsley 提交于
      Only OMAP2+ platforms have the System Control Module (SCM) IP block.
      In the past, we've kept the SCM header file in plat-omap.  This has
      led to abuse - device drivers including it; includes being added that
      create implicit dependencies on OMAP2+ builds; etc.
      
      In response, move the SCM headers into mach-omap2/.
      
      As part of this, remove the direct SCM access from the OMAP UDC
      driver.  It was clearly broken.  The UDC code needs an indepth review for
      use on OMAP2+ chips.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Cory Maccarrone <darkstar6262@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      4814ced5
    • M
      OMAP: mach-omap2: Fix incorrect assignment warnings · 4d63bc1d
      Manjunath Kondaiah G 提交于
      This patch fixes below sparse warnings for incorrect assignments.
      
      arch/arm/mach-omap2/control.c:195:16: warning: incorrect type in assignment (different address spaces)
      arch/arm/mach-omap2/control.c:195:16:    expected unsigned int [usertype] *v_addr
      arch/arm/mach-omap2/control.c:195:16:    got void [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:199:25: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/control.c:199:25:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:199:25:    got unsigned int [usertype] *
      arch/arm/mach-omap2/control.c:320:28: warning: incorrect type in assignment (different address spaces)
      arch/arm/mach-omap2/control.c:320:28:    expected void *[noderef] <asn:2>scratchpad_address
      arch/arm/mach-omap2/control.c:320:28:    got void [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:321:9: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/control.c:321:9:    expected void volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:321:9:    got void *[noderef] <asn:2>scratchpad_address
      arch/arm/mach-omap2/control.c:324:9: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/control.c:324:9:    expected void volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:324:9:    got void *
      arch/arm/mach-omap2/control.c:327:9: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/control.c:327:9:    expected void volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:327:9:    got void *
      arch/arm/mach-omap2/control.c:334:9: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/control.c:334:9:    expected void volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/control.c:334:9:    got void *
      arch/arm/mach-omap2/control.c:321:9: warning: dereference of noderef expression
      arch/arm/mach-omap2/control.c:324:9: warning: dereference of noderef expression
      arch/arm/mach-omap2/control.c:327:9: warning: dereference of noderef expression
      arch/arm/mach-omap2/control.c:334:9: warning: dereference of noderef expression
      
      arch/arm/mach-omap2/pm34xx.c:323:28: warning: incorrect type in assignment (different address spaces)
      arch/arm/mach-omap2/pm34xx.c:323:28:    expected unsigned int [usertype] *scratchpad_address
      arch/arm/mach-omap2/pm34xx.c:323:28:    got void [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/pm34xx.c:326:26: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/pm34xx.c:326:26:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/pm34xx.c:326:26:    got unsigned int [usertype] *
      arch/arm/mach-omap2/pm34xx.c:329:26: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/pm34xx.c:329:26:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/pm34xx.c:329:26:    got unsigned int [usertype] *
      arch/arm/mach-omap2/pm34xx.c:334:29: warning: incorrect type in argument 1 (different address spaces)
      arch/arm/mach-omap2/pm34xx.c:334:29:    expected void const volatile [noderef] <asn:2>*<noident>
      arch/arm/mach-omap2/pm34xx.c:334:29:    got unsigned int [usertype] *
      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>
      4d63bc1d
  11. 30 9月, 2010 2 次提交
  12. 24 9月, 2010 4 次提交
  13. 22 9月, 2010 2 次提交
  14. 16 8月, 2010 1 次提交
    • K
      OMAP3: PM: ensure IO wakeups are properly disabled · 58a5559e
      Kevin Hilman 提交于
      Commit 5a5f561e (convert OMAP3 PRCM macros to the _SHIFT/_MASK suffixes)
      mistakenly removed the check for PER when disabling the IO chain.
      
      During idle, if the PER powerdomain transitions into a lower state
      and CORE does not, the IO pad wakeups are not being disabled in
      the idle path after they are enabled. This can happen with the
      lower C-states when using CPUidle for example.
      
      This patch ensures that the check for disabling IO wakeups also checks
      for PER transitions, matching the check done to enable IO wakeups.
      
      Found when debugging PM/CPUidle related problems reported by Ameya
      Palande <ameya.palande@nokia.com>.  Problems were triggered
      particularily on boards with UART2 consoles (n900, Overo) since UART2
      is in the PER powerdomain.
      
      Tested on l-o master (omap3_defonfig + CONFIG_CPU_IDLE=y) as well
      as with current PM branch.  Boards tested: n900, Overo, omap3evm.
      
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Ameya Palande <ameya.palande@nokia.com>
      Tested-by: NJarkko Nikula <jhnikula@gmail.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      [tony@atomide.com: updated description to clarify the transistion]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      58a5559e
  15. 02 8月, 2010 1 次提交
  16. 10 6月, 2010 1 次提交
  17. 21 5月, 2010 3 次提交
  18. 13 5月, 2010 1 次提交
    • K
      OMAP2/3: GPIO: generalize prepare for idle · 43ffcd9a
      Kevin Hilman 提交于
      Currently, the GPIO 'prepare' hook is only called when going to
      off-mode, while the function is called 'prepare_for_retention.'  This
      patch renames the function to 'prepare_for_idle' and calls it for any
      powersate != PWRDM_POWER_ON passing in the powerstate.
      
      The hook itself is then responsible for doing various preparation
      based on the powerstate.
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      43ffcd9a