1. 24 1月, 2007 1 次提交
  2. 08 12月, 2006 1 次提交
    • B
      [POWERPC] Fix mmap of PCI resource with hack for X · 396a1a58
      Benjamin Herrenschmidt 提交于
      The powerpc version of pci_resource_to_user() and associated hooks
      used by /proc/bus/pci and /sys/bus/pci mmap have been broken for some
      time on machines that don't have a 1:1 mapping of devices (basically
      on non-PowerMacs) and have PCI devices above 32 bits.
      
      This attempts to fix it as well as possible.
      
      The rule is supposed to be that pci_resource_to_user() always converts
      the resources back into a BAR values since that's what the /proc
      interface was supposed to deal with. However, for X to work on
      platforms where PCI MMIO is not mapped 1:1, it became a habit of
      platforms like powerpc to pass "fixed up" values there since X expects
      to be able to use values from /proc/bus/pci/devices as offsets to mmap
      of /dev/mem...
      
      So we keep that contraption here, causing also /sys/*/resource to
      expose fully absolute MMIO addresses instead of BAR values, which is
      ugly, but should still work as long as those are only used to calculate
      alignment within a page.
      
      X is still broken when built 32 bits on machines where PCI MMIO can be
      above 32-bit space unfortunately.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      396a1a58
  3. 04 12月, 2006 1 次提交
  4. 04 10月, 2006 1 次提交
  5. 15 6月, 2006 1 次提交
  6. 24 5月, 2006 3 次提交
  7. 12 1月, 2006 1 次提交
  8. 10 1月, 2006 2 次提交
  9. 09 1月, 2006 6 次提交
  10. 19 11月, 2005 1 次提交
  11. 16 11月, 2005 1 次提交
    • B
      [PATCH] powerpc: pci_64 fixes & cleanups · b5166cc2
      Benjamin Herrenschmidt 提交于
      I discovered that in some cases (PowerMac for example) we wouldn't
      properly map the PCI IO space on recent kernels. In addition, the code
      for initializing PCI host bridges was scattered all over the place with
      some duplication between platforms.
      
      This patch fixes the problem and does a small cleanup by creating a
      pcibios_alloc_controller() in pci_64.c that is similar to the one in
      pci_32.c (just takes an additional device node argument) that takes care
      of all the grunt allocation and initialisation work. It should work for
      both boot time and dynamically allocated PHBs.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b5166cc2
  12. 10 11月, 2005 1 次提交
  13. 22 10月, 2005 1 次提交
  14. 20 10月, 2005 1 次提交
    • P
      powerpc/ppc/ppc64: Various compile fixes. · 17a6392d
      Paul Mackerras 提交于
      This declares powersave_nap in system.h and makes it an int everywhere,
      fixes typos for the maple platform, fixes a couple of places where
      I missed removing the last two arguments from a message_pass function,
      and makes ppc64 consistent with ppc32 in the type of the
      pci_bridge.cfg_data field.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      17a6392d
  15. 14 10月, 2005 3 次提交
  16. 10 10月, 2005 2 次提交
  17. 28 9月, 2005 1 次提交
  18. 12 9月, 2005 1 次提交
    • P
      ppc64: Set up PCI tree from Open Firmware device tree · 4267292b
      Paul Mackerras 提交于
      This adds code which gives us the option on ppc64 of instantiating the
      PCI tree (the tree of pci_bus and pci_dev structs) from the Open
      Firmware device tree rather than by probing PCI configuration space.
      The OF device tree has a node for each PCI device and bridge in the
      system, with properties that tell us what addresses the firmware has
      configured for them and other details.
      
      There are a couple of reasons why this is needed.  First, on systems
      with a hypervisor, there is a PCI-PCI bridge per slot under the PCI
      host bridges.  These PCI-PCI bridges have special isolation features
      for virtualization.  We can't write to their config space, and we are
      not supposed to be reading their config space either.  The firmware
      tells us about the address ranges that they pass in the OF device
      tree.
      
      Secondly, on powermacs, the interrupt controller is in a PCI device
      that may be behind a PCI-PCI bridge.  If we happened to take an
      interrupt just at the point when the device or a bridge on the path to
      it was disabled for probing, we would crash when we try to access the
      interrupt controller.
      
      I have implemented a platform-specific function which is called for
      each PCI bridge (host or PCI-PCI) to say whether the code should look
      in the device tree or use normal PCI probing for the devices under
      that bridge.  On pSeries machines we use the device tree if we're
      running under a hypervisor, otherwise we use normal probing.  On
      powermacs we use normal probing for the AGP bridge, since the device
      for the AGP bridge itself isn't shown in the device tree (at least on
      my G5), and the device tree for everything else.
      
      This has been tested on a dual G5 powermac, a partition on a POWER5
      machine (running under the hypervisor), and a legacy iSeries
      partition.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4267292b
  19. 09 9月, 2005 1 次提交
    • P
      [PATCH] Separate pci bits out of struct device_node · 1635317f
      Paul Mackerras 提交于
      This patch pulls the PCI-related junk out of struct device_node and
      puts it in a separate structure, struct pci_dn.  The device_node now
      just has a void * pointer in it, which points to a struct pci_dn for
      nodes that represent PCI devices.  It could potentially be used in
      future for device-specific data for other sorts of devices, such as
      virtual I/O devices.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1635317f
  20. 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