1. 04 10月, 2007 1 次提交
    • D
      [SPARC64]: Temporary workaround for PCI-E slot on T1000. · 27097ef9
      David S. Miller 提交于
      The PCI-E slot on T1000 connects directly to the Fire PCI chip with no
      intervening bridges visible in the OBP tree.
      
      Unfortunately the bus numbering of the device in that slot is
      different (2) from the PCI host controller (0), and thus the
      pci_bus_{read,write}_config_*() calls don't work out.
      
      Complicating things further the Fire PCI controller has no config
      space it responds to either.
      
      For now treat this case specially so that devices in the slot work.
      
      Longer term we need to perhaps cons up a dummy bridge between the Fire
      and the PCI-E slot so that the bus hierarchy is complete inside of the
      kernel and thus the bus numbering all works out right.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27097ef9
  2. 30 7月, 2007 1 次提交
  3. 13 6月, 2007 1 次提交
  4. 09 5月, 2007 4 次提交
  5. 26 4月, 2007 4 次提交
  6. 11 2月, 2007 1 次提交
  7. 18 10月, 2006 1 次提交
    • D
      [SPARC64]: Fix PCI memory space root resource on Hummingbird. · 5aee87c4
      David S. Miller 提交于
      For Hummingbird PCI controllers, we should create the root
      PCI memory space resource as the full 4GB area, and then
      allocate the IOMMU DMA translation window out of there.
      
      The old code just assumed that the IOMMU DMA translation base
      to the top of the 4GB area was unusable.  This is not true on
      many systems such as SB100 and SB150, where the IOMMU DMA
      translation window sits at 0xc0000000->0xdfffffff.
      
      So what would happen is that any device mapped by the firmware
      at the top section 0xe0000000->0xffffffff would get remapped
      by Linux somewhere else leading to all kinds of problems and
      boot failures.
      
      While we're here, report more cases of OBP resource assignment
      conflicts.  The only truly valid ones are ROM resource conflicts.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5aee87c4
  8. 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
  9. 24 6月, 2006 3 次提交
  10. 20 3月, 2006 6 次提交
  11. 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