1. 23 Jan, 2012 1 commit
    • Will Deacon's avatar
      ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs · a092f2b1
      Will Deacon authored
      
      
      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: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a092f2b1
  2. 13 Jan, 2012 1 commit
    • Russell King's avatar
      ARM: Add arm_memblock_steal() to allocate memory away from the kernel · 716a3dc2
      Russell King authored
      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: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      716a3dc2
  3. 19 Dec, 2011 3 commits
  4. 13 Dec, 2011 3 commits
    • Hemant Pedanekar's avatar
      ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM · a890b676
      Hemant Pedanekar authored
      
      
      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: default avatarHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a890b676
    • Hemant Pedanekar's avatar
      ARM: OMAP: TI81XX: Prepare for addition of TI814X support · a920360f
      Hemant Pedanekar authored
      
      
      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: default avatarHemant Pedanekar <hemantp@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a920360f
    • Afzal Mohammed's avatar
      ARM: OMAP: am33xx: Update common omap platform files · 99541195
      Afzal Mohammed authored
      
      
      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: default avatarAfzal Mohammed <afzal@ti.com>
      Signed-off-by: default avatarVaibhav Hiremath <hvaibhav@ti.com>
      Cc: Hemant Pedanekar <hemantp@ti.com>
      [tony@atomide.com: left out CK_AM33XX for now]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      99541195
  5. 08 Dec, 2011 1 commit
    • Santosh Shilimkar's avatar
      ARM: OMAP4: Fix errata i688 with MPU interconnect barriers. · 137d105d
      Santosh Shilimkar authored
      
      
      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: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: default avatarRichard Woodruff <r-woodruff2@ti.com>
      Acked-by: default avatarJean Pihet <j-pihet@ti.com>
      Reviewed-by: default avatarKevin Hilman <khilman@ti.com>
      Tested-by: default avatarVishwanath BS <vishwanath.bs@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@ti.com>
      137d105d
  6. 23 Nov, 2011 1 commit
    • Ming Lei's avatar
      ARM: OMAP2: select ARM_AMBA if OMAP3_EMU is defined · a8a6565c
      Ming Lei authored
      
      
      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: default avatarMing Lei <tom.leiming@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      a8a6565c
  7. 15 Nov, 2011 2 commits
  8. 24 Oct, 2011 1 commit
    • Arnd Bergmann's avatar
      mfd: remove CONFIG_MFD_SUPPORT · 8a0a8e8e
      Arnd Bergmann authored
      
      
      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: default avatarArnd Bergmann <arnd@arndb.de>
      8a0a8e8e
  9. 04 Oct, 2011 1 commit
  10. 01 Oct, 2011 1 commit
  11. 05 Aug, 2011 1 commit
  12. 05 Jul, 2011 1 commit
  13. 17 May, 2011 1 commit
  14. 08 Mar, 2011 1 commit
  15. 23 Feb, 2011 1 commit
  16. 22 Feb, 2011 1 commit
  17. 16 Feb, 2011 2 commits
  18. 27 Jan, 2011 1 commit
  19. 21 Dec, 2010 2 commits
  20. 20 Dec, 2010 1 commit
  21. 17 Dec, 2010 2 commits
  22. 07 Dec, 2010 1 commit
  23. 30 Nov, 2010 2 commits
  24. 17 Nov, 2010 5 commits
  25. 08 Oct, 2010 2 commits
    • Paul Walmsley's avatar
      OMAP2+: Kconfig: disallow builds for boards that don't use the currently-selected SoC · 6515e489
      Paul Walmsley authored
      
      
      Currently, if, for example, CONFIG_ARCH_OMAP2420 is not selected, OMAP2420
      board files can still be included in the build.  This results in link errors:
      
      arch/arm/mach-omap2/built-in.o: In function `omap_generic_map_io':
      .../arch/arm/mach-omap2/board-generic.c:51: undefined reference to `omap2_set_globals_242x'
      arch/arm/mach-omap2/built-in.o: In function `omap_h4_init':
      .../arch/arm/mach-omap2/board-h4.c:330: undefined reference to `omap2420_mux_init'
      arch/arm/mach-omap2/built-in.o: In function `omap_h4_map_io':
      .../arch/arm/mach-omap2/board-h4.c:373: undefined reference to `omap2_set_globals_242x'
      arch/arm/mach-omap2/built-in.o: In function `omap_apollon_init':
      .../arch/arm/mach-omap2/board-apollon.c:325: undefined reference to `omap2420_mux_init'
      arch/arm/mach-omap2/built-in.o: In function `omap_apollon_map_io':
      .../arch/arm/mach-omap2/board-apollon.c:353: undefined reference to `omap2_set_globals_242x'
      make: *** [.tmp_vmlinux1] Error 1
      
      Fix this by making the boards depend on the Kconfig option for the
      specific SoC that they use.
      
      Also, while here, fix the mach-omap2/board-generic.c file to remove the
      dependency on OMAP2420.
      
      Charulatha Varadarajan <charu@ti.com> caught a typo - thanks Charu.
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Charulatha Varadarajan <charu@ti.com>
      6515e489
    • Enric Balletbo i Serra's avatar
      omap3: Add minimal OMAP3 IGEP module support · e844b1da
      Enric Balletbo i Serra authored
      
      
      The OMAP3 IGEP module is a low-power, high performance production-ready
      system-on-module (SOM) based on TI's OMAP3 family. More about this
      board at www.igep.es.
      Signed-off-by: default avatarEnric Balletbo i Serra <eballetbo@gmail.com>
      [tony@atomide.com: updated for the mmc changes and to be selected by default]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e844b1da
  26. 29 Sep, 2010 1 commit
    • Govindraj.R's avatar
      OMAP: SERIAL: Enable omap-serial driver in Kconfig · 12a75da2
      Govindraj.R authored
      
      
      Enable omap-serial driver in /mach-omap2/Kconfig and
      move 8250 driver selection for zoom boards. With omap-serial
      driver addition all omap-uarts can be handled with
      omap-serial driver.
      
      With addition of omap-serial driver console parameter
      needs be changed in bootargs from ttyS* should be
      replaced with ttyO* [O --> OMAP not ZERO]
      
      For example: ttyS0[UART1 on 3430SDP] changes to ttyO0.
      
      But with some boards that do not use omap-uart as console uart.
      we need to handle them with 8250 driver. Ex: ZOOM2/3.
      For zoom2/3 board we need to use 8250 serial driver and
      console parameter will remain ttyS0 which basically uses
      a Quad uart placed on the debug board connected through a
      gpio line.
      Signed-off-by: default avatarGovindraj.R <govindraj.raja@ti.com>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      12a75da2