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