1. 22 12月, 2010 8 次提交
  2. 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
  3. 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
  4. 12 10月, 2010 1 次提交
  5. 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
  6. 30 9月, 2010 2 次提交
  7. 24 9月, 2010 4 次提交
  8. 22 9月, 2010 2 次提交
  9. 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
  10. 02 8月, 2010 1 次提交
  11. 10 6月, 2010 1 次提交
  12. 21 5月, 2010 3 次提交
  13. 13 5月, 2010 6 次提交
  14. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  15. 25 2月, 2010 1 次提交
  16. 24 2月, 2010 1 次提交
    • S
      OMAP3: cpuidle: Update statistics for correct state · 6af83b38
      Sanjeev Premi 提交于
      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: NSanjeev Premi <premi@ti.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      6af83b38
  17. 27 1月, 2010 3 次提交
    • P
      OMAP clockdomains: add usecounting for wakeup and sleep dependencies · 369d5614
      Paul Walmsley 提交于
      Add usecounting for wakeup and sleep dependencies.  In the current
      situation, if several functions add dependencies on the same
      clockdomains, when the first dependency removal function is called,
      the dependency will be incorrectly removed from the hardware.
      
      Add clkdm_clear_all_wkdeps() and clkdm_clear_all_sleepdeps(), which
      provide a fast and usecounting-consistent way to clear all hardware
      clockdomain dependencies, since accesses to these registers can be
      quite slow.  pm{2,3}4xx.c has been updated to use these new functions.
      The original version of this patch did not touch these files, which
      previously wrote directly to the wkdep registers, and thus confused
      the usecounting code.  This problem was found by Kevin Hilman
      <khilman@deeprootsystems.com>.
      
      N.B.: This patch introduces one significant functional difference over
      the previous pm34xx.c code: sleepdeps are now cleared during
      clockdomain initialization, whereas previously they were left
      untouched.  This has been tested by Kevin and confirmed to work.
      
      The original version of this patch also did not take into
      consideration that some clockdomains do not have sleep or wakeup
      dependency sources, which caused NULL pointer dereferences.  This
      problem was debugged and fixed by Kevin Hilman
      <khilman@deeprootsystems.com>.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      Cc: Jouni Högander <jouni.hogander@nokia.com>
      369d5614
    • P
      OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm · 55ed9694
      Paul Walmsley 提交于
      Move clockdomain wakeup dependency and sleep dependency data
      structures from the powerdomain layer to the clockdomain layer, where
      they belong.  These dependencies were originally placed in the
      powerdomain layer due to unclear documentation; however, it is clear
      now that these dependencies are between clockdomains.  For OMAP2/3,
      this is not such a big problem, but for OMAP4 this needs to be fixed.
      
      Thanks to Benoît Cousson <b-cousson@ti.com> for his advice on this
      patch.
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      55ed9694
    • A
      ARM: OMAP4: PM: OMAP4 Power Domain Porting Related Clean-up. · 37903009
      Abhijit Pagare 提交于
      Module offsets were same for OMAP2 and OMAP3 while they differ for OMAP4.
      Hence we need different macros for identifying platform specific offsets.
      Signed-off-by: NAbhijit Pagare <abhijitpagare@ti.com>
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Rajendra Nayak <rnayak@ti.com>
      37903009
  18. 21 1月, 2010 1 次提交