1. 12 5月, 2011 2 次提交
  2. 18 2月, 2011 1 次提交
  3. 16 7月, 2010 2 次提交
  4. 30 11月, 2008 1 次提交
  5. 28 11月, 2008 1 次提交
    • N
      [ARM] remove a common set of __virt_to_bus definitions · b5ee9002
      Nicolas Pitre 提交于
      Let's provide an overridable default instead of having every machine
      class define __virt_to_bus and __bus_to_virt to the same thing.  What
      most platforms are using is bus_addr == phys_addr so such is the default.
      
      One exception is ebsa110 which has no DMA what so ever, so the actual
      definition is not important except only for proper compilation.  Also
      added a comment about the special footbridge bus translation.
      
      Let's also remove comments alluding to set_dma_addr which is not
      (and should not) be commonly used.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b5ee9002
  6. 07 10月, 2008 1 次提交
  7. 07 8月, 2008 1 次提交
  8. 16 10月, 2007 1 次提交
  9. 01 12月, 2006 1 次提交
    • R
      [ARM] Clean up discontigmem support · b7dc96d7
      Russell King 提交于
      Most architectures have fairly simple discontiguous memory - a
      simple set of successive regions each containing some memory.
      These can be described simply as a log2 of their maximum size,
      along with the base address of the first region and the number
      of regions.
      
      The base address is already described by PHYS_PFN_OFFSET, and
      the number of regions via the MAX_NUMNODES and the number of
      online nodes.
      
      If we then supply the log2 of their maximum size, all the other
      discontigmem macros can move into generic code.
      
      There is one exception: lh7a40x seems to have a more complicated
      setup; this is left alone.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b7dc96d7
  10. 30 10月, 2005 1 次提交
  11. 15 9月, 2005 1 次提交
  12. 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