1. 03 Jul, 2006 1 commit
  2. 01 Jul, 2006 1 commit
  3. 29 Jun, 2006 1 commit
    • Russell King's avatar
      [ARM] Add section support to ioremap · ff0daca5
      Russell King authored
      
      
      Allow section mappings to be setup using ioremap() and torn down
      with iounmap().  This requires additional support in the MM
      context switch to ensure that mappings are properly synchronised
      when mapped in.
      
      Based an original implementation by Deepak Saxena, reworked and
      ARMv6 support added by rmk.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ff0daca5
  4. 28 Jun, 2006 1 commit
  5. 16 May, 2006 1 commit
  6. 21 Mar, 2006 1 commit
  7. 20 Jan, 2006 1 commit
  8. 09 Jan, 2006 1 commit
    • Deepak Saxena's avatar
      [ARM] 3070/2: Add __ioremap_pfn() API · 9d4ae727
      Deepak Saxena authored
      
      
      Patch from Deepak Saxena
      
      In working on adding 36-bit addressed supersection support to ioremap(),
      I came to the conclusion that it would be far simpler to do so by just
      splitting __ioremap() into a main external interface and adding an
      __ioremap_pfn() function that takes a pfn + offset into the page that
      __ioremap() can call. This way existing callers of __ioremap() won't have
      to change their code and 36-bit systems will just call __ioremap_pfn()
      and we will not have to deal with unsigned long long variables.
      
      Note that __ioremap_pfn() should _NOT_ be called directly by drivers
      but is reserved for use by arch_ioremap() implementations that map
      32-bit resource regions into the real 36-bit address and then call
      this new function.
      Signed-off-by: default avatarDeepak Saxena <dsaxena@plexity.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      9d4ae727
  9. 17 Nov, 2005 1 commit
  10. 29 Oct, 2005 1 commit
    • Hugh Dickins's avatar
      [PATCH] mm: init_mm without ptlock · 872fec16
      Hugh Dickins authored
      
      
      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: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      872fec16
  11. 28 Oct, 2005 1 commit
  12. 20 Jun, 2005 1 commit
  13. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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