1. 30 7月, 2007 1 次提交
  2. 12 7月, 2007 1 次提交
  3. 08 6月, 2007 1 次提交
    • D
      [SPARC64]: Handle PCI bridges without 'ranges' property. · 8c2786cf
      David S. Miller 提交于
      This fixes the IDE controller not showing up on Netra-T1
      systems.
      
      Just like Simba bridges, some PCI bridges can lack the
      'ranges' OBP property.  So we handle this similarly to
      the existing Simba code:
      
      1) In of_device register address resolving, we push the
         translation to the parent.
      
      2) In PCI device scanning, we interrogate the PCI config
         space registers of the PCI bus device in order to resolve
         the resources, just like the generic Linux PCI probing
         code does.
      
      With much help and testing from Fabio, who also reported
      the initial problem.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NFabio Massimo Di Nitto <fabbione@ubuntu.com>
      8c2786cf
  4. 29 5月, 2007 1 次提交
  5. 12 5月, 2007 1 次提交
  6. 10 5月, 2007 1 次提交
  7. 09 5月, 2007 7 次提交
  8. 07 5月, 2007 2 次提交
    • D
      [SPARC64]: Fix section mismatch warnings in arch/sparc64/kernel/pci.c · a6009dda
      David S. Miller 提交于
      apb_calc_first_last(), apb_fake_ranges(), pci_of_scan_bus(),
      of_scan_pci_bridge(), pci_of_scan_bus(), and pci_scan_one_pbm()
      should all be __devinit.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6009dda
    • D
      [SPARC64]: SUN4U PCI-E controller support. · 861fe906
      David S. Miller 提交于
      Some minor refactoring in the generic code was necessary for
      this:
      
      1) This controller requires 8-byte access to the interrupt map
         and clear register.  They are 64-bits on all the other
         SBUS and PCI controllers anyways, so this was easy to cure.
      
      2) The IMAP register has a different layout and some bits that we
         need to preserve, so use a read/modify/write when making
         changes to the IMAP register in generic code.
      
      3) Flushing the entire IOMMU TLB is best done with a single write
         to a register on this PCI controller, add a iommu->iommu_flushinv
         for this.
      
      Still lacks MSI support, that will come later.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      861fe906
  9. 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
  10. 26 4月, 2007 10 次提交
  11. 13 4月, 2007 1 次提交
  12. 03 3月, 2007 1 次提交
  13. 27 2月, 2007 1 次提交
  14. 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
  15. 02 12月, 2006 1 次提交
  16. 01 7月, 2006 1 次提交
  17. 30 6月, 2006 2 次提交
  18. 28 6月, 2006 1 次提交
  19. 24 6月, 2006 2 次提交
  20. 20 6月, 2006 1 次提交
    • 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
  21. 18 4月, 2006 1 次提交
  22. 22 3月, 2006 1 次提交