1. 29 6月, 2012 1 次提交
    • K
      ARM: OMAP2+: fix CONFIG_CPU_IDLE dependency on CONFIG_PM · e0246e8e
      Kevin Hilman 提交于
      commit 164e0cbf (ARM: OMAP3/4: consolidate cpuidle Makefile) added
      an OMAP-specific dependency from CPU_IDLE to CONFIG_PM.  This causes
      some randconfig warnings when CONFIG_PM has unmet dependencies:
      
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
      
      Fix this by making the dependency on CONFIG_PM_RUNTIME (which in turn
      will enable CONFIG_PM.)
      Reported-by: NTony Lindgren <tony@atomide.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0246e8e
  2. 20 6月, 2012 1 次提交
    • D
      ARM: OMAP3/4: consolidate cpuidle Makefile · 164e0cbf
      Daniel Lezcano 提交于
      The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files
      even if the cpuidle option is not set in the kernel.
      
      This patch fixes this by creating a section in the Makefile where these
      files are compiled only if the CONFIG_CPU_IDLE option is set.
      
      This modification breaks an implicit dependency between CPU_IDLE and PM as
      they belong to the same block in the Makefile. This is fixed in the Kconfig
      by selecting explicitely PM is CPU_IDLE is set.
      
      The linux coding style recommend to use no-op functions in the headers
      when the subsystem is disabled instead of adding big section in C files.
      
      This patch fix this also.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Reviewed-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NRajendra Nayak <rnayak@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      164e0cbf
  3. 11 5月, 2012 2 次提交
  4. 10 5月, 2012 1 次提交
  5. 06 3月, 2012 2 次提交
  6. 25 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Fix multiple randconfig errors with SOC_OMAP and SOC_OMAP_NOOP · c295fb63
      Tony Lindgren 提交于
      If we don't have ARCH_OMAP2, 3 or 4 selected randconfig will always
      fail with multiple errors as the CPU and MACHINE are not set.
      
      Fix this by changing arch/arm/Makefile to build mach-omap2 based on
      ARCH_OMAP2PLUS. And let's introduce SOC_OMAP and SOC_OMAP_NOOP that
      allow randconfig to generate buildable .config files.
      
      Note that we can also remove few uncecssary ARCH_OMAP2PLUS lines
      as they are all within if ARCH_OMAP2PLUS block.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c295fb63
  7. 24 2月, 2012 1 次提交
  8. 15 2月, 2012 1 次提交
  9. 23 1月, 2012 1 次提交
    • W
      ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs · a092f2b1
      Will Deacon 提交于
      To ensure correct alignment of cacheline-aligned data, the maximum
      cacheline size needs to be known at compile time.
      
      Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
      that there will be future ARMv7 implementations with the same line size)
      then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
      size. For CPUs with smaller caches, this will result in some harmless
      padding but will help with single zImage work and avoid hitting subtle
      bugs with misaligned data structures.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a092f2b1
  10. 21 1月, 2012 2 次提交
  11. 13 1月, 2012 1 次提交
    • R
      ARM: Add arm_memblock_steal() to allocate memory away from the kernel · 716a3dc2
      Russell King 提交于
      Several platforms are now using the memblock_alloc+memblock_free+
      memblock_remove trick to obtain memory which won't be mapped in the
      kernel's page tables.  Most platforms do this (correctly) in the
      ->reserve callback.  However, OMAP has started to call these functions
      outside of this callback, and this is extremely unsafe - memory will
      not be unmapped, and could well be given out after memblock is no
      longer responsible for its management.
      
      So, provide arm_memblock_steal() to perform this function, and ensure
      that it panic()s if it is used inappropriately.  Convert everyone
      over, including OMAP.
      
      As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot
      with this change.  Mark this option as BROKEN and make it depend on
      BROKEN.  OMAP needs to be fixed, or 137d105d (ARM: OMAP4: Fix
      errata i688 with MPU interconnect barriers.) reverted until such
      time it can be fixed correctly.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      716a3dc2
  12. 19 12月, 2011 3 次提交
  13. 17 12月, 2011 1 次提交
  14. 14 12月, 2011 3 次提交
    • H
      ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM · a890b676
      Hemant Pedanekar 提交于
      This patch adds minimal support and build configuration for TI8148 EVM. Also
      adds support for low level debugging on UART1 console on the EVM.
      
      Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine
      info for TI8148 EVM.
      Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a890b676
    • H
      ARM: OMAP: TI81XX: Prepare for addition of TI814X support · a920360f
      Hemant Pedanekar 提交于
      This patch updates existing macros, functions used for TI816X, to enable
      addition of other SoCs belonging to TI81XX family (e.g., TI814X).
      
      The approach taken is to use TI81XX/ti81xx for code/data going to be common
      across all TI81XX devices.
      
      cpu_is_ti81xx() is introduced to handle code common across TI81XX devices.
      
      In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved
      in mach-omap2/common.c as same will be used for TI814X and is not board
      specific.
      Signed-off-by: NHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a920360f
    • A
      ARM: OMAP: am33xx: Update common omap platform files · 99541195
      Afzal Mohammed 提交于
      This patch updates the common platform files with AM335X device
      support (AM33XX family).
      
      The approach taken in this patch is,
      AM33XX device will be considered as OMAP3 variant, and a separate
      SoC class created for AM33XX family of devices with a subclass type
      for AM335X device, which is newly added device in the family.
      
      This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x()
      checks will return success on AM335X device.
      A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3
      to include support for AM33XX build.
      
      Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence
      struct clksel_rate.flags, struct prcm_config.flags and cpu_mask
      are changed to u16 from u8.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Hemant Pedanekar <hemantp@ti.com>
      [tony@atomide.com: left out CK_AM33XX for now]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      99541195
  15. 09 12月, 2011 1 次提交
    • S
      ARM: OMAP4: Fix errata i688 with MPU interconnect barriers. · 137d105d
      Santosh Shilimkar 提交于
      On OMAP4 SOC, intecronnects has many write buffers in the async bridges
      and they need to be drained before CPU enters into standby state.
      
      Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support
      but OMAP errata i688 (Async Bridge Corruption) needs to be taken
      care to avoid issues like system freeze, CPU deadlocks, random
      crashes with register accesses, synchronisation loss on initiators
      operating on both interconnect port simultaneously.
      
      As per the errata, if a data is stalled inside asynchronous bridge
      because of back pressure, it may be accepted multiple times, creating
      pointer misalignment that will corrupt next transfers on that data
      path until next reset of the system (No recovery procedure once
      the issue is hit, the path remains consistently broken).
      Async bridge can be found on path between MPU to EMIF and
      MPU to L3 interconnect. This situation can happen only when the
      idle is initiated by a Master Request Disconnection (which is
      trigged by software when executing WFI on CPU).
      
      The work-around for this errata needs all the initiators
      connected through async bridge must ensure that data path
      is properly drained before issuing WFI. This condition will be
      met if one Strongly ordered access is performed to the
      target right before executing the WFI. In MPU case, L3 T2ASYNC
      FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure
      that there is no synchronisation loss on initiators operating
      on both interconnect port simultaneously.
      
      Thanks to Russell for a tip to conver assembly function to
      C fuction there by reducing 40 odd lines of code from the patch.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com>
      Acked-by: NJean Pihet <j-pihet@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      137d105d
  16. 24 11月, 2011 1 次提交
    • M
      ARM: OMAP2: select ARM_AMBA if OMAP3_EMU is defined · a8a6565c
      Ming Lei 提交于
      This patch selects ARM_AMBA if OMAP3_EMU is defined because
      OC_ETM depends on ARM_AMBA, so fix the link failure[1].
      
      [1],
      arch/arm/kernel/built-in.o: In function `etm_remove':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined
      reference to `amba_release_regions'
      arch/arm/kernel/built-in.o: In function `etb_remove':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined
      reference to `amba_release_regions'
      arch/arm/kernel/built-in.o: In function `etm_init':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined
      reference to `amba_driver_register'
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined
      reference to `amba_driver_register'
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined
      reference to `amba_driver_unregister'
      arch/arm/kernel/built-in.o: In function `etm_probe':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined
      reference to `amba_request_regions'
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined
      reference to `amba_release_regions'
      arch/arm/kernel/built-in.o: In function `etb_probe':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined
      reference to `amba_request_regions'
      /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined
      reference to `amba_release_regions'
      arch/arm/mach-omap2/built-in.o: In function `emu_init':
      /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62:
      undefined reference to `amba_device_register'
      /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63:
      undefined reference to `amba_device_register'
      make: *** [.tmp_vmlinux1] Error 1
      making modules
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a8a6565c
  17. 16 11月, 2011 2 次提交
  18. 24 10月, 2011 1 次提交
    • A
      mfd: remove CONFIG_MFD_SUPPORT · 8a0a8e8e
      Arnd Bergmann 提交于
      We currently have two symbols to control compilation the MFD subsystem,
      MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required
      at all, it only hides the submenu when not set, with the effect that
      Kconfig warns about missing dependencies when another driver selects
      an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu
      back from menuconfig into a plain menu simplifies the Kconfig syntax
      for those kinds of users and avoids the surprise when the menu
      suddenly appears because another driver was enabled that selects this
      symbol.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      8a0a8e8e
  19. 05 10月, 2011 1 次提交
  20. 02 10月, 2011 1 次提交
  21. 06 8月, 2011 1 次提交
  22. 05 7月, 2011 1 次提交
  23. 17 5月, 2011 1 次提交
  24. 09 3月, 2011 1 次提交
  25. 24 2月, 2011 1 次提交
  26. 23 2月, 2011 1 次提交
  27. 17 2月, 2011 2 次提交
  28. 28 1月, 2011 1 次提交
  29. 22 12月, 2010 2 次提交
  30. 21 12月, 2010 1 次提交