1. 06 11月, 2008 1 次提交
  2. 03 10月, 2008 1 次提交
  3. 01 10月, 2008 1 次提交
  4. 25 9月, 2008 3 次提交
    • R
      [ARM] Print details relevant to how we handle the cache · 2b4ae1f1
      Russell King 提交于
      This replaces the original cache type decoding printks.  We now
      indicate how we're treating the cache which we found, rather
      than what we found.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2b4ae1f1
    • R
      [ARM] Introduce new bitmask based cache type macros · c0e95878
      Russell King 提交于
      Rather than trying to (inaccurately) decode the cache type from the
      registers each time we need to decide what type of cache we have,
      use a bitmask initialized early during boot.
      
      Since the setup is a one-off initialization, we can be a little more
      clever and take account of the CPU architecture as well.
      
      Note that we continue to achieve the compactness on optimised kernels
      by forcing tests to always-false or always-true as appropriate, thereby
      allowing the compiler to do build-time code elimination.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0e95878
    • R
      [ARM] Remove cache type printks · 90f1e084
      Russell King 提交于
      The cache type register found in ARMv5 and later CPUs changes format
      and meaning depending on the CPU architecture version.  Currently,
      this code:
      a) doesn't work for everything - Xscale's are identified as
         'unknown 5'.
      b) is not able to tell whether the caches are VIVT or VIPT from the
         cache type.
      c) prints rubbish on some ARMv6 and ARMv7+ CPUs.
      
      The two solutions to this are:
      1. Add yet more code to decode and print the various different register
         formats.
      2. Remove the code altogther.
      
      The code only exists to decode and print the cache parameters.
      Increasing the complexity of it just for the sake of a few prinks
      isn't worth it.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      90f1e084
  5. 06 9月, 2008 2 次提交
  6. 05 9月, 2008 1 次提交
    • R
      [ARM] sparse: fix several warnings · 09d9bae0
      Russell King 提交于
      arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?
      
      This function isn't used, so can be removed.
      
      arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
      arch/arm/kernel/setup.c:524:6: originally declared here
      
      A function containing two 'len's.
      
      arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
      arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
      arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?
      
      Missing includes.
      
      arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
      arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)
      
      Sillies.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      09d9bae0
  7. 01 9月, 2008 2 次提交
  8. 09 8月, 2008 1 次提交
    • L
      [ARM] prevent crashing when too much RAM installed · 60296c71
      Lennert Buytenhek 提交于
      This patch will truncate and/or ignore memory banks if their kernel
      direct mappings would (partially) overlap with the vmalloc area or
      the mappings between the vmalloc area and the address space top, to
      prevent crashing during early boot if there happens to be more RAM
      installed than we are expecting.
      
      Since the start of the vmalloc area is not at a fixed address (but
      the vmalloc end address is, via the per-platform VMALLOC_END define),
      a default area of 128M is reserved for vmalloc mappings, which can
      be shrunk or enlarged by passing an appropriate vmalloc= command line
      option as it is done on x86.
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe000000,
      two 512M RAM banks and vmalloc=128M (the default), this patch gives:
      
      	Truncating RAM at 20000000-3fffffff to -35ffffff (vmalloc region overlap).
      	Memory: 512MB 352MB = 864MB total
      
      On a board with a 3:1 user:kernel split, VMALLOC_END at 0xfe800000,
      two 256M RAM banks and vmalloc=768M, this patch gives:
      
      	Truncating RAM at 00000000-0fffffff to -0e7fffff (vmalloc region overlap).
      	Ignoring RAM at 10000000-1fffffff (vmalloc region overlap).
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Tested-by: NRiku Voipio <riku.voipio@iki.fi>
      60296c71
  9. 24 7月, 2008 1 次提交
    • J
      kgdb: support for ARCH=arm · 5cbad0eb
      Jason Wessel 提交于
      This patch adds the ARCH=arm specific a kgdb backend, originally
      written by Deepak Saxena <dsaxena@plexity.net> and George Davis
      <gdavis@mvista.com>.  Geoff Levand <geoffrey.levand@am.sony.com>,
      Nicolas Pitre, Manish Lachwani, and Jason Wessel have contributed
      various fixups here as well.
      
      The KGDB patch makes one change to the core ARM architecture such that
      the traps are initialized early for use with the debugger or other
      subsystems.
      
      [ mingo@elte.hu: small cleanups. ]
      [ ben-linux@fluff.org: fixed early_trap_init ]
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NDeepak Saxena <dsaxena@plexity.net>
      5cbad0eb
  10. 10 2月, 2008 1 次提交
  11. 04 2月, 2008 2 次提交
  12. 13 10月, 2007 2 次提交
    • M
      [ARM] 4599/1: Preserve ATAG list for use with kexec (2.6.23) · 033b8ffe
      Mike Westerhof 提交于
      This patch resolves a kexec boot failure that can occur because
      no ATAGs are passed in to the kexec'd kernel. Currently the
      newly-kexec'd kernel may fail if it requires specific ATAGs, or
      it may fail because the fixed memory location at which it expects
      to find the ATAGs may contain random data instead of ATAGs.
      
      The patch ensures that any ATAGs passed to the current kernel
      at boot time are copied to a static buffer, and are copied back
      when kexec copies the new kernel into place. Thus the new
      kernel sees the same ATAGs from kexec and the boot loader.
      
      The boot parameters are copied without regard to type, content,
      or length -- this patch's scope is limited soley to saving and
      restoring a fixed-size block of memory containing the kernel's
      boot parameters. Additional functionality to examine, alter, or
      replace the ATAGs (using kexec, for example) can be implemented
      by manipulating the static buffer containing the preserved ATAGs.
      
      Note: the size of the buffer (1.5KB) is selected to comfortably
      hold one of each ATAG type, including a maximum-length command
      line and the maximum number of ATAG_MEM structures currently
      supported by the kernel. Should an ATAG list exceed that limit,
      the list will be silently truncated to that limit (to do other-
      wise at that point in the boot process would make a simple
      problem exceedingly complicated).
      
      [Note: this is the same patch as 4579, modified to accomodate
      the ATAG changes introduced in 2.6.23]
      
      Signed-off-by: Mike Westerhof <mwester at dls.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      033b8ffe
    • C
      [ARM] 4585/1: Correctly identify the CPU architecture version · 180005c4
      Catalin Marinas 提交于
      The cpu_architecture() function in arch/arm/kernel/setup.c only works
      with cores produced by ARM Ltd. The more generic approach is to read
      the ID_MMFR0 register and check for the VMSA or PMSA version
      supported. With this patch, the ARM11MPCore would be reported as ARMv7
      since its MMU is compatible with ARMv7.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      180005c4
  13. 30 7月, 2007 1 次提交
    • A
      Remove fs.h from mm.h · 4e950f6f
      Alexey Dobriyan 提交于
      Remove fs.h from mm.h. For this,
       1) Uninline vma_wants_writenotify(). It's pretty huge anyway.
       2) Add back fs.h or less bloated headers (err.h) to files that need it.
      
      As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files
      rebuilt down to 3444 (-12.3%).
      
      Cross-compile tested without regressions on my two usual configs and (sigh):
      
      alpha              arm-mx1ads        mips-bigsur          powerpc-ebony
      alpha-allnoconfig  arm-neponset      mips-capcella        powerpc-g5
      alpha-defconfig    arm-netwinder     mips-cobalt          powerpc-holly
      alpha-up           arm-netx          mips-db1000          powerpc-iseries
      arm                arm-ns9xxx        mips-db1100          powerpc-linkstation
      arm-assabet        arm-omap_h2_1610  mips-db1200          powerpc-lite5200
      arm-at91rm9200dk   arm-onearm        mips-db1500          powerpc-maple
      arm-at91rm9200ek   arm-picotux200    mips-db1550          powerpc-mpc7448_hpc2
      arm-at91sam9260ek  arm-pleb          mips-ddb5477         powerpc-mpc8272_ads
      arm-at91sam9261ek  arm-pnx4008       mips-decstation      powerpc-mpc8313_rdb
      arm-at91sam9263ek  arm-pxa255-idp    mips-e55             powerpc-mpc832x_mds
      arm-at91sam9rlek   arm-realview      mips-emma2rh         powerpc-mpc832x_rdb
      arm-ateb9200       arm-realview-smp  mips-excite          powerpc-mpc834x_itx
      arm-badge4         arm-rpc           mips-fulong          powerpc-mpc834x_itxgp
      arm-carmeva        arm-s3c2410       mips-ip22            powerpc-mpc834x_mds
      arm-cerfcube       arm-shannon       mips-ip27            powerpc-mpc836x_mds
      arm-clps7500       arm-shark         mips-ip32            powerpc-mpc8540_ads
      arm-collie         arm-simpad        mips-jazz            powerpc-mpc8544_ds
      arm-corgi          arm-spitz         mips-jmr3927         powerpc-mpc8560_ads
      arm-csb337         arm-trizeps4      mips-malta           powerpc-mpc8568mds
      arm-csb637         arm-versatile     mips-mipssim         powerpc-mpc85xx_cds
      arm-ebsa110        i386              mips-mpc30x          powerpc-mpc8641_hpcn
      arm-edb7211        i386-allnoconfig  mips-msp71xx         powerpc-mpc866_ads
      arm-em_x270        i386-defconfig    mips-ocelot          powerpc-mpc885_ads
      arm-ep93xx         i386-up           mips-pb1100          powerpc-pasemi
      arm-footbridge     ia64              mips-pb1500          powerpc-pmac32
      arm-fortunet       ia64-allnoconfig  mips-pb1550          powerpc-ppc64
      arm-h3600          ia64-bigsur       mips-pnx8550-jbs     powerpc-prpmc2800
      arm-h7201          ia64-defconfig    mips-pnx8550-stb810  powerpc-ps3
      arm-h7202          ia64-gensparse    mips-qemu            powerpc-pseries
      arm-hackkit        ia64-sim          mips-rbhma4200       powerpc-up
      arm-integrator     ia64-sn2          mips-rbhma4500       s390
      arm-iop13xx        ia64-tiger        mips-rm200           s390-allnoconfig
      arm-iop32x         ia64-up           mips-sb1250-swarm    s390-defconfig
      arm-iop33x         ia64-zx1          mips-sead            s390-up
      arm-ixp2000        m68k              mips-tb0219          sparc
      arm-ixp23xx        m68k-amiga        mips-tb0226          sparc-allnoconfig
      arm-ixp4xx         m68k-apollo       mips-tb0287          sparc-defconfig
      arm-jornada720     m68k-atari        mips-workpad         sparc-up
      arm-kafa           m68k-bvme6000     mips-wrppmc          sparc64
      arm-kb9202         m68k-hp300        mips-yosemite        sparc64-allnoconfig
      arm-ks8695         m68k-mac          parisc               sparc64-defconfig
      arm-lart           m68k-mvme147      parisc-allnoconfig   sparc64-up
      arm-lpd270         m68k-mvme16x      parisc-defconfig     um-x86_64
      arm-lpd7a400       m68k-q40          parisc-up            x86_64
      arm-lpd7a404       m68k-sun3         powerpc              x86_64-allnoconfig
      arm-lubbock        m68k-sun3x        powerpc-cell         x86_64-defconfig
      arm-lusl7200       mips              powerpc-celleb       x86_64-up
      arm-mainstone      mips-atlas        powerpc-chrp32
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4e950f6f
  14. 12 7月, 2007 1 次提交
  15. 21 5月, 2007 1 次提交
  16. 13 3月, 2007 1 次提交
  17. 13 2月, 2007 1 次提交
  18. 08 2月, 2007 1 次提交
  19. 18 12月, 2006 1 次提交
  20. 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
  21. 08 12月, 2006 1 次提交
  22. 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
  23. 03 11月, 2006 1 次提交
  24. 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
  25. 11 7月, 2006 1 次提交
  26. 03 7月, 2006 1 次提交
  27. 01 7月, 2006 1 次提交
  28. 29 6月, 2006 1 次提交
  29. 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
  30. 21 4月, 2006 2 次提交
  31. 11 4月, 2006 1 次提交
  32. 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