1. 01 8月, 2013 1 次提交
  2. 30 5月, 2013 1 次提交
  3. 03 10月, 2012 1 次提交
  4. 05 5月, 2012 1 次提交
  5. 24 3月, 2012 1 次提交
  6. 08 12月, 2011 1 次提交
    • C
      ARM: LPAE: Introduce the 3-level page table format definitions · dcfdae04
      Catalin Marinas 提交于
      This patch introduces the pgtable-3level*.h files with definitions
      specific to the LPAE page table format (3 levels of page tables).
      
      Each table is 4KB and has 512 64-bit entries. An entry can point to a
      40-bit physical address. The young, write and exec software bits share
      the corresponding hardware bits (negated). Other software bits use spare
      bits in the PTE.
      
      The patch also changes some variable types from unsigned long or int to
      pteval_t or pgprot_t.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      dcfdae04
  7. 06 10月, 2011 1 次提交
  8. 26 5月, 2011 1 次提交
    • W
      ARM: 6913/1: sparsemem: allow pfn_valid to be overridden when using SPARSEMEM · 7b7bf499
      Will Deacon 提交于
      In commit eb33575c ("[ARM] Double check memmap is actually valid with a
      memmap has unexpected holes V2"), a new function, memmap_valid_within,
      was introduced to mmzone.h so that holes in the memmap which pass
      pfn_valid in SPARSEMEM configurations can be detected and avoided.
      
      The fix to this problem checks that the pfn <-> page linkages are
      correct by calculating the page for the pfn and then checking that
      page_to_pfn on that page returns the original pfn. Unfortunately, in
      SPARSEMEM configurations, this results in reading from the page flags to
      determine the correct section. Since the memmap here has been freed,
      junk is read from memory and the check is no longer robust.
      
      In the best case, reading from /proc/pagetypeinfo will give you the
      wrong answer. In the worst case, you get SEGVs, Kernel OOPses and hung
      CPUs. Furthermore, ioremap implementations that use pfn_valid to
      disallow the remapping of normal memory will break.
      
      This patch allows architectures to provide their own pfn_valid function
      instead of using the default implementation used by sparsemem. The
      architecture-specific version is aware of the memmap state and will
      return false when passed a pfn for a freed page within a valid section.
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7b7bf499
  9. 27 11月, 2010 1 次提交
  10. 05 10月, 2009 1 次提交
  11. 12 9月, 2009 1 次提交
    • R
      ARM: Fix pfn_valid() for sparse memory · b7cfda9f
      Russell King 提交于
      On OMAP platforms, some people want to declare to segment up the memory
      between the kernel and a separate application such that there is a hole
      in the middle of the memory as far as Linux is concerned.  However,
      they want to be able to mmap() the hole.
      
      This currently causes problems, because update_mmu_cache() thinks that
      there are valid struct pages for the "hole".  Fix this by making
      pfn_valid() slightly more expensive, by checking whether the PFN is
      contained within the meminfo array.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: NKhasim Syed Mohammed <khasim@ti.com>
      b7cfda9f
  12. 25 6月, 2009 1 次提交
  13. 12 6月, 2009 1 次提交
  14. 03 6月, 2009 1 次提交
  15. 25 3月, 2009 1 次提交
  16. 28 11月, 2008 2 次提交
  17. 27 11月, 2008 1 次提交
    • R
      [ARM] remove memzero() · 59f0cb0f
      Russell King 提交于
      As suggested by Andrew Morton, remove memzero() - it's not supported
      on other architectures so use of it is a potential build breaking bug.
      Since the compiler optimizes memset(x,0,n) to __memzero() perfectly
      well, we don't miss out on the underlying benefits of memzero().
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      59f0cb0f
  18. 01 10月, 2008 1 次提交
  19. 03 8月, 2008 1 次提交
  20. 25 7月, 2008 1 次提交
    • A
      PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architectures · 27ac792c
      Andrea Righi 提交于
      On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
      boundary. For example:
      
      	u64 val = PAGE_ALIGN(size);
      
      always returns a value < 4GB even if size is greater than 4GB.
      
      The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
      example):
      
      #define PAGE_SHIFT      12
      #define PAGE_SIZE       (_AC(1,UL) << PAGE_SHIFT)
      #define PAGE_MASK       (~(PAGE_SIZE-1))
      ...
      #define PAGE_ALIGN(addr)       (((addr)+PAGE_SIZE-1)&PAGE_MASK)
      
      The "~" is performed on a 32-bit value, so everything in "and" with
      PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
      Using the ALIGN() macro seems to be the right way, because it uses
      typeof(addr) for the mask.
      
      Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
      include/linux/mm.h.
      
      See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
      
      [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
      [akpm@linux-foundation.org: fix v850]
      [akpm@linux-foundation.org: fix powerpc]
      [akpm@linux-foundation.org: fix arm]
      [akpm@linux-foundation.org: fix mips]
      [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
      [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
      [akpm@linux-foundation.org: fix powerpc]
      Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      27ac792c
  21. 23 5月, 2008 1 次提交
  22. 29 4月, 2008 1 次提交
  23. 09 2月, 2008 1 次提交
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f569afd
  24. 08 2月, 2008 1 次提交
  25. 21 9月, 2006 1 次提交
  26. 20 9月, 2006 1 次提交
  27. 18 9月, 2006 1 次提交
  28. 29 6月, 2006 1 次提交
    • R
      [ARM] nommu: adjust headers for !MMU ARM systems · 002547b4
      Russell King 提交于
      Majorily based on Hyok Choi's patches, this fixes up the asm-arm
      header files for mmuless systems.  Over and above Hyok's patches:
      
      - nommu.h merged into mmu.h (it's only a structure)
      - nommu_context.h is essentially the same as mmu_context.h, but
        without the MM switching code.
      
      so there's no point having separate files.  Also, in memory.h,
      there's no point #ifndef'ing PHYS_OFFSET and END_MEM - both
      CONFIG_DRAM_BASE and CONFIG_DRAM_SIZE will always be set by the
      configuration scripts.
      
      Other files have minor formatting changes, but are essentially
      the same.  Hyok's original patches were signed off thusly:
      Signed-off-by: NHyok S. Choi <hyok.choi@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      002547b4
  29. 26 4月, 2006 1 次提交
  30. 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
  31. 15 1月, 2006 1 次提交
    • N
      [ARM] 3101/1: ARM EABI: slab memory must be 64-bit aligned · da2b1cd6
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      Although ARM is still using 32-bit pointers, version 5 and later
      versions of the ARM architecture introduced the ldrd and strd
      instructions to move 64-bit data which must be 64-bit aligned in memory,
      and the EABI includes new constraints on structure data alignment to
      allow for the compiler to use those instructions. This means that any
      slab allocation must start on a 64-bit boundary which is not equivalent
      to BYTES_PER_WORD, especially on those architecture versions that
      implements the ldrd/strd instructions.
      
      Overriding the default alignment disables some slab debug features. If
      those debug features are really needed then the kernel will have to be
      compiled for version 4 of the ARM architecture.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      da2b1cd6
  32. 05 9月, 2005 1 次提交
  33. 10 5月, 2005 2 次提交
  34. 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