aboutsummaryrefslogtreecommitdiff
path: root/arch/ppc64/Kconfig
AgeCommit message (Collapse)Author
2005-09-14[LIB]: Consolidate _atomic_dec_and_lock()David S. Miller
Several implementations were essentialy a common piece of C code using the cmpxchg() macro. Put the implementation in one spot that everyone can share, and convert sparc64 over to using this. Alpha is the lone arch-specific implementation, which codes up a special fast path for the common case in order to avoid GP reloading which a pure C version would require. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-07[PATCH] Kconfig fix (BLK_DEV_FD dependencies)viro@ZenIV.linux.org.uk
Sanitized and fixed floppy dependencies: split the messy dependencies for BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC to arch/*/Kconfig. While we are at it, fixed several obvious cases when BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h are *not* going to have floppy.c compile, let alone work). If you can come up with better name for that ("this architecture might have working PC-compatible floppy disk controller"), you are more than welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch below... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-29[PATCH] ppc64: Remove CONFIG_MSCHUNKSMichael Ellerman
We can now remove CONFIG_MSCHUNKS as it doesn't do anything interesting anymore. The only macro in abs_addr.h which is called by non-iSeries code is phys_to_abs(), so remove the other dummy implementations, and we add a firmware feature check to phys_to_abs(). Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-29[PATCH] ppc64: change duplicate Kconfig menu "General setup" to "Bus Options"Frank Rowand
arch/ppc64/Kconfig defines a "General setup" menu, but also sources init/Kconfig which also defines a "General setup" menu. Both of these menus appear at the top level of make menuconfig. Having two menus with the same name is confusing. This patch renames the ppc64/Kconfig menu to be "Bus Options" and moves options in this menu which are not bus related to the end of the "Platform support" menu. There are many variations among architectures on the exact naming of the "Bus Options" menu. I chose to use the simplest one, which is also used in arch/ppc/Kconfig. Signed-off-by: Frank Rowand <frowand@mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-07-27[PATCH] ppc/ppc64: use Kconfig.hzOlaf Hering
use new Kconfig.hz on ppc/ppc64, use also Kconfig.preempt for ppc Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-11[NET]: add a top-level Networking menu to *configSam Ravnborg
Create a new top-level menu named "Networking" thus moving net related options and protocol selection way from the drivers menu and up on the top-level where they belong. To implement this all architectures has to source "net/Kconfig" before drivers/*/Kconfig in their Kconfig file. This change has been implemented for all architectures. Device drivers for ordinary NIC's are still to be found in the Device Drivers section, but Bluetooth, IrDA and ax25 are located with their corresponding menu entries under the new networking menu item. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-25[PATCH] ppc64: kexec support for ppc64R Sharada
This patch implements the kexec support for ppc64 platforms. A couple of notes: 1) We copy the pages in virtual mode, using the full base kernel and a statically allocated stack. At kexec_prepare time we scan the pages and if any overlap our (0, _end[]) range we return -ETXTBSY. On PowerPC 64 systems running in LPAR (logical partitioning) mode, only a small region of memory, referred to as the RMO, can be accessed in real mode. Since Linux runs with only one zone of memory in the memory allocator, and it can be orders of magnitude more memory than the RMO, looping until we allocate pages in the source region is not feasible. Copying in virtual means we don't have to write a hash table generation and call hypervisor to insert translations, instead we rely on the pinned kernel linear mapping. The kernel already has move to linked location built in, so there is no requirement to load it at 0. If we want to load something other than a kernel, then a stub can be written to copy a linear chunk in real mode. 2) The start entry point gets passed parameters from the kernel. Slaves are started at a fixed address after copying code from the entry point. All CPUs get passed their firmware assigned physical id in r3 (most calling conventions use this register for the first argument). This is used to distinguish each CPU from all other CPUs. Since firmware is not around, there is no other way to obtain this information other than to pass it somewhere. A single CPU, referred to here as the master and the one executing the kexec call, branches to start with the address of start in r4. While this can be calculated, we have to load it through a gpr to branch to this point so defining the register this is contained in is free. A stack of unspecified size is available at r1 (also common calling convention). All remaining running CPUs are sent to start at absolute address 0x60 after copying the first 0x100 bytes from start to address 0. This convention was chosen because it matches what the kernel has been doing itself. (only gpr3 is defined). Note: This is not quite the convention of the kexec bootblock v2 in the kernel. A stub has been written to convert between them, and we may adjust the kernel in the future to allow this directly without any stub. 3) Destination pages can be placed anywhere, even where they would not be accessible in real mode. This will allow us to place ram disks above the RMO if we choose. Signed-off-by: Milton Miller <miltonm@bga.com> Signed-off-by: R Sharada <sharada@in.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25[PATCH] consolidate PREEMPT options into kernel/Kconfig.preemptIngo Molnar
This patch consolidates the CONFIG_PREEMPT and CONFIG_PREEMPT_BKL preemption options into kernel/Kconfig.preempt. This, besides reducing source-code, also enables more centralized tweaking of preemption related options. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/ppc64-2.6Linus Torvalds
2005-06-23[PATCH] ppc64: sparsemem memory modelAndy Whitcroft
Provide the architecture specific implementation for SPARSEMEM for PPC64 systems. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Mike Kravetz <kravetz@us.ibm.com> (in part) Signed-off-by: Martin Bligh <mbligh@aracnet.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] ppc64: add memory presentAndy Whitcroft
Provide hooks for PPC64 to allow memory models to be informed of installed memory areas. This allows SPARSEMEM to instantiate mem_map for the populated areas. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Martin Bligh <mbligh@aracnet.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] ppc64: add early_pfn_to_nidAndy Whitcroft
Provide an implementation of early_pfn_to_nid for PPC64. This is used by memory models to determine the node from which to take allocations before the memory allocators are fully initialised. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Martin Bligh <mbligh@aracnet.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] sparsemem swiss cheese numa layoutsAndy Whitcroft
The part of the sparsemem patch which modifies memmap_init_zone() has recently become a problem. It changes behavior so that there is a call to pfn_to_page() for each individual page inside of a node's range: node_start_pfn through node_end_pfn. It used to simply do this once, at the beginning of the node, but having sparsemem's non-contiguous mem_map[]s inside of a node made it necessary to change. Mike Kravetz recently wrote a patch which made the NUMA code accept some new kinds of layouts. The system's memory was laid out like this, with node 0's memory in two pieces: one before and one after node 1's memory: Node 0: +++++ +++++ Node 1: +++++ Previous behavior before Mike's patch was to assign nodes like this: Node 0: 00000 XXXXX Node 1: 11111 Where the 'X' areas were simply thrown away. The new behavior was to make the pg_data_t span node 0 across all of its areas, including areas that are really node 1's: Node 0: 000000000000000 Node 1: 11111 This wastes a little bit of mem_map space, but ends up being OK, and more fully utilizes the system's memory. memmap_init_zone() initializes all of the "struct page"s for node 0, even for the "hole", but those never get used, because there is no pfn_to_page() that resolves to those pages. However, only calling pfn_to_page() once, memmap_init_zone() always uses the pages that were allocated for node0->node_mem_map because: struct page *start = pfn_to_page(start_pfn); // effectively start = &node->node_mem_map[0] for (page = start; page < (start + size); page++) { init_page_here();... page++; } Slow, and wasteful, but generally harmless. But, modify that to call pfn_to_page() for each loop iteration (like sparsemem does): for (pfn = start_pfn; pfn < < (start_pfn + size); pfn++++) { page = pfn_to_page(pfn); } And you end up trying to initialize node 1's pages too early, along with bogus data from node 0. This patch checks for those weird layouts and declines to touch the pages, making the more frequent pfn_to_page() calls OK to do. Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andy Whitcroft <apw@shadowen.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] ppc64: Kconfig memory modelsMike Kravetz
This patch changes some of the default behavior in the ppc64 Kconfig file that was recently changed/added to 2.6.12-rc2-mm1 by Dave Hansen in preparation for SPARSEMEM. Patch allows the display of both FLAT and DISCONTIG models on pseries. As before, default is DISCONTIG for SMP and PSERIES and FLAT for others. Signed-off-by: Mike Kravetz <kravetz@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] make each arch use mm/KconfigDave Hansen
For all architectures, this just means that you'll see a "Memory Model" choice in your architecture menu. For those that implement DISCONTIGMEM, you may eventually want to make your ARCH_DISCONTIGMEM_ENABLE a "def_bool y" and make your users select DISCONTIGMEM right out of the new choice menu. The only disadvantage might be if you have some specific things that you need in your help option to explain something about DISCONTIGMEM. Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23[PATCH] ppc64: Add driver for BPA interrupt controllersArnd Bergmann
Add support for the integrated interrupt controller on BPA CPUs. There is one of those for each SMT thread. The mapping of interrupt numbers to HW interrupt sources is described in arch/ppc64/kernel/bpa_iic.h. This version hardcodes the 'Spider' chip as the secondary interrupt controller. That is not really generic for the architecture, but at the moment it is the only secondary PIC that exists. A little more work will be needed on this as soon as we have boards with multiple external interrupt controllers. Signed-off-by: Arnd Bergmann <arndb@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-06-23[PATCH] ppc64: add BPA platform typeArnd Bergmann
This adds the basic support for running on BPA machines. So far, this is only the IBM workstation, and it will not run on others without a little more generalization. It should be possible to configure a kernel for any combination of CONFIG_PPC_BPA with any of the other multiplatform targets. Signed-off-by: Arnd Bergmann <arndb@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-06-21[PATCH] ppc64 iSeries: allow build with no PCIStephen Rothwell
This patch allows iSeries to build with CONFIG_PCI=n. This is useful for partitions that have only virtual I/O. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-06[PATCH] ppc64: enable CONFIG_RTAS_PROC by defaultPaul Mackerras
This patch enables CONFIG_RTAS_PROC by default on pSeries. This will preserve /proc/ppc64/rtas/rmo_buffer, which is needed by librtas. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05[PATCH] ppc64: remove hidden -fno-omit-frame-pointer for schedule.cAnton Blanchard
While looking at code generated by gcc4.0 I noticed some functions still had frame pointers, even after we stopped ppc64 from defining CONFIG_FRAME_POINTER. It turns out kernel/Makefile hardwires -fno-omit-frame-pointer on when compiling schedule.c. Create CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER and define it on architectures that dont require frame pointers in sched.c code. (akpm: blame me for the name) Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-04[PATCH] ISA DMA Kconfig fixes - part 1Al Viro
A bunch of drivers use ISA DMA helpers or their equivalents for platforms that have ISA with different DMA controller (a lot of ARM boxen). Currently there is no way to put such dependency in Kconfig - CONFIG_ISA is not it (e.g. it is not set on platforms that have no ISA slots, but have on-board devices that pretend to be ISA ones). New symbol added - ISA_DMA_API. Set when we have functional enable_dma()/set_dma_mode()/etc. set of helpers. Next patches in the series will add missing dependencies for drivers that need them. I'm very carefully staying the hell out of the recurring flamefest on what exactly CONFIG_ISA would mean in ideal world - added symbol has a well-defined meaning and for now I really want to treat it as completely independent from the mess around CONFIG_ISA. Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16[PATCH] ppc64: remove -fno-omit-frame-pointerAnton Blanchard
During some code inspection using gcc 4.0 I noticed a stack frame was being created for a number of functions that didnt require it. For example: c0000000000df944 <._spin_unlock>: c0000000000df944: fb e1 ff f0 std r31,-16(r1) c0000000000df948: f8 21 ff c1 stdu r1,-64(r1) c0000000000df94c: 7c 3f 0b 78 mr r31,r1 c0000000000df950: 7c 20 04 ac lwsync c0000000000df954: e8 21 00 00 ld r1,0(r1) c0000000000df958: 38 00 00 00 li r0,0 c0000000000df95c: 90 03 00 00 stw r0,0(r3) c0000000000df960: eb e1 ff f0 ld r31,-16(r1) c0000000000df964: 4e 80 00 20 blr It turns out we are adding -fno-omit-frame-pointer to ppc64 which is causing the above behaviour. Removing that flag results in much better code: c0000000000d5b30 <._spin_unlock>: c0000000000d5b30: 7c 20 04 ac lwsync c0000000000d5b34: 38 00 00 00 li r0,0 c0000000000d5b38: 90 03 00 00 stw r0,0(r3) c0000000000d5b3c: 4e 80 00 20 blr We dont require a frame pointer to debug on ppc64, so remove it. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus 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!