1. 09 5月, 2007 1 次提交
  2. 03 5月, 2007 1 次提交
    • M
      MSI: arch must connect the irq and the msi_desc · 7fe3730d
      Michael Ellerman 提交于
      set_irq_msi() currently connects an irq_desc to an msi_desc. The archs call
      it at some point in their setup routine, and then the generic code sets up the
      reverse mapping from the msi_desc back to the irq.
      
      set_irq_msi() should do both connections, making it the one and only call
      required to connect an irq with it's MSI desc and vice versa.
      
      The arch code MUST call set_irq_msi(), and it must do so only once it's sure
      it's not going to fail the irq allocation.
      
      Given that there's no need for the arch to return the irq anymore, the return
      value from the arch setup routine just becomes 0 for success and anything else
      for failure.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7fe3730d
  3. 27 4月, 2007 1 次提交
  4. 26 4月, 2007 12 次提交
  5. 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
  6. 10 12月, 2006 1 次提交
  7. 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
  8. 24 6月, 2006 3 次提交
  9. 20 6月, 2006 2 次提交
    • D
      [SPARC64]: Move over to GENERIC_HARDIRQS. · e18e2a00
      David S. Miller 提交于
      This is the long overdue conversion of sparc64 over to
      the generic IRQ layer.
      
      The kernel image is slightly larger, but the BSS is ~60K
      smaller due to the reduced size of struct ino_bucket.
      
      A lot of IRQ implementation details, including ino_bucket,
      were moved out of asm-sparc64/irq.h and are now private to
      arch/sparc64/kernel/irq.c, and most of the code in irq.c
      totally disappeared.
      
      One thing that's different at the moment is IRQ distribution,
      we do it at enable_irq() time.  If the cpu mask is ALL then
      we round-robin using a global rotating cpu counter, else
      we pick the first cpu in the mask to support single cpu
      targetting.  This is similar to what powerpc's XICS IRQ
      support code does.
      
      This works fine on my UP SB1000, and the SMP build goes
      fine and runs on that machine, but lots of testing on
      different setups is needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18e2a00
    • D
      [SPARC64]: Kill ino_bucket->pil · 37cdcd9e
      David S. Miller 提交于
      And reuse that struct member for virt_irq, which will
      be used in future changesets for the implementation of
      mapping between real and virtual IRQ numbers.
      
      This nicely kills off a ton of SBUS and PCI controller
      PIL assignment code which is no longer necessary.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37cdcd9e
  10. 10 6月, 2006 1 次提交
    • D
      [SPARC64]: Avoid JBUS errors on some Niagara systems. · 46b30493
      David S. Miller 提交于
      Doing PCI config space accesses to non-present PCI slots
      can result in fatal JBUS errors if the PCI config access
      hypervisor call is performed on cpus other than the boot
      cpu.
      
      PCI config space accesses to present PCI slots works just
      fine.
      
      Recursively traverse the OBP device tree under the PCI
      controller node and record all present device IDs into
      a small hash table.
      
      Avoid the hypervisor call for any PCI config space access
      attempt for a device not recorded in the hash table.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46b30493
  11. 23 5月, 2006 1 次提交
    • D
      [SPARC64]: Respect gfp_t argument to dma_alloc_coherent(). · 42f14237
      David S. Miller 提交于
      Using asm-generic/dma-mapping.h does not work because pushing
      the call down to pci_alloc_coherent() causes the gfp_t argument
      of dma_alloc_coherent() to be ignored.
      
      Fix this by implementing things directly, and adding a gfp_t
      argument we can use in the internal call down to the PCI DMA
      implementation of pci_alloc_coherent().
      
      This fixes massive memory corruption when using the sound driver
      layer, which passes things like __GFP_COMP down into these
      routines and (correctly) expects that to work.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42f14237
  12. 11 4月, 2006 1 次提交
  13. 20 3月, 2006 14 次提交