1. 29 11月, 2008 1 次提交
  2. 07 8月, 2008 2 次提交
  3. 04 2月, 2008 1 次提交
  4. 26 1月, 2008 1 次提交
  5. 20 10月, 2007 1 次提交
  6. 06 5月, 2007 1 次提交
    • R
      [ARM] mm 10: allow memory type to be specified with ioremap · 3603ab2b
      Russell King 提交于
      __ioremap() took a set of page table flags (specifically the cacheable
      and bufferable bits) to control the mapping type.  However, with
      the advent of ARMv6, this is far too limited.
      
      Replace the page table flags with a memory type index, so that the
      desired attributes can be selected from the mem_type table.
      
      Finally, to prevent silent miscompilation due to the differing
      arguments, rename the __ioremap() and __ioremap_pfn() functions.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3603ab2b
  7. 22 4月, 2007 1 次提交
  8. 30 3月, 2007 1 次提交
  9. 10 2月, 2007 1 次提交
  10. 01 7月, 2006 1 次提交
  11. 30 4月, 2006 1 次提交
  12. 18 11月, 2005 1 次提交
  13. 02 11月, 2005 1 次提交
  14. 31 10月, 2005 1 次提交
  15. 01 9月, 2005 1 次提交
  16. 07 7月, 2005 1 次提交
    • D
      [PATCH] ARM: 2792/1: IXP4xx iomap API implementation · 450008b5
      Deepak Saxena 提交于
      Patch from Deepak Saxena
      
      This patch implements the iomap API for Intel IXP4xx NPU systems.
      We need to implement our own version of the API functions b/c of the
      PCI hostbridge does not provide the capability to map PCI I/O space
      into the CPU's physical memory space. In addition, if a system has
      more than 64M of PCI memory mapped BARs, PCI memory must also be
      accessed indirectly.  This patch changes the assignment of PCI I/O
      resources to fall into to 0x0000:0xffff range so that we can trap
      I/O areas in our ioread/iowrite macros.
      
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      450008b5
  17. 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