1. 13 2月, 2007 1 次提交
  2. 09 12月, 2006 1 次提交
  3. 06 12月, 2006 1 次提交
    • P
      sh: Preliminary support for SH-X2 MMU. · 21440cf0
      Paul Mundt 提交于
      This adds some preliminary support for the SH-X2 MMU, used by
      newer SH-4A parts (particularly SH7785).
      
      This MMU implements a 'compat' mode with SH-X MMUs and an
      'extended' mode for SH-X2 extended features. Extended features
      include additional page sizes (8kB, 4MB, 64MB), as well as the
      addition of page execute permissions.
      
      The extended mode attributes are placed in a second data array,
      which requires us to switch to 64-bit PTEs when in X2 mode.
      
      With the addition of the exec perms, we also overhaul the mmap
      prots somewhat, now that it's possible to handle them more
      intelligently.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      21440cf0
  4. 27 9月, 2006 1 次提交
  5. 17 1月, 2006 1 次提交
    • P
      [PATCH] sh: I/O routine cleanups and ioremap() overhaul · b66c1a39
      Paul Mundt 提交于
      This introduces a few changes in the way that the I/O routines are defined on
      SH, specifically so that things like the iomap API properly wrap through the
      machvec for board-specific quirks.
      
      In addition to this, the old p3_ioremap() work is converted to a more generic
      __ioremap() that will map through the PMB if it's available, or fall back on
      page tables for everything else.
      
      An alpha-like IO_CONCAT is also added so we can start to clean up the
      board-specific io.h mess, which will be handled in board update patches..
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b66c1a39
  6. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: init_mm without ptlock · 872fec16
      Hugh Dickins 提交于
      First step in pushing down the page_table_lock.  init_mm.page_table_lock has
      been used throughout the architectures (usually for ioremap): not to serialize
      kernel address space allocation (that's usually vmlist_lock), but because
      pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it.
      
      Reverse that: don't lock or unlock init_mm.page_table_lock in any of the
      architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take
      and drop it when allocating a new one, to check lest a racing task already
      did.  Similarly no page_table_lock in vmalloc's map_vm_area.
      
      Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle
      user mms, which are converted only by a later patch, for now they have to lock
      differently according to whether or not it's init_mm.
      
      If sources get muddled, there's a danger that an arch source taking
      init_mm.page_table_lock will be mixed with common source also taking it (or
      neither take it).  So break the rules and make another change, which should
      break the build for such a mismatch: remove the redundant mm arg from
      pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13).
      
      Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64
      used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to
      pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64
      map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free
      took page_table_lock for no good reason.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      872fec16
  7. 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