1. 09 Jul, 2008 1 commit
  2. 05 Jul, 2008 2 commits
  3. 03 Jul, 2008 2 commits
  4. 26 Jun, 2008 1 commit
  5. 22 Jun, 2008 5 commits
    • Stanislav Samsonov's avatar
      [ARM] add Marvell 78xx0 ARM SoC support · 794d15b2
      Stanislav Samsonov authored
      The Marvell Discovery Duo (MV78xx0) is a family of ARM SoCs featuring
      (depending on the model) one or two Feroceon CPU cores with 512K of L2
      cache and VFP coprocessors running at (depending on the model) between
      800 MHz and 1.2 GHz, and features a DDR2 controller, two PCIe
      interfaces that can each run either in x4 or quad x1 mode, three USB
      2.0 interfaces, two 3Gb/s SATA II interfaces, a SPI interface, two
      TWSI interfaces, a crypto accelerator, IDMA/XOR engines, a SPI
      interface, four UARTs, and depending on the model, two or four gigabit
      ethernet interfaces.
      This patch adds basic support for the platform, and allows booting
      on the MV78x00 development board, with functional UARTs, SATA, PCIe,
      GigE and USB ports.
      Signed-off-by: default avatarStanislav Samsonov <samsonov@marvell.com>
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
    • Saeed Bishara's avatar
      [ARM] add Marvell Kirkwood (88F6000) SoC support · 651c74c7
      Saeed Bishara authored
      The Marvell Kirkwood (88F6000) is a family of ARM SoCs based on a
      Shiva CPU core, and features a DDR2 controller, a x1 PCIe interface,
      a USB 2.0 interface, a SPI controller, a crypto accelerator, a TS
      interface, and IDMA/XOR engines, and depending on the model, also
      features one or two Gigabit Ethernet interfaces, two SATA II
      interfaces, one or two TWSI interfaces, one or two UARTs, a
      TDM/SLIC interface, a NAND controller, an I2S/SPDIF interface, and
      an SDIO interface.
      This patch adds supports for the Marvell DB-88F6281-BP Development
      Board and the RD-88F6192-NAS and the RD-88F6281 Reference Designs,
      enabling support for the PCIe interface, the USB interface, the
      ethernet interfaces, the SATA interfaces, the TWSI interfaces, the
      UARTs, and the NAND controller.
      Signed-off-by: default avatarSaeed Bishara <saeed@marvell.com>
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
    • Lennert Buytenhek's avatar
      [ARM] add Marvell Loki (88RC8480) SoC support · 777f9beb
      Lennert Buytenhek authored
      The Marvell Loki (88RC8480) is an ARM SoC based on a Feroceon CPU
      core running at between 400 MHz and 1.0 GHz, and features a 64 bit
      DDR controller, 512K of internal SRAM, two x4 PCI-Express ports,
      two Gigabit Ethernet ports, two 4x SAS/SATA controllers, two UARTs,
      two TWSI controllers, and IDMA/XOR engines.
      This patch adds support for the Marvell LB88RC8480 Development
      Board, enabling the use of the PCIe interfaces, the ethernet
      interfaces, the TWSI interfaces and the UARTs.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
    • Lennert Buytenhek's avatar
    • Nicolas Pitre's avatar
      [ARM] latencytop support · f76e9154
      Nicolas Pitre authored
      Available for !SMP only at the moment.
      From Russell:
      |Basically, if a thread is running on a CPU, thread_saved_fp() is invalid.
      |So, the question is: what guarantees do we have here that 'tsk' is not
      |running on another CPU?
      Signed-off-by: default avatarNicolas Pitre <nico@marvell.com>
      Tested-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
  6. 02 Jun, 2008 1 commit
  7. 19 May, 2008 1 commit
  8. 12 May, 2008 1 commit
  9. 02 May, 2008 1 commit
    • Adrian Bunk's avatar
      [ARM] 5015/1: arm: remove ARCH_CO285 · e055d5bf
      Adrian Bunk authored
      Trying to compile a kerel for ARCH_CO285 fails with the following error:
      <--  snip  -->
        CC      arch/arm/mach-footbridge/dc21285.o
      In function 'dc21285_base_address':
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:54: error: 'PCICFG0_BASE' undeclared (first use in this function)
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:54: error: (Each undeclared identifier is reported only once
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:54: error: for each function it appears in.)
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:57: error: 'PCICFG1_BASE' undeclared (first use in this function)
      In function 'dc21285_scan_bus':
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:286: error: implicit declaration of function 'pci_scan_bus'
      make[2]: *** [arch/arm/mach-footbridge/dc21285.o] Error 1
      <--  snip  -->
      This does not seem to be a recent breakage.
      The ARCH_CO285 support is old - kernel 2.2.0 contains first traces of
      it, an it seems to have been pretty complete in later 2.2 kernels.
      Since it seems to be completely dead code now this patch therefore
      removes it.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  10. 28 Apr, 2008 1 commit
    • Adrian Bunk's avatar
      ARM: always select HAVE_IDE · 2064c946
      Adrian Bunk authored
      It's plain wrong for PCMCIA to select HAVE_IDE that implies e.g. the
      availability of an asm/ide.h
      It turns out this was done for ARM, and we can simply always select 
      HAVE_IDE on ARM instead of manually tracking which platforms might 
      possible have an IDE controller directly or indirectly.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
  11. 19 Apr, 2008 3 commits
  12. 18 Apr, 2008 1 commit
  13. 14 Apr, 2008 2 commits
  14. 10 Apr, 2008 1 commit
  15. 27 Mar, 2008 2 commits
  16. 20 Mar, 2008 1 commit
  17. 04 Mar, 2008 1 commit
  18. 29 Feb, 2008 1 commit
    • Uli Luckas's avatar
      [ARM] 4836/1: Make ATAGS_PROC depend on KEXEC · b98d7291
      Uli Luckas authored
      On Wed, Feb 20, 2008 at 11:50:33AM +0100, Guennadi Liakhovetski wrote:
      > arch/arm/kernel/atags.c uses for some reason the
      > KEXEC_BOOT_PARAMS_SIZE macro, which is only defined if CONFIG_KEXEC
      > is set. So, either this macro should be defined always, or another
      > macro should be used, or ATAGS_PROC should depend on KEXEC.
      As the procfs export of ATAGS is not meant as a stable, general purpose
      ABI it shouldn't be an independent, general configuration option.
      This patch make ATAGS_PROC depend on KEXEC
      Signed-off-by: default avatarUli Luckas <u.luckas@road.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  19. 09 Feb, 2008 1 commit
  20. 08 Feb, 2008 1 commit
  21. 05 Feb, 2008 2 commits
  22. 04 Feb, 2008 5 commits
  23. 03 Feb, 2008 3 commits
    • Adrian Bunk's avatar
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk authored
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
    • Mathieu Desnoyers's avatar
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers authored
      Move the instrumentation Kconfig to
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      init/Kconfig for architecture independent options
        - profiling
        - markers
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
    • Mathieu Desnoyers's avatar
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers authored
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      It would be much better to do
              depends on ARCH_SUPPORTS_KPROBES
      in that generic file, and then architectures that do support it would just
      have a
              bool ARCH_SUPPORTS_KPROBES
                      default y
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
              config KPROBES_SUPPORT
                      def_bool y
      instead, which is a bit denser.
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      - Use HAVE_KPROBES
      - Use a select
      - Yet another update :
      Moving to HAVE_* now.
      - Update ARM for kprobes support.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>