1. 28 9月, 2006 2 次提交
    • H
      [ARM] nommu: manage the CP15 things · f12d0d7c
      Hyok S. Choi 提交于
      All the current CP15 access codes in ARM arch can be categorized and
      conditioned by the defines as follows:
      
           Related operation	Safe condition
        a. any CP15 access	!CPU_CP15
        b. alignment trap	CPU_CP15_MMU
        c. D-cache(C-bit)	CPU_CP15
        d. I-cache		CPU_CP15 && !( CPU_ARM610 || CPU_ARM710 ||
      				CPU_ARM720 || CPU_ARM740 ||
      				CPU_XSCALE || CPU_XSC3 )
        e. alternate vector	CPU_CP15 && !CPU_ARM740
        f. TTB		CPU_CP15_MMU
        g. Domain		CPU_CP15_MMU
        h. FSR/FAR		CPU_CP15_MMU
      
      For example, alternate vector is supported if and only if
      "CPU_CP15 && !CPU_ARM740" is satisfied.
      Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f12d0d7c
    • H
      [ARM] nommu: defines CPU_CP15, CPU_CP15_MMU and CPU_CP15_MPU · fefdaa06
      Hyok S. Choi 提交于
      By merging of uClinux/ARM, we need to treat various CPU cores which have
      MMU, MPU or even none for memory management. The memory management
      coprocessors are controlled by CP15 register set and the ARM core family
      can be categorized by 5 groups by the register ;
        G-a. CP15 is MMU : 610, 710, 720, 920, 922, 925, 926, 1020, 1020e, 1022,
      		v6 and the derivations sa1100, sa110, xscale, xsc3.
        G-b. CP15 is MPU : 740, 940, 946, 996, 1156.
        G-c. CP15 is MPU or MMU : 1026 (selectable by schematic design)
        G-d. CP15 is exist, but nothing for memory managemnt : 966, 968.
        G-e. no-CP15 : 7tdmi, 9tdmi, 9e, 9ej
      
      This patch defines CPU_CP15, CPU_CP15_MMU and CPU_CP15_MPU. Thus the
      family can be defined as :
        - CPU_CP15 only : G-d
        - CPU_CP15_MMU(implies CPU_CP15) : G-a, G-c(selectable)
        - CPU_CP15_MPU(implies CPU_CP15) : G-b, G-c(selectable)
        - !CPU_CP15 : G-e
      Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fefdaa06
  2. 25 9月, 2006 1 次提交
  3. 28 8月, 2006 1 次提交
  4. 29 6月, 2006 3 次提交
  5. 25 6月, 2006 1 次提交
  6. 19 6月, 2006 1 次提交
  7. 18 6月, 2006 1 次提交
  8. 29 3月, 2006 1 次提交
    • L
      [ARM] 3377/2: add support for intel xsc3 core · 23bdf86a
      Lennert Buytenhek 提交于
      Patch from Lennert Buytenhek
      
      This patch adds support for the new XScale v3 core.  This is an
      ARMv5 ISA core with the following additions:
      
      - L2 cache
      - I/O coherency support (on select chipsets)
      - Low-Locality Reference cache attributes (replaces mini-cache)
      - Supersections (v6 compatible)
      - 36-bit addressing (v6 compatible)
      - Single instruction cache line clean/invalidate
      - LRU cache replacement (vs round-robin)
      
      I attempted to merge the XSC3 support into proc-xscale.S, but XSC3
      cores have separate errata and have to handle things like L2, so it
      is simpler to keep it separate.
      
      L2 cache support is currently a build option because the L2 enable
      bit must be set before we enable the MMU and there is no easy way to
      capture command line parameters at this point.
      
      There are still optimizations that can be done such as using LLR for
      copypage (in theory using the exisiting mini-cache code) but those
      can be addressed down the road.
      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>
      23bdf86a
  9. 22 3月, 2006 2 次提交
  10. 10 1月, 2006 1 次提交
  11. 09 1月, 2006 1 次提交
  12. 10 11月, 2005 2 次提交
    • T
      [ARM] 3145/1: OMAP 3a/5: Add support for omap24xx · 1dbae815
      Tony Lindgren 提交于
      Patch from Tony Lindgren
      
      This patch adds support for omap24xx series of processors.
      The files live in arch/arm/mach-omap2, and share common
      files with omap15xx and omap16xx processors in
      arch/arm/plat-omap.
      
      Omap24xx support was originally added for 2.6.9 by TI.
      This code was then improved and integrated to share common
      code with omap15xx and omap16xx processors by various
      omap developers, such as Paul Mundt, Juha Yrjola, Imre Deak,
      Tony Lindgren, Richard Woodruff, Nishant Menon, Komal Shah
      et al.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1dbae815
    • T
      [ARM] 3141/1: OMAP 1/5: Update omap1 specific files · 3179a019
      Tony Lindgren 提交于
      Patch from Tony Lindgren
      
      This patch syncs the mainline kernel with linux-omap tree.
      The highlights of the patch are:
      
      - Omap1 serial pport and framebuffer init updates by Imre Deak
      
      - Add support for omap310 processor and Palm Tungsten E PDA
        by Laurent Gonzales, Romain Goyet, et al. Omap310 and
        omap1510 processors are now handled as omap15xx.
      
      - Omap1 specific changes to shared omap clock framework
        by Tony Lindgren
      
      - Omap1 specific changes to shared omap pin mux framework
        by Tony Lindgren
      
      - Other misc fixes, such as update memory timings for smc91x,
        omap1 specific device initialization etc.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3179a019
  13. 03 11月, 2005 1 次提交
  14. 31 10月, 2005 1 次提交
  15. 06 10月, 2005 1 次提交
  16. 17 8月, 2005 1 次提交
  17. 11 7月, 2005 1 次提交
  18. 21 6月, 2005 1 次提交
  19. 09 6月, 2005 1 次提交
  20. 08 6月, 2005 1 次提交
  21. 13 5月, 2005 1 次提交
  22. 11 5月, 2005 1 次提交
  23. 06 5月, 2005 1 次提交
  24. 04 5月, 2005 1 次提交
  25. 30 4月, 2005 1 次提交
    • N
      [PATCH] ARM: 2651/3: kernel helpers for NPTL support · 2d2669b6
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      This patch entirely reworks the kernel assistance for NPTL on ARM.
      In particular this provides an efficient way to retrieve the TLS
      value and perform atomic operations without any instruction emulation
      nor special system call.  This even allows for pre ARMv6 binaries to
      be forward compatible with SMP systems without any penalty.
      The problematic and performance critical operations are performed
      through segment of kernel provided user code reachable from user space
      at a fixed address in kernel memory.  Those fixed entry points are
      within the vector page so we basically get it for free as no extra
      memory page is required and nothing else may be mapped at that
      location anyway.
      This is different from (but doesn't preclude) a full blown VDSO
      implementation, however a VDSO would prevent some assembly tricks with
      constants that allows for efficient branching to those code segments.
      And since those code segments only use a few cycles before returning to
      user code, the overhead of a VDSO far call would add a significant
      overhead to such minimalistic operations.
      The ARM_NR_set_tls syscall also changed number.  This is done for two
      reasons:
      1) this patch changes the way the TLS value was previously meant to be
         retrieved, therefore we ensure whatever library using the old way
         gets fixed (they only exist in private tree at the moment since the
         NPTL work is still progressing).
      2) the previous number was allocated in a range causing an undefined
         instruction trap on kernels not supporting that syscall and it was
         determined that allocating it in a range returning -ENOSYS would be
         much nicer for libraries trying to determine if the feature is
         present or not.
      
      Signed-off-by: Nicolas Pitre
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2d2669b6
  26. 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