1. 03 3月, 2012 3 次提交
    • K
      ARM: S3C2416: move mach-s3c2416/* into mach-s3c24xx/ · 26febf8e
      Kukjin Kim 提交于
      This patch moves S3C2416 stuff into mach-s3c24xx/ directory
      so that we can merge the s3c24 series' directories to the
      just one mach-s3c24xx/ directory.
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      [kgene.kim@samsung.com: removed compiling s3c2416 as per Heiko's suggestion]
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      26febf8e
    • K
      ARM: S3C2410: move mach-s3c2410/* into mach-s3c24xx/ · 85fd6d63
      Kukjin Kim 提交于
      This patch moves S3C2410 stuff into mach-s3c24xx/ directory
      so that we can merge the s3c24 series' directories to the
      just one mach-s3c24xx/ directory.
      
      And this patch is including following.
      - re-ordered alphabetically by option text at Kconfig and Makefile
      - removed unused option, MACH_N35
      - fixed duplcated option name, S3C2410_DMA to S3C24XX_DMA which is
        in plat-s3c24xx/
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      85fd6d63
    • K
      ARM: S3C24XX: change the ARCH_S3C2410 to ARCH_S3C24XX · b130d5c2
      Kukjin Kim 提交于
      This patch changes the ARCH name to "ARCH_S3C24XX" for Samsung
      S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443,
      and S3C2450 SoCs so that we can merge the mach-xxx directories
      and plat-s3c24xx dir. to just one mach-s3c24xx for them.
      
      I think this should be sent to upstream via samsung tree because
      this touches many samsung stuff.
      
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Chris Ball <cjb@laptop.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      [for the gadget part:]
      Acked-by: NFelipe Balbi <balbi@ti.com>
      [for the framebuffer (video) part:]
      Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      [For the watchdog-part:]
      Acked-by: NWim Van Sebroeck <wim@iguana.be>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      b130d5c2
  2. 05 1月, 2012 1 次提交
  3. 06 11月, 2011 1 次提交
    • K
      ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos · 83014579
      Kukjin Kim 提交于
      The arch/arm/mach-exynos4 directory (CONFIG_ARCH_EXYNOS4) has
      made for plaforms based on EXYNOS4 SoCs. But since upcoming
      Samsung's SoCs such as EXYNOS5 (ARM Cortex A15) can reuse most
      codes in current mach-exynos4, one mach-exynos directory will
      be used for them.
      
      This patch changes to CONFIG_ARCH_EXYNOS (arch/arm/mach-exynos)
      but keeps original CONFIG_ARCH_EXYNOS4 in mach-exynos/Kconfig to
      avoid changing in driver side.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      83014579
  4. 31 10月, 2011 3 次提交
  5. 26 9月, 2011 1 次提交
    • J
      picoxcell: support for Picochip picoxcell devices · af75655c
      Jamie Iles 提交于
      picoXcell is a family of femtocell devices with an ARM application
      processor and picoArray DSP processor array.
      
      This patch adds support for picoXcell boards to be booted using the
      device tree registering the VIC's, UART's and timers.
      
      v3:	- fixup vic compatible string in binding
      v2:	- cleanup empty mach headers
      	- convert to of_platform_populate()
      	- simplify uncompress.h
      	- split vic node into 2 devices
      	- add missing __initconst attributes
      Signed-off-by: NJamie Iles <jamie@jamieiles.com>
      af75655c
  6. 22 9月, 2011 1 次提交
    • N
      ARM: mach-nuc93x: delete · 4702abd3
      Nicolas Pitre 提交于
      This architecture received only generic maintenance since December 2009
      when it was originally submitted, and no actual additional support since
      then.  It has no defconfig entry either, meaning that it was never built
      by the ARM KAutobuild.  Incidentally it currently doesn't build either
      when CONFIG_MACH_NUC932EVB is selected which is the only possible config
      choice.
      
      This is therefore dead code and should be removed.  If someone wants to
      revive this code, it could be retrieved from the Git repository, and
      ideally be merged in mach-w90x900/ instead.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Wan ZongShun <mcuos.com@gmail.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4702abd3
  7. 24 8月, 2011 1 次提交
  8. 13 8月, 2011 1 次提交
    • S
      ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs · 9e775ad1
      Stephen Boyd 提交于
      MSMs post 8x50 have 2Mb at the beginning of RAM reserved for
      shared memory. Since the kernel hasn't typically been told this
      RAM exists, PHYS_OFFSET has been set to 0xN0200000 and the memory
      atags passed to the kernel have matched. This doesn't play nicely
      with things such as AUTO_ZRELADDR, which doesn't work at all, and
      dynamic phys to virt, which requires an MSM specific workaround.
      
      Work around these issues by telling the kernel RAM starts at
      0xN0000000 (it actually does) and fixup the atags from the
      bootloader (if necessary) to say the same. In addition, make sure
      to set TEXT_OFFSET at least 2Mb beyond the start of RAM so that
      the kernel doesn't end up being decompressed into shared memory.
      
      After doing this, AUTO_ZRELADDR should work on MSM with no
      problems and ARM_PATCH_PHYS_VIRT_16BIT should no longer be
      necessary.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9e775ad1
  9. 25 7月, 2011 1 次提交
  10. 18 7月, 2011 3 次提交
    • N
      ARM: mach-loki: delete · c8b7d43b
      Nicolas Pitre 提交于
      This was introduced more than 3 years ago, and since then only generic
      janitorial changes were made without further addition of actual support
      for "real" devices.  This is therefore a cost with no benefits to keep
      in the tree.  If someone wishes to revive this code, it is always
      possible to retrieve it from the Git repository.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      CC: Ke Wei <kewei@marvell.com>
      CC: Saeed Bishara <saeed@marvell.com>
      CC: Lennert Buytenhek <buytenh@wantstofly.org>
      c8b7d43b
    • N
      ARM: mach-s3c2400: delete · 632b7cf6
      Nicolas Pitre 提交于
      On Tue, 28 Jun 2011, Ben Dooks wrote:
      
      > On Tue, Jun 28, 2011 at 11:22:57PM +0200, Arnd Bergmann wrote:
      >
      > > On a related note, what about mach-s3c2400? It seems to be even more
      > > incomplete.
      >
      > Probably the same fate awaits that. It is so old that there's little
      > incentive to do anything with it.
      
      So out it goes as well.
      
      The PORT_S3C2400 definition in include/linux/serial_core.h is left there
      to prevent a reuse of the same number for another port type.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      632b7cf6
    • N
      ARM: mach-s3c24a0: delete · af0e060e
      Nicolas Pitre 提交于
      Commit bcae8aeb "[ARM] S3C24A0: Initial architecture support files"
      brought in a bunch of files while explicitly leaving out the corresponding
      Kconfig entry, stating that the series is not complete.
      
      More than 2.5 years later, the support for this has not seen any progress.
      This is therefore dead code.  If someone wants to revive this code, it is
      always possible to retrieve it from the Git repository.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: NBen Dooks <ben-linux@fluff.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      af0e060e
  11. 09 7月, 2011 1 次提交
  12. 21 6月, 2011 1 次提交
    • J
      ARM: Xilinx: Adding Xilinx board support · b85a3ef4
      John Linn 提交于
      The 1st board support is minimal to get a system up and running
      on the Xilinx platform.
      
      This platform reuses the clock implementation from plat-versatile, and
      it depends entirely on CONFIG_OF support.  There is only one board
      support file which obtains all device information from a device tree
      dtb file which is passed to the kernel at boot time.
      Signed-off-by: NJohn Linn <john.linn@xilinx.com>
      b85a3ef4
  13. 19 5月, 2011 2 次提交
  14. 12 5月, 2011 1 次提交
  15. 03 5月, 2011 3 次提交
    • W
      ARM: plat-stmp: remove plat · 041f10d4
      Wolfram Sang 提交于
      Now that both users of plat-stmp have been deleted in previous patches,
      delete the platform, too.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      041f10d4
    • W
      ARM: mach-stmp378x: remove mach · f295dc68
      Wolfram Sang 提交于
      This mach has not seen any updates since the initial inclusion besides
      generic cleanup. Furthermore:
      
      - The i.MX23 covered in mach-mxs is just a renamed version of the
        STMP378x.
      
      - mach-stmp378x has a lot of reinvented interfaces, leaking all sorts of
        mach-related includes into the drivers. One example is the dmaengine
        which does not use the linux dmaengine-API but some privately exported
        symbols. So drivers cannot be reused. mach-mxs does it better.
      
      - There is only one board defined (which I couldn't find any trace of
        despite being a development board). It has been converted to
        mach-mxs in a previous patch.
      
      Since the only user of this mach was converted, it means that
      mach-stmp378x can go.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f295dc68
    • W
      ARM: mach-stmp37xx: remove mach · 76359658
      Wolfram Sang 提交于
      This mach has not seen any updates since the initial inclusion besides
      generic cleanup. Furthermore:
      
      - It has a lot of reinvented interfaces, leaking all sorts of
        mach-related includes into the drivers. One example is the dmaengine
        which does not use the linux dmaengine-API but some privately exported
        symbols. So, drivers cannot be reused. mach-mxs is very similar and
        does it better.
      
      - It can be doubted that this worked at all. Check the DMA routines in
        stmp37xx.c for copy/paste bugs. A lot of APBX-related stuff is
        actually writing into registers for APBH.
      
      - There is only one board defined (which I couldn't find any trace of
        despite being a development board). In this board, only two devices
        have resources, the debug uart and the application uart. Neither of
        those have the needed custom drivers merged (and never will). debug
        uart is amba-pl011 which has an in-kernel driver without the
        mach-specific-stuff. appuart has a driver which was introduced for
        mach-mxs, and this one is reusable for a properly done mach.
      
      So, this single board registers only unsupported devices and the
      generic code looks suspicious and has poor design. Delete this
      stuff. If there is interest, it is wiser to restart using
      mach-mxs.
      Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      76359658
  16. 29 4月, 2011 1 次提交
  17. 11 3月, 2011 1 次提交
    • D
      ARM: 6781/1: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas · 6f685c5c
      Dave Martin 提交于
      Various binutils versions can resolve Thumb-2 branches to
      locally-defined, preemptible global symbols as short-range "b.n"
      branch instructions.
      
      This is a problem, because there's no guarantee the final
      destination of the symbol, or any candidate locations for a
      trampoline, are within range of the branch.  For this reason, the
      kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
      relocation in modules at all, and it makes little sense to add
      support.
      
      The symptom is that the kernel fails with an "unsupported
      relocation" error when loading some modules.
      
      Until fixed tools are available, passing
      -fno-optimize-sibling-calls to gcc should prevent gcc generating
      code which hits this problem, at the cost of a bit of extra runtime
      stack usage in some cases.
      
      The problem is described in more detail at:
          https://bugs.launchpad.net/binutils-linaro/+bug/725126
      
      Only Thumb-2 kernels are affected.
      
      This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
      option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
      when building a Thumb-2 kernel.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6f685c5c
  18. 24 2月, 2011 1 次提交
  19. 22 2月, 2011 2 次提交
  20. 12 2月, 2011 1 次提交
  21. 03 2月, 2011 1 次提交
  22. 25 1月, 2011 2 次提交
  23. 21 12月, 2010 1 次提交
  24. 20 11月, 2010 1 次提交
  25. 18 10月, 2010 1 次提交
  26. 02 10月, 2010 1 次提交
  27. 18 9月, 2010 1 次提交
  28. 15 8月, 2010 1 次提交
  29. 06 8月, 2010 1 次提交