summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* x86, irq: Move __setup_vector_irq() before the first irq enable in cpu ↵Suresh Siddha2010-01-292-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | online path Lowest priority delivery of logical flat mode is broken on some systems, such that even when IO-APIC RTE says deliver the interrupt to a particular CPU, interrupt subsystem delivers the interrupt to totally different CPU. For example, this behavior was observed on a P4 based system with SiS chipset which was reported by Li Zefan. We have been handling this kind of behavior by making sure that in logical flat mode, we assign the same vector to irq mappings on all the 8 possible logical cpu's. But we have been doing this initial assignment (__setup_vector_irq()) a little late (before which interrupts were already enabled for a short duration). Move the __setup_vector_irq() before the first irq enable point in the cpu online path to avoid the issue of not handling some interrupts that wrongly hit the cpu which is still coming online. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100129194330.283696385@sbs-t61.sc.intel.com> Tested-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86, irq: Update the vector domain for legacy irqs handled by io-apicSuresh Siddha2010-01-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | In the recent change of not reserving IRQ0_VECTOR..IRQ15_VECTOR's on all cpu's, we start with irq 0..15 getting directed to (and handled on) cpu-0. In the logical flat mode, once the AP's are online (and before irqbalance comes into picture), kernel intends to handle these IRQ's on any cpu (as the logical flat mode allows to specify multiple cpu's for the irq destination and the chipset based routing can deliver to the interrupt to any one of the specified cpu's). This was broken with our recent change, which was ending up using only cpu 0 as the destination, even when the kernel was specifying to use all online cpu's for the logical flat mode case. Fix this by updating vector allocation domain (cfg->domain) for legacy irqs, when the IO-APIC handles them. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100129194330.207790269@sbs-t61.sc.intel.com> Tested-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86, irq: Don't block IRQ0_VECTOR..IRQ15_VECTOR's on all cpu'sSuresh Siddha2010-01-194-41/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently IRQ0..IRQ15 are assigned to IRQ0_VECTOR..IRQ15_VECTOR's on all the cpu's. If these IRQ's are handled by legacy pic controller, then the kernel handles them only on cpu 0. So there is no need to block this vector space on all cpu's. Similarly if these IRQ's are handled by IO-APIC, then the IRQ affinity will determine on which cpu's we need allocate the vector resource for that particular IRQ. This can be done dynamically and here also there is no need to block 16 vectors for IRQ0..IRQ15 on all cpu's. Fix this by initially assigning IRQ0..IRQ15 to IRQ0_VECTOR..IRQ15_VECTOR's only on cpu 0. If the legacy controllers like pic handles these irq's, then this configuration will be fixed. If more modern controllers like IO-APIC handle these IRQ's, then we start with this configuration and as IRQ's migrate, vectors (/and cpu's) associated with these IRQ's change dynamically. This will freeup the block of 16 vectors on other cpu's which don't handle IRQ0..IRQ15, which can now be used for other IRQ's that the particular cpu handle. [ hpa: this also an architectural cleanup for future legacy-PIC-free configurations. ] [ hpa: fixed typo NR_LEGACY_IRQS -> NR_IRQS_LEGACY ] Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1263932453.2814.52.camel@sbs-t61.sc.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86, irq: Use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1fSuresh Siddha2010-01-182-33/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | After talking to some more folks inside intel (Peter Anvin, Asit Mallick), the safest option (for future compatibility etc) seen was to use vector 0x20 for IRQ_MOVE_CLEANUP_VECTOR instead of using vector 0x1f (which is documented as reserved vector in the Intel IA32 manuals). Also we don't need to reserve the entire privilege level (all 16 vectors in the priority bucket that IRQ_MOVE_CLEANUP_VECTOR falls into), as the x86 architecture (section 10.9.3 in SDM Vol3a) specifies that with in the priority level, the higher the vector number the higher the priority. And hence we don't need to reserve the complete priority level 0x20-0x2f for the IRQ migration cleanup logic. So change the IRQ_MOVE_CLEANUP_VECTOR to 0x20 and allow 0x21-0x2f to be used for device interrupts. 0x30-0x3f will be used for ISA interrupts (these also can be migrated in the context of IOAPIC and hence need to be at a higher priority level than IRQ_MOVE_CLEANUP_VECTOR). Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100114002118.521826763@sbs-t61.sc.intel.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86, vmi: Fix vmi_get_timer_vector() to use IRQ0_VECTORSuresh Siddha2010-01-181-7/+1
| | | | | | | | | | | | | | FIRST_DEVICE_VECTOR is going away and it looks like a bad hack to steal FIRST_DEVICE_VECTOR / FIRST_EXTERNAL_VECTOR, when it looks like it needs IRQ0_VECTOR. Fix vmi_get_timer_vector() to use IRQ0_VECTOR. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100114002118.436172066@sbs-t61.sc.intel.com> Cc: Alok N Kataria <akataria@vmware.com> Cc: Zach Amsden <zach@vmware.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86, apic: Don't waste a vector to improve vector spreadH. Peter Anvin2010-01-042-5/+7
| | | | | | | | | | | | | We want to use a vector-assignment sequence that avoids stumbling onto 0x80 earlier in the sequence, in order to improve the spread of vectors across priority levels on machines with a small number of interrupt sources. Right now, this is done by simply making the first vector (0x31 or 0x41) completely unusable. This is unnecessary; all we need is to start assignment at a +1 offset, we don't actually need to prohibit the usage of this vector once we have wrapped around. Signed-off-by: H. Peter Anvin <hpa@zytor.com> LKML-Reference: <4B426550.6000209@kernel.org>
* x86, apic: Reclaim IDT vectors 0x20-0x2fH. Peter Anvin2010-01-041-8/+20
| | | | | | | | | | | | | | | | | | | | | | | Reclaim 16 IDT vectors and make them available for general allocation. Reclaim vectors 0x20-0x2f by reallocating the IRQ_MOVE_CLEANUP_VECTOR to vector 0x1f. This is in the range of vector numbers that is officially reserved for the CPU (for exceptions), however, the use of the APIC to generate any vector 0x10 or above is documented, and the CPU internally can receive any vector number (the legacy BIOS uses INT 0x08-0x0f for interrupts, as messed up as that is.) Since IRQ_MOVE_CLEANUP_VECTOR has to be alone in the lowest-numbered priority level (block of 16), this effectively enables us to reclaim an otherwise-unusable APIC priority level and put it to use. Since this is a transient kernel-only allocation we can change it at any time, and if/when there is an exception at vector 0x1f this assignment needs to be changed as part of OS enabling that new feature. Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4B4284C6.9030107@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* x86: Increase NR_IRQS and nr_irqsYinghai Lu2009-12-302-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I have a system with lots of igb and ixgbe, when iov/vf are enabled for them, we hit the limit of 3064. when system has 20 pcie installed, and one card has 2 functions, and one function needs 64 msi-x, may need 20 * 2 * 64 = 2560 for msi-x but if iov and vf are enabled may need 20 * 2 * 64 * 3 = 7680 for msi-x assume system with 5 ioapic, nr_irqs_gsi will be 120. NR_CPUS = 512, and nr_cpu_ids = 128 will have NR_IRQS = 256 + 512 * 64 = 33024 will have nr_irqs = 120 + 8 * 128 + 120 * 64 = 8824 When SPARSE_IRQ is not set, there is no increase with kernel data size. when NR_CPUS=128, and SPARSE_IRQ is set: text data bss dec hex filename 21837444 4216564 12480736 38534744 24bfe58 vmlinux.before 21837442 4216580 12480736 38534758 24bfe66 vmlinux.after when NR_CPUS=4096, and SPARSE_IRQ is set text data bss dec hex filename 21878619 5610244 13415392 40904255 270263f vmlinux.before 21878617 5610244 13415392 40904253 270263d vmlinux.after Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <4B398ECD.1080506@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* Merge branch 'release' of ↵Linus Torvalds2009-12-247-192/+36
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (34 commits) classmate-laptop: add support for Classmate PC ACPI devices hp-wmi: Fix two memleaks acer-wmi, msi-wmi: Remove needless DMI MODULE_ALIAS dell-wmi: do not keep driver loaded on unsupported boxes wmi: Free the allocated acpi objects through wmi_get_event_data drivers/platform/x86/acerhdf.c: check BIOS information whether it begins with string of table acerhdf: add new BIOS versions acerhdf: limit modalias matching to supported toshiba_acpi: convert to seq_file asus_acpi: convert to seq_file ACPI: do not select ACPI_DOCK from ATA_ACPI sony-laptop: enumerate rfkill devices using SN06 sony-laptop: rfkill support for newer models ACPI: fix OSC regression that caused aer and pciehp not to load MAINTAINERS: add maintainer for msi-wmi driver fujitu-laptop: fix tests of acpi_evaluate_integer() return value arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by using smp_call_function_any() ACPI: processor: remove _PDC object list from struct acpi_processor ACPI: processor: change acpi_processor_set_pdc() interface ACPI: processor: open code acpi_processor_cleanup_pdc ...
| * Merge branch 'misc-2.6.33' into releaseLen Brown2009-12-241-1/+3
| |\
| | * arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by ↵Andrew Morton2009-12-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | using smp_call_function_any() Presently acpi-cpufreq will perform the MSR read on the first CPU in the mask. That's inefficient if that CPU differs from the current CPU. Because we have to perform a cross-CPU call, but we could have run the rdmsr on the current CPU. So switch to using the new smp_call_function_any(), which will perform the call on the current CPU if that CPU is present in the mask (it is). Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Cc: Dave Jones <davej@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Jaswinder Singh Rajput <jaswinder@kernel.org> Cc: Len Brown <len.brown@intel.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * | Merge branch 'pdc' into releaseLen Brown2009-12-246-191/+33
| |\ \
| | * | ACPI: processor: unify arch_acpi_processor_cleanup_pdcAlex Chiang2009-12-224-57/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The x86 and ia64 implementations of the function in $subject are exactly the same. Also, since the arch-specific implementations of setting _PDC have been completely hollowed out, remove the empty shells. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: processor: finish unifying arch_acpi_processor_init_pdc()Alex Chiang2009-12-224-52/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only thing arch-specific about calling _PDC is what bits get set in the input obj_list buffer. There's no need for several levels of indirection to twiddle those bits. Additionally, since we're just messing around with a buffer, we can simplify the interface; no need to pass around the entire struct acpi_processor * just to get at the buffer. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: processor: factor out common _PDC settingsAlex Chiang2009-12-222-18/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both x86 and ia64 initialize _PDC with mostly common bit settings. Factor out the common settings and leave the arch-specific ones alone. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: processor: unify arch_acpi_processor_init_pdcAlex Chiang2009-12-222-66/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The x86 and ia64 implementations of arch_acpi_processor_init_pdc() are almost exactly the same. The only difference is in what bits they set in obj_list buffer. Combine the boilerplate memory management code, and leave the arch-specific bit twiddling in separate implementations. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: processor: introduce arch_has_acpi_pdcAlex Chiang2009-12-223-3/+10
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arch dependent helper function that tells us if we should attempt to evaluate _PDC on this machine or not. The x86 implementation assumes that the CPUs in the machine must be homogeneous, and that you cannot mix CPUs of different vendors. Cc: Tony Luck <tony.luck@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by: Alex Chiang <achiang@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds2009-12-24180-547/+313
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm: VIDEO: cyberpro: pci_request_regions needs a persistent name ARM: dma-isa: request cascade channel after registering it ARM: footbridge: trim down old ISA rtc setup ARM: fix PAGE_KERNEL ARM: Fix wrong shared bit for CPU write buffer bug test ARM: 5857/1: ARM: dmabounce: fix build ARM: 5856/1: Fix bug of uart0 platfrom data for nuc900 ARM: 5855/1: putc support for nuc900 ARM: 5854/1: fix compiling error for NUC900 ARM: 5849/1: ARMv7: fix Oprofile events count ARM: add missing include to nwflash.c ARM: Kill CONFIG_CPU_32 ARM: Convert VFP/Crunch/XscaleCP thread_release() to exit_thread() ARM: 5853/1: ARM: Fix build break on ARM v6 and v7
| * | | ARM: dma-isa: request cascade channel after registering itRussell King2009-12-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't request the cascade channel before it's been registered, so move it afterwards. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: footbridge: trim down old ISA rtc setupRussell King2009-12-246-174/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a "start_kernel(): bug: interrupts were enabled early". rtc_cmos now takes care of initializing the ISA RTC and reading the current time and date from it; there's no need to repeat that here, thereby causing interrupts to be enabled too early. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: fix PAGE_KERNELRussell King2009-12-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PAGE_KERNEL should not be executable; any area marked executable can be prefetched into the instruction cache. We don't want vmalloc areas to be read in this way. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: Fix wrong shared bit for CPU write buffer bug testRussell King2009-12-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is unpredictable to have the same memory mapped using different shared bit settings for ARMv6 and ARMv7 CPUs. Fix this for the CPU write buffer bug test. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5857/1: ARM: dmabounce: fix buildMike Rapoport2009-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f74f7e57ae9fa12b2951ae62ce3557799b318399 (ARM: use flush_kernel_dcache_area() for dmabounce) has broken dmabounce build: CC arch/arm/common/dmabounce.o arch/arm/common/dmabounce.c: In function 'unmap_single': arch/arm/common/dmabounce.c:315: error: implicit declaration of function '__cpuc_flush_kernel_dcache_area' make[2]: *** [arch/arm/common/dmabounce.o] Error 1 Fix it. Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5856/1: Fix bug of uart0 platfrom data for nuc900wanzongshun2009-12-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix bug of uart0 platfrom data for nuc900 Signed-off-by: lijie <eltshanli@gmail.com> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5855/1: putc support for nuc900wanzongshun2009-12-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | putc support for nuc900 Signed-off-by: lijie <eltshanli@gmail.com> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5854/1: fix compiling error for NUC900wanzongshun2009-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fix compiling error for NUC900 Signed-off-by: lijie <eltshanli@gmail.com> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5849/1: ARMv7: fix Oprofile events countJean PIHET2009-12-221-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Oprofile ARMv7 the PMNC_D bit was set to lower the PMU IRQs and so to decrease the risk of errata #628216 from appearing. The effect of setting the PMNC_D bit is that the CCNT counter is divided by 64, making the program counter events count inaccurate. The new OMAP3 r4 cores should have that errata fixed. The PMNC_D bit should not be set, this patch fixes it. Signed-off-by: Jean Pihet <jpihet@mvista.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: Kill CONFIG_CPU_32Russell King2009-12-18160-339/+200
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 26-bit ARM support was removed a long time ago, and this symbol has been defined to be 'y' ever since. As it's never disabled anymore, we can kill it without any side effects. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: Convert VFP/Crunch/XscaleCP thread_release() to exit_thread()Russell King2009-12-185-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This avoids races in the VFP code where the dead thread may have state on another CPU. By moving this code to exit_thread(), we will be running as the thread, and therefore be running on the current CPU. This means that we can ensure that the only local state is accessed in the thread notifiers. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | ARM: 5853/1: ARM: Fix build break on ARM v6 and v7Anand Gadiyar2009-12-181-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2c9b9c849 added an argument to __cpuc_flush_dcache_page and renamed it. Update a caller of the old function to fix this build error: CC arch/arm/mm/copypage-v6.o arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing': arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page' make[1]: *** [arch/arm/mm/copypage-v6.o] Error 1 make: *** [arch/arm/mm] Error 2 Reported-by: Jinsung Yang <jsgood.yang@samsung.com> Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | Merge branch 'sh/g3-prep' into sh/for-2.6.33Paul Mundt2009-12-24418-4676/+18603
|\ \ \ | | |/ | |/|
| * | Revert "x86, ucode-amd: Ensure ucode update on suspend/resume after CPU ↵Linus Torvalds2009-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | off/online cycle" This reverts commit 9f15226e75583547aaf542c6be4bdac1060dd425. It's just wrong, and broke resume for Rafael even on a non-AMD CPU. As Rafael says: "... it causes microcode_init_cpu() to be called during resume even for CPUs for which there's no microcode to apply. That, in turn, results in executing request_firmware() (on Intel CPUs at least) which doesn't work at this stage of resume (we have device interrupts disabled, I/O devices are still suspended and so on). If I'm not mistaken, the "if (uci->valid)" logic means "if that CPU is known to us" , so before commit 9f15226e755 microcode_resume_cpu() was called for all CPUs already in the system during suspend, which was the right thing to do. The commit changed it so that the CPUs without microcode to apply are now treated as "unknown", which is not quite right. The problem this commit attempted to solve has to be handled differently." Bisected-and -requested-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Merge branch 'merge' of ↵Linus Torvalds2009-12-2233-171/+738
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (36 commits) powerpc/gc/wii: Remove get_irq_desc() powerpc/gc/wii: hlwd-pic: convert irq_desc.lock to raw_spinlock powerpc/gamecube/wii: Fix off-by-one error in ugecon/usbgecko_udbg powerpc/mpic: Fix problem that affinity is not updated powerpc/mm: Fix stupid bug in subpge protection handling powerpc/iseries: use DECLARE_COMPLETION_ONSTACK for non-constant completion powerpc: Fix MSI support on U4 bridge PCIe slot powerpc: Handle VSX alignment faults correctly in little-endian mode powerpc/mm: Fix typo of cpumask_clear_cpu() powerpc/mm: Fix hash_utils_64.c compile errors with DEBUG enabled. powerpc: Convert BUG() to use unreachable() powerpc/pseries: Make declarations of cpu_hotplug_driver_lock() ANSI compatible. powerpc/pseries: Don't panic when H_PROD fails during cpu-online. powerpc/mm: Fix a WARN_ON() with CONFIG_DEBUG_PAGEALLOC and CONFIG_DEBUG_VM powerpc/defconfigs: Set HZ=100 on pseries and ppc64 defconfigs powerpc/defconfigs: Disable token ring in powerpc defconfigs powerpc/defconfigs: Reduce 64bit vmlinux by making acenic and cramfs modules powerpc/pseries: Select XICS and PCI_MSI PSERIES powerpc/85xx: Wrong variable returned on error powerpc/iseries: Convert to proc_fops ...
| | * | powerpc/gc/wii: Remove get_irq_desc()Albert Herranz2009-12-212-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following build failures: arch/powerpc/platforms/embedded6xx/flipper-pic.c: In function 'flipper_pic_map': arch/powerpc/platforms/embedded6xx/flipper-pic.c:105: error: implicit declaration of function 'get_irq_desc' arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_map': arch/powerpc/platforms/embedded6xx/hlwd-pic.c:98: error: implicit declaration of function 'get_irq_desc' These failures are caused by the changes introduced in commit "powerpc: Remove get_irq_desc()". The reason these drivers were not updated is that they weren't merged yet. Signed-off-by: Albert Herranz <albert_herranz@yahoo.es> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| | * | powerpc/gc/wii: hlwd-pic: convert irq_desc.lock to raw_spinlockAlbert Herranz2009-12-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following build failures: arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_irq_cascade': arch/powerpc/platforms/embedded6xx/hlwd-pic.c:135: error: passing argument 1 of 'spin_lock' from incompatible pointer type arch/powerpc/platforms/embedded6xx/hlwd-pic.c:137: error: passing argument 1 of 'spin_unlock' from incompatible pointer type arch/powerpc/platforms/embedded6xx/hlwd-pic.c:145: error: passing argument 1 of 'spin_lock' from incompatible pointer type arch/powerpc/platforms/embedded6xx/hlwd-pic.c:149: error: passing argument 1 of 'spin_unlock' from incompatible pointer type These failures are caused by the changes introduced in commit "genirq: Convert irq_desc.lock to raw_spinlock". The reason this driver was not updated is that it wasn't merged yet. Signed-off-by: Albert Herranz <albert_herranz@yahoo.es> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| | * | Merge commit 'jwb/next' into mergeBenjamin Herrenschmidt2009-12-212-2/+52
| | |\ \
| | | * | powerpc/44x: Increase warp SD bufferSean MacLennan2009-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer revs of the FPGA have a larger SD buffer. Signed-off-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
| | | * | powerpc/44x: Extend Katmai dts for ADMA and RAID56 supportAnatolij Gustschin2009-12-111-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add nodes for PPC440SPe DMA, I2O, XOR engines and Memory Queue module which are used in the updated PPC440SPe ADMA driver. Also extend plb ranges property to specify address ranges for DMA0/1 and I2O engines. Signed-off-by: Yuri Tikhonov <yur@emcraft.com> Signed-off-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
| | * | | Merge commit 'kumar/next' into mergeBenjamin Herrenschmidt2009-12-217-17/+206
| | |\ \ \
| | | * | | powerpc/85xx: Workaround MPC8572/MPC8536 GPIO 1 errata.Felix Radensky2009-12-101-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On MPC8572 and MPC8536 the status of GPIO pins configured as output cannot be determined by reading GPDAT register. Workaround by reading the status of input pins from GPDAT and the status of output pins from a shadow register. Signed-off-by: Felix Radensky <felix@embedded-sol.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/gpio: support gpio_to_irq()Peter Korsgaard2009-12-101-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gpiolib returns -ENXIO if struct gpio_chip::to_irq isn't set, so it's safe to always call. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx: Add power management support for MPC8315E-RDB boardsAnton Vorontsov2009-12-101-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add nodes for PMC and GTM controllers. GTM4 can be used as a wakeup source; - Add fsl,magic-packet properties to eTSEC nodes, i.e. wake-on-lan support. Unlike MPC8313 processors, MPC8315 can resume from deep sleep upon magic packet reception. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx/suspend: Save and restore SICRL, SICRH and SCCRAnton Vorontsov2009-12-101-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to save SICRL, SICRH and SCCR registers on suspend, and restore them on resume. Otherwise, we lose IO and clocks setup on MPC8315E-RDB boards when ULPI USB PHY is used (non-POR setup). Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx/suspend: Clear deep_sleeping after devices resumeAnton Vorontsov2009-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently 83xx PMC driver clears deep_sleeping variable very early, before devices are resumed. This makes fsl_deep_sleep() unusable in drivers' resume() callback. Sure, drivers can store fsl_deep_sleep() value on suspend and use the stored value on resume. But a better solution is to postpone clearing the deep_sleeping variable, i.e. move it into finish() callback. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/cpm2_pic: Allow correct flow_types for port C interruptsMark Ware2009-12-101-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Port C interrupts can be either falling edge, or either edge. Other external interrupts are either falling edge or active low. Tested on a custom 8280 based board. Signed-off-by: Mark Ware <mware@elphinstone.net> Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx: mpc8349emitx - add leds-gpio bindingDmitry Eremin-Solenikov2009-12-091-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx: mpc8349emitx - add OF descriptions of LocalBus devicesDmitry Eremin-Solenikov2009-12-091-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe all LocalBus chipselects on MPC8349E-MITX board. Also add flash bindings. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx: mpc8349emitx - populate I2C busses in device treeDmitry Eremin-Solenikov2009-12-091-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add OF descriptions of EEPROM, two GPIO extenders and SPD hanging on I2C on this board. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/83xx: mpc8349emitx - add gpio controller declarationsDmitry Eremin-Solenikov2009-12-091-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpc8349 bears two GPIO controllers. Enable support for them. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
| | | * | | powerpc/fsl_pci: Fix P2P bridge handling for MPC83xx PCIe controllersAnton Vorontsov2009-12-091-2/+6
| | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that we wrongly calculate dev_base for type1 config cycles. The thing is: we shouldn't subtract hose->first_busno because PCI core sets PCI primary, secondary and subordinate bus numbers, and PCIe controller actually takes the registers into account. So we should use just bus->number. Also, according to MPC8315 reference manual, primary bus number should always remain 0. We have PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS quirk in indirect_pci.c, but since 83xx is somewhat special, it doesn't use indirect_pci.c routines, so we have to implement the quirk specifically for 83xx PCIe controllers. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
OpenPOWER on IntegriCloud