1. 10 7月, 2008 1 次提交
  2. 05 7月, 2008 2 次提交
  3. 03 7月, 2008 2 次提交
  4. 26 6月, 2008 1 次提交
  5. 23 6月, 2008 5 次提交
    • S
      [ARM] add Marvell 78xx0 ARM SoC support · 794d15b2
      Stanislav Samsonov 提交于
      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: NStanislav Samsonov <samsonov@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      794d15b2
    • S
      [ARM] add Marvell Kirkwood (88F6000) SoC support · 651c74c7
      Saeed Bishara 提交于
      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: NSaeed Bishara <saeed@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      651c74c7
    • L
      [ARM] add Marvell Loki (88RC8480) SoC support · 777f9beb
      Lennert Buytenhek 提交于
      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: NLennert Buytenhek <buytenh@marvell.com>
      777f9beb
    • L
    • N
      [ARM] latencytop support · f76e9154
      Nicolas Pitre 提交于
      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: NNicolas Pitre <nico@marvell.com>
      Tested-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      f76e9154
  6. 02 6月, 2008 1 次提交
  7. 19 5月, 2008 1 次提交
  8. 13 5月, 2008 1 次提交
  9. 03 5月, 2008 1 次提交
    • A
      [ARM] 5015/1: arm: remove ARCH_CO285 · e055d5bf
      Adrian Bunk 提交于
      Trying to compile a kerel for ARCH_CO285 fails with the following error:
      
      <--  snip  -->
      
      ...
        CC      arch/arm/mach-footbridge/dc21285.o
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:
      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)
      /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mach-footbridge/dc21285.c:
      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: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e055d5bf
  10. 29 4月, 2008 1 次提交
    • A
      ARM: always select HAVE_IDE · 2064c946
      Adrian Bunk 提交于
      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: NAdrian Bunk <bunk@kernel.org>
      Cc: Russell King <rmk+lkml@arm.linux.org.uk>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      2064c946
  11. 20 4月, 2008 1 次提交
  12. 19 4月, 2008 3 次提交
  13. 15 4月, 2008 2 次提交
  14. 10 4月, 2008 1 次提交
  15. 28 3月, 2008 2 次提交
  16. 20 3月, 2008 1 次提交
  17. 05 3月, 2008 1 次提交
  18. 01 3月, 2008 1 次提交
    • U
      [ARM] 4836/1: Make ATAGS_PROC depend on KEXEC · b98d7291
      Uli Luckas 提交于
      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: NUli Luckas <u.luckas@road.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b98d7291
  19. 09 2月, 2008 2 次提交
  20. 06 2月, 2008 2 次提交
  21. 05 2月, 2008 4 次提交
  22. 04 2月, 2008 1 次提交
    • R
      [ARM] 4736/1: Export atags to userspace and allow kexec to use customised atags · 4cd9d6f7
      Richard Purdie 提交于
      Currently, the atags used by kexec are fixed to the ones originally used
      to boot the kernel. This is less than ideal as changing the commandline,
      initrd and other options would be a useful feature.
      
      This patch exports the atags used for the current kernel to userspace
      through an "atags" file in procfs. The presence of the file is
      controlled by its own Kconfig option and cleans up several ifdef blocks
      into a separate file. The tags for the new kernel are assumed to be at
      a fixed location before the kernel image itself. The location of the
      tags used to boot the original kernel is unimportant and no longer
      saved.
      
      Based on a patch from Uli Luckas <u.luckas@road.de>
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Acked-by: NUli Luckas <u.luckas@road.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4cd9d6f7
  23. 03 2月, 2008 3 次提交
    • A
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk 提交于
      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
      place.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      03502faa
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      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: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      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...
      
      Changelog:
      
      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: NMathieu 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: NSam Ravnborg <sam@ravnborg.org>
      3f550096