1. 19 9月, 2012 2 次提交
  2. 31 8月, 2012 1 次提交
  3. 23 8月, 2012 1 次提交
    • A
      ARM: omap: allow building omap44xx without SMP · c7a9b09b
      Arnd Bergmann 提交于
      The new omap4 cpuidle implementation currently requires
      ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
      
      This patch makes it possible to build a non-SMP kernel
      for that platform. This is not normally desired for
      end-users but can be useful for testing.
      
      Without this patch, building rand-0y2jSKT results in:
      
      drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
      drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
      
      It's not clear if this patch is the best solution for
      the problem at hand. I have made sure that we can now
      build the kernel in all configurations, but that does
      not mean it will actually work on an OMAP44xx.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Tony Lindgren <tony@atomide.com>
      c7a9b09b
  4. 07 8月, 2012 1 次提交
    • S
      OMAP2+: Fix random config build break with !ARM_CPU_SUSPEND · acb11fe8
      Santosh Shilimkar 提交于
      The random config builds with PM and !ARM_CPU_SUSPEND breaks with below
      error on omap2plus_defconfig.
      
      arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
      arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend'
      
      This is because recently merged OMAP5 platform shares the common files
      with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND
      the sleep code is meaningless.
      
      Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from
      Russell King in an off-list discussion.
      
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Kevin Hilman <khilman@ti.com>
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      acb11fe8
  5. 26 7月, 2012 1 次提交
    • S
      ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP cpuidle. · dd3ad97c
      Santosh Shilimkar 提交于
      OMAP4 CPUDILE driver is converted mainly based on notes from the
      coupled cpuidle patch series.
      
      The changes include :
      - Register both CPUs and C-states to cpuidle driver.
      - Set struct cpuidle_device.coupled_cpus
      - Set struct cpuidle_device.safe_state to non coupled state.
      - Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
        state that affects multiple cpus.
      - Separate ->enter hooks for coupled & simple idle.
      - CPU0 wait loop for CPU1 power transition.
      - CPU1 wakeup mechanism for the idle exit.
      - Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.
      
      Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
      on the intermediate version of this patch.
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      dd3ad97c
  6. 09 7月, 2012 1 次提交
  7. 05 7月, 2012 2 次提交
    • V
      ARM: OMAP2+: Remove unnecessary ifdef around __omap2_set_globals · ecc46cfd
      Vaibhav Hiremath 提交于
      The function __omap2_set_globals() can be common across all
      platforms/architectures, even in case of omap4, internally it
      calls same set of functions as in __omap2_set_globals() function
      (except for sdrc).
      This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
      so that we can reuse same function across omap2/3/4...
      Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ecc46cfd
    • V
      ARM: OMAP2+: am33xx: Make am33xx as a separate class · 1c213ba1
      Vaibhav Hiremath 提交于
      Initially, we decided to make am33xx family of device to fall
      under omap3 class (cpu_is_omap34xx() = true), since it carries
      Cortex-A8 core. But while adding complete baseport support
      (like, clock, power and hwmod) support, it is observed that,
      we are creating more and more problems by treating am33xx device
      as omap3 family, as nothing matches between them
      (except cortex-A8 mpu).
      
      So,  after long discussion we have came to the conclusion that,
      we should not consider am33xx device as omap3 family, instead
      create separate class (SOC_AM33XX) under OMAP2PLUS.
      This means, for am33xx device, cpu_is_omap34xx() will return false,
      and only cpu_is_am33xx() will be true.
      
      Please refer to the link below, for mailing-list discussion on this -
      
      http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      [tony@atomide.com: fixed typo, updated for soc_is changes]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1c213ba1
  8. 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
  9. 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
  10. 04 6月, 2012 2 次提交
    • T
      ARM: OMAP2: Remove legacy USB FS support · fe57ab06
      Tony Lindgren 提交于
      The FS (Full Speed) USB controller is available on 2420 and 2430,
      but not being used.
      
      Out of the 2420 based boards only Nokia N8X0 are seeing active
      development and they have external HS (High Speed) TUSB controller.
      On omap 2430sdp there is MUSB HS controller, so there's no need
      to use the legacy USB FS controller.
      
      That leaves only H4 and Apollon boards that could use the FS USB
      controller. As both H4 and Apollon boards are old proprietary
      development boards, it's unlikely that we have any active
      developers working on those boards using the USB.
      
      So remove the FS USB support for omap2 machines. Patches are
      welcome if somebody wants to instead fix it all up to the
      current standards.
      
      Cc: linux-usb@vger.kernel.org
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      fe57ab06
    • T
      ARM: OMAP3: There is no FS USB controller on omap3 · a22ab1c4
      Tony Lindgren 提交于
      We should not select ARCH_OMAP_OTG as the hardware does not
      have the legacy FS (Full Speed) USB interface.
      
      Cc: linux-usb@vger.kernel.org
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      a22ab1c4
  11. 11 5月, 2012 2 次提交
  12. 10 5月, 2012 1 次提交
  13. 06 3月, 2012 2 次提交
  14. 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
  15. 24 2月, 2012 1 次提交
  16. 15 2月, 2012 1 次提交
  17. 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
  18. 21 1月, 2012 2 次提交
  19. 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
  20. 19 12月, 2011 3 次提交
  21. 17 12月, 2011 1 次提交
  22. 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
  23. 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
  24. 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
  25. 16 11月, 2011 2 次提交
  26. 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
  27. 05 10月, 2011 1 次提交
  28. 02 10月, 2011 1 次提交
  29. 06 8月, 2011 1 次提交