Skip to content

L
linux-davinci
An error occurred fetching the project authors.
Switch branch/tag
  1. 29 Jun, 2007 1 commit
  3. 14 Jun, 2007 3 commits
    • Benjamin Herrenschmidt's avatar
      [POWERPC] Rewrite IO allocation & mapping on powerpc64 · 3d5134ee
      Benjamin Herrenschmidt authored 
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      3d5134ee
    • Linas Vepstas's avatar
      [POWERPC] Show EEH per-device false positives · 858955bd
      Linas Vepstas authored 
      Track and report the number of times we read an all-1s value (0xff,
0xffff or 0xffffffff) from each device which is valid data, not
indicating EEH isolation.
Signed-off-by: default avatarLinas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/platforms/pseries/eeh.c       |    5 +++++
 arch/powerpc/platforms/pseries/eeh_sysfs.c |    3 +++
 include/asm-powerpc/pci-bridge.h           |    1 +
 3 files changed, 9 insertions(+)
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      858955bd
    • Linas Vepstas's avatar
      [POWERPC] pseries: asm/pci-bridge.h CONFIG_ minor cleanup · c2e221e8
      Linas Vepstas authored 
      Use the correct CONFIG_ option to mark off the EEH bits.
Move the EEH bits to the bottom of the struct.
The config_space array is used by EEH only; it does not
need to be part of the struct for non-pseries machines.
Signed-off-by: default avatarLinas Vepstas <linas@austin.ibm.com>

----
Revised patch, per commments from Michael Ellerman.

 include/asm-powerpc/pci-bridge.h |   16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      c2e221e8
  5. 24 Jan, 2007 1 commit
  7. 08 Dec, 2006 1 commit
    • Benjamin Herrenschmidt's avatar
      [POWERPC] Fix mmap of PCI resource with hack for X · 396a1a58
      Benjamin Herrenschmidt authored 
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      396a1a58
  9. 04 Dec, 2006 1 commit
  11. 04 Oct, 2006 1 commit
  13. 15 Jun, 2006 1 commit
  15. 24 May, 2006 3 commits
  17. 12 Jan, 2006 1 commit
  19. 10 Jan, 2006 2 commits
  21. 09 Jan, 2006 6 commits
  23. 19 Nov, 2005 1 commit
  25. 16 Nov, 2005 1 commit
    • Benjamin Herrenschmidt's avatar
      [PATCH] powerpc: pci_64 fixes & cleanups · b5166cc2
      Benjamin Herrenschmidt authored 
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      b5166cc2
  27. 10 Nov, 2005 1 commit
  29. 22 Oct, 2005 1 commit
  31. 20 Oct, 2005 1 commit
    • Paul Mackerras's avatar
      powerpc/ppc/ppc64: Various compile fixes. · 17a6392d
      Paul Mackerras authored 
      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: default avatarPaul Mackerras <paulus@samba.org>
      17a6392d
  33. 14 Oct, 2005 3 commits
  35. 10 Oct, 2005 2 commits
  37. 28 Sep, 2005 1 commit
  39. 12 Sep, 2005 1 commit
    • Paul Mackerras's avatar
      ppc64: Set up PCI tree from Open Firmware device tree · 4267292b
      Paul Mackerras authored 
      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: default avatarPaul Mackerras <paulus@samba.org>
      4267292b
  41. 09 Sep, 2005 1 commit
    • Paul Mackerras's avatar
      [PATCH] Separate pci bits out of struct device_node · 1635317f
      Paul Mackerras authored 
      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: default avatarPaul Mackerras <paulus@samba.org>
      1635317f
  43. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored 
      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