1. 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
  2. 22 12月, 2010 13 次提交
  3. 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
  4. 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
  5. 16 11月, 2010 1 次提交
  6. 12 10月, 2010 1 次提交
  7. 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
  8. 30 9月, 2010 2 次提交
  9. 24 9月, 2010 4 次提交
  10. 22 9月, 2010 2 次提交
  11. 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
  12. 02 8月, 2010 1 次提交
  13. 10 6月, 2010 1 次提交
  14. 21 5月, 2010 3 次提交
  15. 13 5月, 2010 6 次提交