1. 13 2月, 2007 1 次提交
  2. 08 2月, 2007 1 次提交
  3. 18 12月, 2006 1 次提交
  4. 09 12月, 2006 1 次提交
    • R
      [ARM] Handle HWCAP_VFP in VFP support code · efe90d27
      Russell King 提交于
      Don't set HWCAP_VFP in the processor support file; not only does it
      depend on the processor features, but it also depends on the support
      code being present.  Therefore, only set it if the support code
      detects that we have a VFP coprocessor attached.
      
      Also, move the VFP handling of the coprocessor access register into
      the VFP support code.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      efe90d27
  5. 08 12月, 2006 1 次提交
  6. 04 12月, 2006 1 次提交
    • L
      [ARM] 3881/4: xscale: clean up cp0/cp1 handling · afe4b25e
      Lennert Buytenhek 提交于
      XScale cores either have a DSP coprocessor (which contains a single
      40 bit accumulator register), or an iWMMXt coprocessor (which contains
      eight 64 bit registers.)
      
      Because of the small amount of state in the DSP coprocessor, access to
      the DSP coprocessor (CP0) is always enabled, and DSP context switching
      is done unconditionally on every task switch.  Access to the iWMMXt
      coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
      first issued, and iWMMXt context switching is done lazily.
      
      CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
      have iWMMXt support', but boards are supposed to select this config
      symbol by hand, and at least one pxa27x board doesn't get this right,
      so on that board, proc-xscale.S will incorrectly assume that we have a
      DSP coprocessor, enable CP0 on boot, and we will then only save the
      first iWMMXt register (wR0) on context switches, which is Bad.
      
      This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
      might have iWMMXt support, and we will enable iWMMXt context switching
      if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
      kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
      state over context switches, and running a CONFIG_IWMMXT=y kernel on a
      non-iWMMXt capable CPU will still do DSP context save/restore.
      
      These changes should make iWMMXt work on PXA3xx, and as a side effect,
      enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
      as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
      as well as setting and using HWCAP_IWMMXT properly.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      afe4b25e
  7. 03 11月, 2006 1 次提交
  8. 02 10月, 2006 1 次提交
    • S
      [PATCH] namespaces: utsname: use init_utsname when appropriate · 96b644bd
      Serge E. Hallyn 提交于
      In some places, particularly drivers and __init code, the init utsns is the
      appropriate one to use.  This patch replaces those with a the init_utsname
      helper.
      
      Changes: Removed several uses of init_utsname().  Hope I picked all the
      	right ones in net/ipv4/ipconfig.c.  These are now changed to
      	utsname() (the per-process namespace utsname) in the previous
      	patch (2/7)
      
      [akpm@osdl.org: CIFS fix]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Andrey Savochkin <saw@sw.ru>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      96b644bd
  9. 11 7月, 2006 1 次提交
  10. 03 7月, 2006 1 次提交
  11. 01 7月, 2006 1 次提交
  12. 29 6月, 2006 1 次提交
  13. 28 6月, 2006 2 次提交
    • K
      [PATCH] node hotplug: register cpu: remove node struct · 76b67ed9
      KAMEZAWA Hiroyuki 提交于
      With Goto-san's patch, we can add new pgdat/node at runtime.  I'm now
      considering node-hot-add with cpu + memory on ACPI.
      
      I found acpi container, which describes node, could evaluate cpu before
      memory. This means cpu-hot-add occurs before memory hot add.
      
      In most part, cpu-hot-add doesn't depend on node hot add.  But register_cpu(),
      which creates symbolic link from node to cpu, requires that node should be
      onlined before register_cpu().  When a node is onlined, its pgdat should be
      there.
      
      This patch-set holds off creating symbolic link from node to cpu
      until node is onlined.
      
      This removes node arguments from register_cpu().
      
      Now, register_cpu() requires 'struct node' as its argument.  But the array of
      struct node is now unified in driver/base/node.c now (By Goto's node hotplug
      patch).  We can get struct node in generic way.  So, this argument is not
      necessary now.
      
      This patch also guarantees add cpu under node only when node is onlined.  It
      is necessary for node-hot-add vs.  cpu-hot-add patch following this.
      
      Moreover, register_cpu calculates cpu->node_id by cpu_to_node() without regard
      to its 'struct node *root' argument.  This patch removes it.
      
      Also modify callers of register_cpu()/unregister_cpu, whose args are changed
      by register-cpu-remove-node-struct patch.
      
      [Brice.Goglin@ens-lyon.org: fix it]
      Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      76b67ed9
    • G
      [PATCH] 64bit resource: C99 changes for struct resource declarations · 740e518e
      Greg Kroah-Hartman 提交于
      Based on an original patch from Ralf Baechle <ralf@linux-mips.org> and
      Vivek Goyal <vgoyal@in.ibm.com>.  This is needed in order to prepare for
      changing the size of resources.
      
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      740e518e
  14. 21 4月, 2006 2 次提交
  15. 11 4月, 2006 1 次提交
  16. 02 4月, 2006 1 次提交
    • L
      [ARM] 3439/2: xsc3: add I/O coherency support · 23759dc6
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      This patch adds support for the I/O coherent cache available on the
      xsc3.  The approach is to provide a simple API to determine whether the
      chipset supports coherency by calling arch_is_coherent() and then
      setting the appropriate system memory PTE and PMD bits.  In addition,
      we call this API on dma_alloc_coherent() and dma_map_single() calls.
      A generic version exists that will compile out all the coherency-related
      code that is not needed on the majority of ARM systems.
      
      Note that we do not check for coherency in the dma_alloc_writecombine()
      function as that still requires a special PTE setting.  We also don't
      touch dma_mmap_coherent() as that is a special ARM-only API that is by
      definition only used on non-coherent system.
      Signed-off-by: NDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      23759dc6
  17. 22 3月, 2006 1 次提交
  18. 16 3月, 2006 2 次提交
  19. 16 2月, 2006 1 次提交
    • R
      [ARM] Fix SMP initialisation oops · 7bbb7940
      Russell King 提交于
      A change to the SMP initialisation caused the following oops:
      
       CPU1: Booted secondary processor
       CPU1: D VIPT write-back cache
       CPU1: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
       CPU1: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
       <7>Calibrating delay loop... 83.14 BogoMIPS (lpj=415744)
       <1>Unable to handle kernel NULL pointer dereference at virtual address 0000001c
       ...
       PC is at enqueue_task+0x1c/0x64
       LR is at activate_task+0xcc/0xe4
      
      SMP initialisation now requires cpu_possible_map to be initialised in
      setup_arch().  Move this from smp_prepare_cpus() to smp_init_cpus()
      and call it from our setup_arch() if CONFIG_SMP is enabled.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7bbb7940
  20. 13 1月, 2006 1 次提交
  21. 04 1月, 2006 1 次提交
    • R
      [ARM] Cleanup ARM includes · 78ff18a4
      Russell King 提交于
      arch/arm/kernel/entry-armv.S has contained a comment suggesting
      that asm/hardware.h and asm/arch/irqs.h should be moved into the
      asm/arch/entry-macro.S include.  So move the includes to these
      two files as required.
      
      Add missing includes (asm/hardware.h, asm/io.h) to asm/arch/system.h
      includes which use those facilities, and remove asm/io.h from
      kernel/process.c.
      
      Remove other unnecessary includes from arch/arm/kernel, arch/arm/mm
      and arch/arm/mach-footbridge.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      78ff18a4
  22. 07 11月, 2005 2 次提交
  23. 04 7月, 2005 1 次提交
  24. 29 6月, 2005 1 次提交
  25. 23 6月, 2005 1 次提交
  26. 20 6月, 2005 1 次提交
  27. 01 6月, 2005 1 次提交
    • R
      [PATCH] ARM SMP: Fix vector entry · ccea7a19
      Russell King 提交于
      The current vector entry system does not allow for SMP.  In
      order to work around this, we need to eliminate our reliance
      on the fixed save areas, which breaks the way we enable
      alignment traps.  This patch changes the way we handle the
      save areas such that we can have one per CPU.
      Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
      ccea7a19
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4