1. 26 4月, 2007 7 次提交
  2. 11 2月, 2007 1 次提交
    • D
      [SPARC64]: Add PCI MSI support on Niagara. · 35a17eb6
      David S. Miller 提交于
      This is kind of hokey, we could use the hardware provided facilities
      much better.
      
      MSIs are assosciated with MSI Queues.  MSI Queues generate interrupts
      when any MSI assosciated with it is signalled.  This suggests a
      two-tiered IRQ dispatch scheme:
      
      	MSI Queue interrupt --> queue interrupt handler
      		MSI dispatch --> driver interrupt handler
      
      But we just get one-level under Linux currently.  What I'd like to do
      is possibly stick the IRQ actions into a per-MSI-Queue data structure,
      and dispatch them form there, but the generic IRQ layer doesn't
      provide a way to do that right now.
      
      So, the current kludge is to "ACK" the interrupt by processing the
      MSI Queue data structures and ACK'ing them, then we run the actual
      handler like normal.
      
      We are wasting a lot of useful information, for example the MSI data
      and address are provided with ever MSI, as well as a system tick if
      available.  If we could pass this into the IRQ handler it could help
      with certain things, in particular for PCI-Express error messages.
      
      The MSI entries on sparc64 also tell you exactly which bus/device/fn
      sent the MSI, which would be great for error handling when no
      registered IRQ handler can service the interrupt.
      
      We override the disable/enable IRQ chip methods in sun4v_msi, so we
      have to call {mask,unmask}_msi_irq() directly from there.  This is
      another ugly wart.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35a17eb6
  3. 30 6月, 2006 2 次提交
    • 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
    • D
      [SPARC64]: Kill starfire_cookie from SBUS/PCI. · 286bbe87
      David S. Miller 提交于
      Totally unused.
      
      We need to traverse the list of global IRQ translaters,
      so storing it in the per-bus structures was useless.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      286bbe87
  4. 24 6月, 2006 2 次提交
  5. 20 3月, 2006 1 次提交
  6. 14 10月, 2005 2 次提交
  7. 05 7月, 2005 1 次提交
    • D
      [SPARC64]: Do proper DMA IRQ syncing on Tomatillo · bb6743f4
      David S. Miller 提交于
      This was the main impetus behind adding the PCI IRQ shim.
      
      In order to properly order DMA writes wrt. interrupts, you have to
      write to a PCI controller register, then poll for that bit clearing.
      There is one bit for each interrupt source, and setting this register
      bit tells Tomatillo to drain all pending DMA from that device.
      
      Furthermore, Tomatillo's with revision less than 4 require us to do a
      block store due to some memory transaction ordering issues it has on
      JBUS.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb6743f4
  8. 01 6月, 2005 1 次提交
  9. 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