2005-09-26 14:04:21 +08:00
|
|
|
#
|
|
|
|
|
# Makefile for the linux kernel.
|
|
|
|
|
#
|
|
|
|
|
|
2005-09-30 11:51:25 +08:00
|
|
|
ifeq ($(CONFIG_PPC64),y)
|
|
|
|
|
EXTRA_CFLAGS += -mno-minimal-toc
|
|
|
|
|
endif
|
2005-09-30 14:16:52 +08:00
|
|
|
ifeq ($(CONFIG_PPC32),y)
|
2005-10-06 10:06:20 +08:00
|
|
|
CFLAGS_prom_init.o += -fPIC
|
2005-10-06 11:24:50 +08:00
|
|
|
CFLAGS_btext.o += -fPIC
|
2005-09-30 14:16:52 +08:00
|
|
|
endif
|
2005-10-06 10:06:20 +08:00
|
|
|
|
2005-10-18 12:19:41 +08:00
|
|
|
obj-y := semaphore.o cputable.o ptrace.o syscalls.o \
|
2006-01-12 18:22:34 +08:00
|
|
|
irq.o align.o signal_32.o pmc.o vdso.o \
|
2007-06-04 13:15:49 +08:00
|
|
|
init_task.o process.o systbl.o idle.o \
|
|
|
|
|
signal.o
|
2005-11-11 18:15:21 +08:00
|
|
|
obj-y += vdso32/
|
2005-10-27 18:20:42 +08:00
|
|
|
obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
|
2006-02-10 13:02:20 +08:00
|
|
|
signal_64.o ptrace32.o \
|
2006-08-11 13:03:01 +08:00
|
|
|
paca.o cpu_setup_ppc970.o \
|
2007-02-05 06:36:51 +08:00
|
|
|
cpu_setup_pa6t.o \
|
2006-11-02 20:56:11 +08:00
|
|
|
firmware.o sysfs.o nvram_64.o
|
2005-11-11 18:15:21 +08:00
|
|
|
obj-$(CONFIG_PPC64) += vdso64/
|
2005-10-10 20:50:37 +08:00
|
|
|
obj-$(CONFIG_ALTIVEC) += vecemu.o vector.o
|
2006-04-18 19:49:11 +08:00
|
|
|
obj-$(CONFIG_PPC_970_NAP) += idle_power4.o
|
2006-11-11 14:24:59 +08:00
|
|
|
obj-$(CONFIG_PPC_OF) += of_device.o of_platform.o prom_parse.o
|
2005-11-10 12:26:20 +08:00
|
|
|
procfs-$(CONFIG_PPC64) := proc_ppc64.o
|
|
|
|
|
obj-$(CONFIG_PROC_FS) += $(procfs-y)
|
2007-03-04 14:04:44 +08:00
|
|
|
rtaspci-$(CONFIG_PPC64)-$(CONFIG_PCI) := rtas_pci.o
|
|
|
|
|
obj-$(CONFIG_PPC_RTAS) += rtas.o rtas-rtc.o $(rtaspci-y-y)
|
2005-11-03 11:41:19 +08:00
|
|
|
obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o
|
|
|
|
|
obj-$(CONFIG_RTAS_PROC) += rtas-proc.o
|
2005-11-10 12:26:20 +08:00
|
|
|
obj-$(CONFIG_LPARCFG) += lparcfg.o
|
2005-10-24 12:22:37 +08:00
|
|
|
obj-$(CONFIG_IBMVIO) += vio.o
|
2005-11-16 15:56:43 +08:00
|
|
|
obj-$(CONFIG_IBMEBUS) += ibmebus.o
|
2005-11-04 10:28:58 +08:00
|
|
|
obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
|
2005-12-04 15:39:37 +08:00
|
|
|
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
|
2006-03-27 16:15:26 +08:00
|
|
|
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
|
|
|
|
|
obj-$(CONFIG_TAU) += tau_6xx.o
|
2007-07-30 05:24:36 +08:00
|
|
|
obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
|
|
|
|
|
obj32-$(CONFIG_HIBERNATION) += swsusp_32.o
|
|
|
|
|
obj64-$(CONFIG_HIBERNATION) += swsusp_64.o swsusp_asm64.o
|
2006-03-27 16:28:58 +08:00
|
|
|
obj32-$(CONFIG_MODULES) += module_32.o
|
2005-10-10 20:50:37 +08:00
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_PPC_MERGE),y)
|
|
|
|
|
|
2005-10-10 19:52:43 +08:00
|
|
|
extra-$(CONFIG_PPC_STD_MMU) := head_32.o
|
2005-09-30 14:16:52 +08:00
|
|
|
extra-$(CONFIG_PPC64) := head_64.o
|
2005-09-26 14:04:21 +08:00
|
|
|
extra-$(CONFIG_40x) := head_4xx.o
|
|
|
|
|
extra-$(CONFIG_44x) := head_44x.o
|
|
|
|
|
extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o
|
|
|
|
|
extra-$(CONFIG_8xx) := head_8xx.o
|
|
|
|
|
extra-y += vmlinux.lds
|
|
|
|
|
|
2006-06-28 09:55:49 +08:00
|
|
|
obj-y += time.o prom.o traps.o setup-common.o \
|
2006-09-19 20:17:49 +08:00
|
|
|
udbg.o misc.o io.o
|
2006-02-10 13:02:20 +08:00
|
|
|
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
|
2005-11-14 14:30:17 +08:00
|
|
|
obj-$(CONFIG_PPC64) += misc_64.o dma_64.o iommu.o
|
2006-01-09 18:32:42 +08:00
|
|
|
obj-$(CONFIG_PPC_MULTIPLATFORM) += prom_init.o
|
2005-09-28 18:28:14 +08:00
|
|
|
obj-$(CONFIG_MODULES) += ppc_ksyms.o
|
2005-10-06 10:06:20 +08:00
|
|
|
obj-$(CONFIG_BOOTX_TEXT) += btext.o
|
2005-11-05 07:33:55 +08:00
|
|
|
obj-$(CONFIG_SMP) += smp.o
|
2005-11-14 14:30:17 +08:00
|
|
|
obj-$(CONFIG_KPROBES) += kprobes.o
|
2006-01-10 13:19:05 +08:00
|
|
|
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
|
2006-11-11 14:24:53 +08:00
|
|
|
|
2005-11-14 14:30:17 +08:00
|
|
|
module-$(CONFIG_PPC64) += module_64.o
|
|
|
|
|
obj-$(CONFIG_MODULES) += $(module-y)
|
|
|
|
|
|
[POWERPC] Rewrite IO allocation & mapping on powerpc64
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: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-04 13:15:36 +08:00
|
|
|
pci64-$(CONFIG_PPC64) += pci_64.o pci_dn.o isa-bridge.o
|
2006-01-15 19:05:47 +08:00
|
|
|
pci32-$(CONFIG_PPC32) := pci_32.o
|
2007-06-27 14:17:57 +08:00
|
|
|
obj-$(CONFIG_PCI) += $(pci64-y) $(pci32-y) pci-common.o
|
2007-05-08 10:58:34 +08:00
|
|
|
obj-$(CONFIG_PCI_MSI) += msi.o
|
2006-07-05 12:39:43 +08:00
|
|
|
kexec-$(CONFIG_PPC64) := machine_kexec_64.o
|
[PATCH] powerpc: Merge kexec
This patch merges, to some extent, the PPC32 and PPC64 kexec implementations.
We adopt the PPC32 approach of having ppc_md callbacks for the kexec functions.
The current PPC64 implementation becomes the "default" implementation for PPC64
which platforms can select if they need no special treatment.
I've added these default callbacks to pseries/maple/cell/powermac, this means
iSeries no longer supports kexec - but it never worked anyway.
I've renamed PPC32's machine_kexec_simple to default_machine_kexec, inline with
PPC64. Judging by the comments it might be better named machine_kexec_non_of,
or something, but at the moment it's the only implementation for PPC32 so it's
the "default".
Kexec requires machine_shutdown(), which is in machine_kexec.c on PPC32, but we
already have in setup-common.c on powerpc. All this does is call
ppc_md.nvram_sync, which only powermac implements, so instead make
machine_shutdown a ppc_md member and have it call core99_nvram_sync directly
on powermac.
I've also stuck relocate_kernel.S into misc_32.S for powerpc.
Built for ARCH=ppc, and 32 & 64 bit ARCH=powerpc, with KEXEC=y/n. Booted on
P5 LPAR and successfully kexec'ed.
Should apply on top of 493f25ef4087395891c99fcfe2c72e62e293e89f.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-14 20:35:00 +08:00
|
|
|
kexec-$(CONFIG_PPC32) := machine_kexec_32.o
|
2006-07-05 12:39:43 +08:00
|
|
|
obj-$(CONFIG_KEXEC) += machine_kexec.o crash.o $(kexec-y)
|
2006-09-01 07:02:42 +08:00
|
|
|
obj-$(CONFIG_AUDIT) += audit.o
|
|
|
|
|
obj64-$(CONFIG_AUDIT) += compat_audit.o
|
2005-09-30 14:16:52 +08:00
|
|
|
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
|
2006-11-13 06:27:39 +08:00
|
|
|
obj-y += iomap.o
|
[POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits
This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).
While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).
A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).
Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.
In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)
Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.
The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-11 14:25:10 +08:00
|
|
|
endif
|
|
|
|
|
|
2005-09-30 14:16:52 +08:00
|
|
|
ifeq ($(CONFIG_PPC_ISERIES),y)
|
2007-08-11 07:03:11 +08:00
|
|
|
CFLAGS_lparmap.s += -g0
|
2006-11-30 13:55:04 +08:00
|
|
|
extra-y += lparmap.s
|
2006-12-08 13:57:49 +08:00
|
|
|
$(obj)/head_64.o: $(obj)/lparmap.s
|
2005-10-10 20:45:07 +08:00
|
|
|
AFLAGS_head_64.o += -I$(obj)
|
|
|
|
|
endif
|
2005-10-11 20:08:12 +08:00
|
|
|
|
|
|
|
|
else
|
2005-11-14 14:30:17 +08:00
|
|
|
# stuff used from here for ARCH=ppc
|
2005-11-05 07:33:55 +08:00
|
|
|
smpobj-$(CONFIG_SMP) += smp.o
|
2005-10-11 20:08:12 +08:00
|
|
|
|
2005-09-30 14:16:52 +08:00
|
|
|
endif
|
[PATCH] powerpc: Fix handling of fpscr on 64-bit
The recent merge of fpu.S broken the handling of fpscr for
ARCH=powerpc and CONFIG_PPC64=y. FP registers could be corrupted,
leading to strange random application crashes.
The confusion arises, because the thread_struct has (and requires) a
64-bit area to save the fpscr, because we use load/store double
instructions to get it in to/out of the FPU. However, only the low
32-bits are actually used, so we want to treat it as a 32-bit quantity
when manipulating its bits to avoid extra load/stores on 32-bit. This
patch replaces the current definition with a structure of two 32-bit
quantities (pad and val), to clarify things as much as is possible.
The 'val' field is used when manipulating bits, the structure itself
is used when obtaining the address for loading/unloading the value
from the FPU.
While we're at it, consolidate the 4 (!) almost identical versions of
cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
arch/powerpc/kernel/misc_64.S) into a single version in fpu.S. The
new version takes a pointer to thread_struct and applies the correct
offset itself, rather than a pointer to the fpscr field itself, again
to avoid confusion as to which is the correct field to use.
Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
code, which it previously did not.
Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
Booted on G5 (ARCH=powerpc) and things which previously fell over no
longer do.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-27 14:27:25 +08:00
|
|
|
|
2006-03-27 16:28:58 +08:00
|
|
|
obj-$(CONFIG_PPC32) += $(obj32-y)
|
2005-11-18 12:43:34 +08:00
|
|
|
obj-$(CONFIG_PPC64) += $(obj64-y)
|
|
|
|
|
|
[PATCH] powerpc: Fix handling of fpscr on 64-bit
The recent merge of fpu.S broken the handling of fpscr for
ARCH=powerpc and CONFIG_PPC64=y. FP registers could be corrupted,
leading to strange random application crashes.
The confusion arises, because the thread_struct has (and requires) a
64-bit area to save the fpscr, because we use load/store double
instructions to get it in to/out of the FPU. However, only the low
32-bits are actually used, so we want to treat it as a 32-bit quantity
when manipulating its bits to avoid extra load/stores on 32-bit. This
patch replaces the current definition with a structure of two 32-bit
quantities (pad and val), to clarify things as much as is possible.
The 'val' field is used when manipulating bits, the structure itself
is used when obtaining the address for loading/unloading the value
from the FPU.
While we're at it, consolidate the 4 (!) almost identical versions of
cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
arch/powerpc/kernel/misc_64.S) into a single version in fpu.S. The
new version takes a pointer to thread_struct and applies the correct
offset itself, rather than a pointer to the fpscr field itself, again
to avoid confusion as to which is the correct field to use.
Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
code, which it previously did not.
Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
Booted on G5 (ARCH=powerpc) and things which previously fell over no
longer do.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-10-27 14:27:25 +08:00
|
|
|
extra-$(CONFIG_PPC_FPU) += fpu.o
|
2005-10-28 10:51:45 +08:00
|
|
|
extra-$(CONFIG_PPC64) += entry_64.o
|