1. 30 7月, 2007 1 次提交
    • D
      [SPARC64]: Fix conflicts in SBUS/PCI/EBUS/ISA DMA handling. · ad7ad57c
      David S. Miller 提交于
      Fully unify all of the DMA ops so that subordinate bus types to
      the DMA operation providers (such as ebus, isa, of_device) can
      work transparently.
      
      Basically, we just make sure that for every system device we
      create, the dev->archdata 'iommu' and 'stc' fields are filled
      in.
      
      Then we have two platform variants of the DMA ops, one for SUN4U which
      actually programs the real hardware, and one for SUN4V which makes
      hypervisor calls.
      
      This also fixes the crashes in parport_pc on sparc64, reported by
      Meelis Roos.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad7ad57c
  2. 21 7月, 2007 1 次提交
  3. 09 5月, 2007 1 次提交
  4. 26 4月, 2007 2 次提交
  5. 27 10月, 2006 1 次提交
  6. 09 10月, 2006 1 次提交
  7. 03 7月, 2006 1 次提交
  8. 01 7月, 2006 1 次提交
  9. 30 6月, 2006 1 次提交
    • D
      [SPARC64]: of_device layer IRQ resolution · 2b1e5978
      David S. Miller 提交于
      Do IRQ determination generically by parsing the PROM properties,
      and using IRQ controller drivers for final resolution.
      
      One immediate positive effect is that all of the IRQ frobbing
      in the EBUS, ISA, and PCI controller layers has been eliminated.
      We just look up the of_device and use the properly computed
      value.
      
      The PCI controller irq_build() routines are gone and no longer
      used.  Unfortunately sbus_build_irq() has to remain as there is
      a direct reference to this in the sunzilog driver.  That can be
      killed off once the sparc32 side of this is written and the
      sunzilog driver is transformed into an "of" bus driver.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b1e5978
  10. 24 6月, 2006 5 次提交
  11. 20 3月, 2006 1 次提交
  12. 10 1月, 2006 1 次提交
  13. 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