1. 06 5月, 2013 1 次提交
    • B
      powerpc/pci: Support per-aperture memory offset · 3fd47f06
      Benjamin Herrenschmidt 提交于
      The PCI core supports an offset per aperture nowadays but our arch
      code still has a single offset per host bridge representing the
      difference betwen CPU memory addresses and PCI MMIO addresses.
      
      This is a problem as new machines and hypervisor versions are
      coming out where the 64-bit windows will have a different offset
      (basically mapped 1:1) from the 32-bit windows.
      
      This fixes it by using separate offsets. In the long run, we probably
      want to get rid of that intermediary struct pci_controller and have
      those directly stored into the pci_host_bridge as they are parsed
      but this will be a more invasive change.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      3fd47f06
  2. 04 1月, 2013 1 次提交
    • G
      POWERPC: drivers: remove __dev* attributes. · cad5cef6
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cad5cef6
  3. 24 2月, 2012 1 次提交
  4. 30 9月, 2011 1 次提交
  5. 12 7月, 2011 1 次提交
  6. 10 6月, 2011 1 次提交
  7. 08 6月, 2011 1 次提交
    • B
      pci/of: Match PCI devices to OF nodes dynamically · 98d9f30c
      Benjamin Herrenschmidt 提交于
      powerpc has two different ways of matching PCI devices to their
      corresponding OF node (if any) for historical reasons. The ppc64 one
      does a scan looking for matching bus/dev/fn, while the ppc32 one does a
      scan looking only for matching dev/fn on each level in order to be
      agnostic to busses being renumbered (which Linux does on some
      platforms).
      
      This removes both and instead moves the matching code to the PCI core
      itself. It's the most logical place to do it: when a pci_dev is created,
      we know the parent and thus can do a single level scan for the matching
      device_node (if any).
      
      The benefit is that all archs now get the matching for free. There's one
      hook the arch might want to provide to match a PHB bus to its device
      node. A default weak implementation is provided that looks for the
      parent device device node, but it's not entirely reliable on powerpc for
      various reasons so powerpc provides its own.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NMichal Simek <monstr@monstr.eu>
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      98d9f30c
  8. 31 3月, 2011 1 次提交
  9. 29 3月, 2011 1 次提交
  10. 24 8月, 2010 1 次提交
  11. 04 12月, 2009 1 次提交
  12. 02 9月, 2009 1 次提交
    • B
      powerpc: Fix some late PowerMac G5 with PCIe ATI graphics · cede3930
      Benjamin Herrenschmidt 提交于
      A misconfiguration by the firmware of the U4 PCIe bridge on PowerMac G5
      with the U4 bridge (latest generations, may also affect the iMac G5
      "iSight") is causing us to re-assign the PCI BARs of the video card,
      which can get it out of sync with the firmware, thus breaking offb.
      
      This works around it by fixing up the bridge configuration properly
      at boot time. It also fixes a bug where the firmware provides us with
      an incorrect set of accessible regions in the device-tree.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      cede3930
  13. 08 1月, 2009 1 次提交
  14. 16 12月, 2008 1 次提交
  15. 18 4月, 2008 1 次提交
  16. 20 12月, 2007 7 次提交
  17. 11 12月, 2007 1 次提交
  18. 10 12月, 2007 1 次提交
  19. 17 8月, 2007 2 次提交
  20. 29 6月, 2007 2 次提交
  21. 14 6月, 2007 1 次提交
    • B
      [POWERPC] Rewrite IO allocation & mapping on powerpc64 · 3d5134ee
      Benjamin Herrenschmidt 提交于
      This rewrites pretty much from scratch the handling of MMIO and PIO
      space allocations on powerpc64.  The main goals are:
      
       - Get rid of imalloc and use more common code where possible
       - Simplify the current mess so that PIO space is allocated and
         mapped in a single place for PCI bridges
       - Handle allocation constraints of PIO for all bridges including
         hot plugged ones within the 2GB space reserved for IO ports,
         so that devices on hotplugged busses will now work with drivers
         that assume IO ports fit in an int.
       - Cleanup and separate tracking of the ISA space in the reserved
         low 64K of IO space. No ISA -> Nothing mapped there.
      
      I booted a cell blade with IDE on PIO and MMIO and a dual G5 so
      far, that's it :-)
      
      With this patch, all allocations are done using the code in
      mm/vmalloc.c, though we use the low level __get_vm_area with
      explicit start/stop constraints in order to manage separate
      areas for vmalloc/vmap, ioremap, and PCI IOs.
      
      This greatly simplifies a lot of things, as you can see in the
      diffstat of that patch :-)
      
      A new pair of functions pcibios_map/unmap_io_space() now replace
      all of the previous code that used to manipulate PCI IOs space.
      The allocation is done at mapping time, which is now called from
      scan_phb's, just before the devices are probed (instead of after,
      which is by itself a bug fix). The only other caller is the PCI
      hotplug code for hot adding PCI-PCI bridges (slots).
      
      imalloc is gone, as is the "sub-allocation" thing, but I do beleive
      that hotplug should still work in the sense that the space allocation
      is always done by the PHB, but if you unmap a child bus of this PHB
      (which seems to be possible), then the code should properly tear
      down all the HPTE mappings for that area of the PHB allocated IO space.
      
      I now always reserve the first 64K of IO space for the bridge with
      the ISA bus on it. I have moved the code for tracking ISA in a separate
      file which should also make it smarter if we ever are capable of
      hot unplugging or re-plugging an ISA bridge.
      
      This should have a side effect on platforms like powermac where VGA IOs
      will no longer work. This is done on purpose though as they would have
      worked semi-randomly before. The idea at this point is to isolate drivers
      that might need to access those and fix them by providing a proper
      function to obtain an offset to the legacy IOs of a given bus.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3d5134ee
  22. 07 5月, 2007 1 次提交
  23. 24 4月, 2007 1 次提交
  24. 13 4月, 2007 2 次提交
  25. 08 3月, 2007 1 次提交
  26. 04 12月, 2006 1 次提交
    • B
      [POWERPC] Make pci_read_irq_line the default · f90bb153
      Benjamin Herrenschmidt 提交于
      This patch reworks the way IRQs are fixed up on PCI for arch powerpc.
      
      It makes pci_read_irq_line() called by default in the PCI code for
      devices that are probed, and add an optional per-device fixup in
      ppc_md for platforms that really need to correct what they obtain
      from pci_read_irq_line().
      
      It also removes ppc_md.irq_bus_setup which was only used by pSeries
      and should not be needed anymore.
      
      I've also removed the pSeries s7a workaround as it can't work with
      the current interrupt code anyway. I'm trying to get one of these
      machines working so I can test a proper fix for that problem.
      
      I also haven't updated the old-style fixup code from 85xx_cds.c
      because it's actually buggy :) It assigns pci_dev->irq hard coded
      numbers which is no good with the new IRQ mapping code. It should
      at least use irq_create_mapping(NULL, hard_coded_number); and possibly
      also set_irq_type() to set them as level low.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f90bb153
  27. 02 12月, 2006 1 次提交
  28. 31 7月, 2006 1 次提交
  29. 11 7月, 2006 1 次提交
    • B
      [PATCH] powerpc: fix trigger handling in the new irq code · 6e99e458
      Benjamin Herrenschmidt 提交于
      This patch slightly reworks the new irq code to fix a small design error.  I
      removed the passing of the trigger to the map() calls entirely, it was not a
      good idea to have one call do two different things.  It also fixes a couple of
      corner cases.
      
      Mapping a linux virtual irq to a physical irq now does only that.  Setting the
      trigger is a different action which has a different call.
      
      The main changes are:
      
      - I no longer call host->ops->map() for an already mapped irq, I just return
        the virtual number that was already mapped.  It was called before to give an
        opportunity to change the trigger, but that was causing issues as that could
        happen while the interrupt was in use by a device, and because of the
        trigger change, map would potentially muck around with things in a racy way.
         That was causing much burden on a given's controller implementation of
        map() to get it right.  This is much simpler now.  map() is only called on
        the initial mapping of an irq, meaning that you know that this irq is _not_
        being used.  You can initialize the hardware if you want (though you don't
        have to).
      
      - Controllers that can handle different type of triggers (level/edge/etc...)
        now implement the standard irq_chip->set_type() call as defined by the
        generic code.  That means that you can use the standard set_irq_type() to
        configure an irq line manually if you wish or (though I don't like that
        interface), pass explicit trigger flags to request_irq() as defined by the
        generic kernel interfaces.  Also, using those interfaces guarantees that
        your controller set_type callback is called with the descriptor lock held,
        thus providing locking against activity on the same interrupt (including
        mask/unmask/etc...) automatically.  A result is that, for example, MPIC's
        own map() implementation calls irq_set_type(NONE) to configure the hardware
        to the default triggers.
      
      - To allow the above, the irq_map array entry for the new mapped interrupt
        is now set before map() callback is called for the controller.
      
      - The irq_create_of_mapping() (also used by irq_of_parse_and_map()) function
        for mapping interrupts from the device-tree now also call the separate
        set_irq_type(), and only does so if there is a change in the trigger type.
      
      - While I was at it, I changed pci_read_irq_line() (which is the helper I
        would expect most archs to use in their pcibios_fixup() to get the PCI
        interrupt routing from the device tree) to also handle a fallback when the
        DT mapping fails consisting of reading the PCI_INTERRUPT_PIN to know wether
        the device has an interrupt at all, and the the PCI_INTERRUPT_LINE to get an
        interrupt number from the device.  That number is then mapped using the
        default controller, and the trigger is set to level low.  That default
        behaviour works for several platforms that don't have a proper interrupt
        tree like Pegasos.  If it doesn't work for your platform, then either
        provide a proper interrupt tree from the firmware so that fallback isn't
        needed, or don't call pci_read_irq_line()
      
      - Add back a bit that got dropped by my main rework patch for properly
        clearing pending IPIs on pSeries when using a kexec
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e99e458
  30. 03 7月, 2006 1 次提交
    • B
      [POWERPC] Add new interrupt mapping core and change platforms to use it · 0ebfff14
      Benjamin Herrenschmidt 提交于
      This adds the new irq remapper core and removes the old one.  Because
      there are some fundamental conflicts with the old code, like the value
      of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
      etc..., this commit also changes the relevant platform and driver code
      over to use the new remapper (so as not to cause difficulties later
      in bisecting).
      
      This patch removes the old pre-parsing of the open firmware interrupt
      tree along with all the bogus assumptions it made to try to renumber
      interrupts according to the platform. This is all to be handled by the
      new code now.
      
      For the pSeries XICS interrupt controller, a single remapper host is
      created for the whole machine regardless of how many interrupt
      presentation and source controllers are found, and it's set to match
      any device node that isn't a 8259.  That works fine on pSeries and
      avoids having to deal with some of the complexities of split source
      controllers vs. presentation controllers in the pSeries device trees.
      
      The powerpc i8259 PIC driver now always requests the legacy interrupt
      range. It also has the feature of being able to match any device node
      (including NULL) if passed no device node as an input. That will help
      porting over platforms with broken device-trees like Pegasos who don't
      have a proper interrupt tree.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0ebfff14
  31. 28 6月, 2006 1 次提交