Only MULTIPLATFORM has phbs_remap_io.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>

phbs_remap_io(), which maps the PCI IO space into the kernel virtual space,
is called too early on powermac, and thus doesn't work.

This fixes it by removing the call from all platforms and putting it back
into the ppc64 common code where it belongs, after the actual probing of
the bus.

That means that before that call, only the ISA IO space (if any) is mapped,
any PIO access (from quirks for example) will fail. This happens not to be
a problem for now, but we'll have to rework that code if it becomes one in
the future.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This patch merges platform codes.  systemcfg->platform is no longer used,
systemcfg use in general is deprecated as much as possible (and renamed
_systemcfg before it gets completely moved elsewhere in a future patch),
_machine is now used on ppc64 along as ppc32.  Platform codes aren't gone
yet but we are getting a step closer. A bunch of asm code in head[_64].S
is also turned into C code.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This patch contains the arch/ppc64 bits for enabling DLPAR and PCI
Hotplug for the new OF-based PCI probe mechanism.  This code path is
currently broken.
Signed-off-by: NJohn Rose <johnrose@austin.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Change the phys_mem_access_prot() function to take a pfn instead of an
address.  This allows mmap64() to work on /dev/mem for addresses above 4G
on 32-bit architectures.  We start with a pfn in mmap_mem(), so there's no
need to convert to an address; in fact, it's actively bad, since the
conversion can overflow when the address is above 4G.

Similarly fix the ppc32 page_is_ram() function to avoid a conversion to an
address by directly comparing to max_pfn.  Working with max_pfn instead of
high_memory fixes page_is_ram() to give the right answer for highmem pages.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

... for consistency with ppc32 and to make the powermac merge easier.
Also make it use just a single resource in the host bridge for multiple
consecutive elements of the ranges property.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

and rename it to pci.c.  This also required moving
arch/ppc64/kernel/pci.h into include/asm-powerpc (called
ppc-pci.h.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>

My code to set up the PCI tree from the Open Firmware device tree was
setting IORESOURCE_* flags on the resources for the devices, but not
the PCI_BASE_ADDRESS_* flags.  This meant that some drivers
misbehaved, and /proc/pci showed the wrong types for the resources.
This fixes it.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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>

The pciconfig_iobase, pciconfig_read and pciconfig_write system calls
were only implemented for 32-bit processes; for 64-bit processes they
returned an ENOSYS error.  This allows them to be used by 64-bit
processes as well.  The X server uses pciconfig_iobase at least, and
this change is necessary to allow a 64-bit X server to work on my G5.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

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>

This patch removes CONFIG_PCI_NAMES.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In yenta_socket, we default to using the resource setting of the CardBus
bridge.  However, this is a PCI-bus-centric view of resources and thus needs
to be converted to generic resources first.  Therefore, add a call to
pcibios_bus_to_resource() call in between.  This function is a mere wrapper on
x86 and friends, however on some others it already exists, is added in this
patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where
is its pcibios_resource_to_bus() ?).
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is an updated version of Ben's fix-pci-mmap-on-ppc-and-ppc64.patch
which is in 2.6.12-rc4-mm1.

It fixes the patch to work on PPC iSeries, removes some debug printks
at Ben's request, and incorporates your
fix-pci-mmap-on-ppc-and-ppc64-fix.patch also.

Originally from Benjamin Herrenschmidt <benh@kernel.crashing.org>

This patch was discussed at length on linux-pci and so far, the last
iteration of it didn't raise any comment.  It's effect is a nop on
architecture that don't define the new pci_resource_to_user() callback
anyway.  It allows architecture like ppc who put weird things inside of
PCI resource structures to convert to some different value for user
visible ones.  It also fixes mmap'ing of IO space on those archs.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

For I/O DLPAR to work properly, the kernel needs to allow for dynamic
assignment of the irq field of the pci_dev structure upon dynamic bus
addition.  This patch moves the assignment of that field from
pSeries_final_fixup() to pcibios_fixup_bus(), which enables dynamic
assignment for the children of a newly added bus.

Currently, pci_devs receive their irq numbers in one of two ways.  The
irq line is either read at boot for all pci_devs, or read by the rpaphp
module at slot enable time.  The latter is no longer sufficient for
DLPAR addition of slots that don't qualify as PCI-hotplug capable.
This solution handles the cases of boot and dynamic add.
Signed-off-by: NJohn Rose <johnrose@austin.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Signed-off-by: NYani Ioannou <yani.ioannou@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch started as simply removing a few never-used macros from
asm-ppc64/pgtable.h, then kind of grew.  It now makes a bunch of
cleanups to the ppc64 low-level header files (with corresponding
changes to .c files where necessary) such as:
	- Abolishing never-used macros
	- Eliminating multiple #defines with the same purpose
	- Removing pointless macros (cases where just expanding the
macro everywhere turns out clearer and more sensible)
	- Removing some cases where macros which could be defined in
terms of each other weren't
	- Moving imalloc() related definitions from pgtable.h to their
own header file (imalloc.h)
	- Re-arranging headers to group things more logically
	- Moving all VSID allocation related things to mmu.h, instead
of being split between mmu.h and mmu_context.h
	- Removing some reserved space for flags from the PMD - we're
not using it.
	- Fix some bugs which broke compile with STRICT_MM_TYPECHECKS.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Acked-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch fixes ppc64 __ioremap() so that it stops adding implicitely
_PAGE_GUARDED when the cache is not writeback, and instead, let the callers
provide the flag they want here.  This allows things like framebuffers to
explicitely request a non-cacheable and non-guarded mapping which is more
efficient for that type of memory without side effects.  The patch also
fixes all current callers to add _PAGE_GUARDED except btext, which is fine
without it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!