aboutsummaryrefslogtreecommitdiff
path: root/arch/parisc/kernel/irq.c
AgeCommit message (Collapse)Author
2009-12-16parisc: Fixup last users of irq_chip->typenameThomas Gleixner
The typename member of struct irq_chip was kept for migration purposes and is obsolete since more than 2 years. Fix up the leftovers. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-12-14genirq: Convert irq_desc.lock to raw_spinlockThomas Gleixner
Convert locks which cannot be sleeping locks in preempt-rt to raw_spinlocks. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Ingo Molnar <mingo@elte.hu>
2009-09-28parisc: convert to asm-generic/hardirq.hChristoph Hellwig
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-07-03parisc: remove obsolete hw_interrupt_typeThomas Gleixner
The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) have been kept around for migration reasons. After more than two years it's time to remove them finally. This patch cleans up one of the remaining users. When all such patches hit mainline we can remove the defines and typedefs finally. Impact: cleanup Convert the last remaining users to struct irq_chip and remove the define. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-07-03parisc: fix irq compile bugs in arch/parisc/kernel/irq.cHelge Deller
Fix miscompilation in arch/parisc/kernel/irq.c: 123: warning: passing arg 1 of `cpumask_setall' from incompatible pointer type 141: warning: passing arg 1 of `cpumask_copy' from incompatible pointer type 300: warning: passing arg 1 of `cpumask_copy' from incompatible pointer type 357: warning: passing arg 2 of `cpumask_copy' from incompatible pointer type Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-04-28irq: change ->set_affinity() to return statusYinghai Lu
according to Ingo, change set_affinity() in irq_chip should return int, because that way we can handle failure cases in a much cleaner way, in the genirq layer. v2: fix two typos [ Impact: extend API ] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: linux-arch@vger.kernel.org LKML-Reference: <49F654E9.4070809@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-04-02Merge branch 'rusty-cpumask-parisc' into pariscKyle McMartin
2009-03-27Merge branch 'core/percpu' into percpu-cpumask-x86-for-linus-2Ingo Molnar
Conflicts: arch/parisc/kernel/irq.c arch/x86/include/asm/fixmap_64.h arch/x86/include/asm/setup.h kernel/irq/handle.c Semantic merge: arch/x86/include/asm/fixmap.h Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-16Merge branches 'irq/genirq' and 'linus' into irq/coreIngo Molnar
2009-03-16cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: pariscRusty Russell
Impact: cleanup, futureproof In fact, all cpumask ops will only be valid (in general) for bit numbers < nr_cpu_ids. So use that instead of NR_CPUS in various places. This is always safe: no cpu number can be >= nr_cpu_ids, and nr_cpu_ids is initialized to NR_CPUS at boot. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Ingo Molnar <mingo@elte.hu>
2009-03-13parisc: convert cpu_check_affinity to new cpumask apiKyle McMartin
cpumask arg to the affinity function is now const, sort that out through the irq_desc implementations. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-03-13parisc: fix use of new cpumask api in irq.cKyle McMartin
cpumask api needs to take a pointer to irq_desc[cpu].affinity Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-03-13parisc: update parisc for new irq_descMike Travis
Impact: cleanup, update to new cpumask API Irq_desc.affinity and irq_desc.pending_mask are now cpumask_var_t's so access to them should be using the new cpumask API. Signed-off-by: Mike Travis <travis@sgi.com> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-01-12irq: update all arches for new irq_descMike Travis
Impact: cleanup, update to new cpumask API Irq_desc.affinity and irq_desc.pending_mask are now cpumask_var_t's so access to them should be using the new cpumask API. Signed-off-by: Mike Travis <travis@sgi.com>
2009-01-11sparseirq: use kstat_irqs_cpu insteadYinghai Lu
Impact: build fix Ingo Molnar wrote: > tip/arch/blackfin/kernel/irqchip.c: In function 'show_interrupts': > tip/arch/blackfin/kernel/irqchip.c:85: error: 'struct kernel_stat' has no member named 'irqs' > make[2]: *** [arch/blackfin/kernel/irqchip.o] Error 1 > make[2]: *** Waiting for unfinished jobs.... > So could move kstat_irqs array to irq_desc struct. (s390, m68k, sparc) are not touched yet, because they don't support genirq Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-01-05parisc: Replace NR_CPUS in parisc codeHelge Deller
parisc: Replace most arrays sized by NR_CPUS with percpu variables. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2009-01-05parisc: trivial fixesHelge Deller
trivial fixes: - use KERN_WARNING for printk() - use BUG_ON() instead of "if (xx) BUG();" Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2008-12-13cpumask: make irq_set_affinity() take a const struct cpumaskRusty Russell
Impact: change existing irq_chip API Not much point with gentle transition here: the struct irq_chip's setaffinity method signature needs to change. Fortunately, not widely used code, but hits a few architectures. Note: In irq_select_affinity() I save a temporary in by mangling irq_desc[irq].affinity directly. Ingo, does this break anything? (Folded in fix from KOSAKI Motohiro) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> Reviewed-by: Grant Grundler <grundler@parisc-linux.org> Acked-by: Ingo Molnar <mingo@redhat.com> Cc: ralf@linux-mips.org Cc: grundler@parisc-linux.org Cc: jeremy@xensource.com Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
2007-12-06[PARISC] timer interrupt should not be IRQ_DISABLEDKyle McMartin
The timer interrupt had accidentally been marked IRQ_DISABLED since IRQ_PER_CPU had been OR-ed in, instead of set. This had been working by accident for quite a while. Commit c642b8391cf8efc3622cc97329a0f46e7cbb70b8 changed the behaviour of IRQ_PER_CPU interrupts, which previously weren't checked for IRQ_DISABLED. Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
2007-06-12[PARISC] remove global_ack_eiemGrant Grundler
Kudos to Thibaut Varene for spotting the (mis)use of appropriately named global_ack_eiem. This took a long time to figure out and both insight from myself, Kyle McMartin, and James Bottomley were required to narrow down which bit of code could have this race condition. The symptom was interrupts stopped getting delivered while some workload was generating IO interrupts on two different CPUs. One of the interrupt sources would get masked off and stay unmasked. Problem was global_ack_eiem was accessed with read/modified/write sequence and not protected by a spinlock. PA-RISC doesn't need a global ack flag though. External Interrupts are _always_ delivered to a single CPU (except for "global broadcast interrupt" which AFAIK currently is not used.) So we don't have to worry about any given IRQ vector getting delivered to more than one CPU. Tested on a500 and rp34xx boxen. rsync to/from gsyprf11 (a500) would lock up the box since NIC (tg3) interrupt and SCSI (sym2) were on "opposite" CPUs (2 CPU system). Put them on the same CPU or apply this patch and 10GB of data would rsync completely. Please apply the following critical patch. thanks, grant Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Acked-by: Thibaut VARENE <T-Bone@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2007-05-08Add IRQF_IRQPOLL flag on pariscBernhard Walle
Add IRQF_IRQPOLL to the timer interrupt on parisc. Signed-off-by: Bernhard Walle <bwalle@suse.de> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Matthew Wilcox <willy@debian.org> Cc: Grant Grundler <grundler@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-17[PARISC] use fls_long in irq.cKyle McMartin
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2006-10-07[PARISC] Use set_irq_regsMatthew Wilcox
Actually set the irq_regs pointer. Signed-off-by: Matthew Wilcox <matthew@wil.cx>
2006-10-06Build fixes for struct pt_regs removalMatthew Wilcox
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
2006-10-04[PARISC] Allow nested interruptsJames Bottomley
Our prior mode of operation didn't allow nested interrupts because it makes the interrupt code much simpler. However, nested interrupts are better for latency. This code uses the EIEM register to simulate level interrupts and thus achieve nesting. Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2006-10-04[PARISC] Fix up parisc irq handling for genirq changesKyle McMartin
Clean up enough to get things compiling again in the interim. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2006-07-02[PATCH] irq-flags: PARISC: Use the new IRQF_ constantsThomas Gleixner
Use the new IRQF_ constants and remove the SA_INTERRUPT define Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-29[PATCH] genirq: add ->retrigger() irq op to consolidate hw_irq_resend()Ingo Molnar
Add ->retrigger() irq op to consolidate hw_irq_resend() implementations. (Most architectures had it defined to NOP anyway.) NOTE: ia64 needs testing. i386 and x86_64 tested. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-29[PATCH] genirq: cleanup: merge irq_affinity[] into irq_desc[]Ingo Molnar
Consolidation: remove the irq_affinity[NR_IRQS] array and move it into the irq_desc[NR_IRQS].affinity field. [akpm@osdl.org: sparc64 build fix] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-29[PATCH] genirq: rename desc->handler to desc->chipIngo Molnar
This patch-queue improves the generic IRQ layer to be truly generic, by adding various abstractions and features to it, without impacting existing functionality. While the queue can be best described as "fix and improve everything in the generic IRQ layer that we could think of", and thus it consists of many smaller features and lots of cleanups, the one feature that stands out most is the new 'irq chip' abstraction. The irq-chip abstraction is about describing and coding and IRQ controller driver by mapping its raw hardware capabilities [and quirks, if needed] in a straightforward way, without having to think about "IRQ flow" (level/edge/etc.) type of details. This stands in contrast with the current 'irq-type' model of genirq architectures, which 'mixes' raw hardware capabilities with 'flow' details. The patchset supports both types of irq controller designs at once, and converts i386 and x86_64 to the new irq-chip design. As a bonus side-effect of the irq-chip approach, chained interrupt controllers (master/slave PIC constructs, etc.) are now supported by design as well. The end result of this patchset intends to be simpler architecture-level code and more consolidation between architectures. We reused many bits of code and many concepts from Russell King's ARM IRQ layer, the merging of which was one of the motivations for this patchset. This patch: rename desc->handler to desc->chip. Originally i did not want to do this, because it's a big patch. But having both "desc->handler", "desc->handle_irq" and "action->handler" caused a large degree of confusion and made the code appear alot less clean than it truly is. I have also attempted a dual approach as well by introducing a desc->chip alias - but that just wasnt robust enough and broke frequently. So lets get over with this quickly. The conversion was done automatically via scripts and converts all the code in the kernel. This renaming patch is the first one amongst the patches, so that the remaining patches can stay flexible and can be merged and split up without having some big monolithic patch act as a merge barrier. [akpm@osdl.org: build fix] [akpm@osdl.org: another build fix] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-17[PARISC] Make redirecting irq messages less noisyRyan Bradetich
Make the "redirecting irq" message to not display on the console by setting the severity to KERN_DEBUG. The console was basically unusable. Signed-off-by: Ryan Bradetich <rbrad@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] irq_affinityp[] only available for SMP buildsGrant Grundler
irq_affinityp[] only available for SMP builds, make code that uses it conditional on CONFIG_SMP. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] Add IRQ affinitiesJames Bottomley
This really only adds them for the machines I can check SMP on, which is CPU interrupts and IOSAPIC (so not any of the GSC based machines). With this patch, irqbalanced can be used to maintain irq balancing. Unfortunately, irqbalanced is a bit x86 centric, so it doesn't do an incredibly good job, but it does work. Signed-off-by: James Bottomley <jejb@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] Fix uniprocessor build by dummying smp_send_all_nop()Kyle McMartin
Since irq.c uses smp_send_all_nop, we must define it for UP builds as well. Make it a static inline so it gets optimized away. This forces irq.c to include <asm/smp.h> though. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] Fix our interrupts not to use smp_call_functionJames Bottomley
Fix our interrupts not to use smp_call_function On K and D class smp, the generic code calls this under an irq spinlock, which causes the WARN_ON() message in smp_call_function() (and is also illegal because it could deadlock). The fix is to use a new scheme based on the IPI_NOP. Signed-off-by: James Bottomley <jejb@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] Disable nesting of interruptsGrant Grundler
Disable nesting of interrupts - still has holes The offending sequence starts out like this: 1) take external interrupt 2) set_eiem() to only allow TIMER_IRQ; local interrupts still disabled 3) read the EIRR to get a "list" of pending interrupts 4) clear EIRR of pending interrupts we intend to handle 5) call __do_IRQ() to handle IRQ. 6) handle_IRQ_event() enables local interrupts (I-Bit) 7) take a timer interrupt 8) read EIRR to get a new list of pending interrupts 9) clear EIRR of pending interrupts we just read 10) handle pending interrupts found in (8) 11) set_eiem(cpu_eiem) and return [ TROUBLE! all enabled CPU IRQs are unmasked. } 12) handle remaining interrupts pending from (3) e.g. call __do_IRQ() -> handle_IRQ_event()..etc [ TROUBLE! call to handle_IRQ_event() can now enable *any* IRQ. } 13) set_eiem(cpu_eiem) and return The problem is we now get into ugly race conditions with Timer and IPI interrupts at this point. I'm not exactly sure what happens when things go wrong (perhaps nest calls to IPI or timer interrupt?). But I'm certain it's not good. This sequence will break sooner if (10) would accidentally leave interrupts enabled. I'm pretty sure the right answer is now to make cpu_eiem a per CPU variable since all external interrupts on parisc are per CPU. This means we will NOT need to send an IPI to every CPU in the system when enabling or disabling an IRQ since only one CPU needs to change it's EIEM. Thanks to James Bottomley for (once again) pointing out the problem. Signed-off-by: Grant Grundler <grundler@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
2005-11-17[PARISC] Make sure timer and IPI execute with interrupts disabledJames Bottomley
Fix a longstanding smp bug The problem is that both the timer and ipi interrupts are being called with interrupts enabled, which isn't what anyone is expecting. The IPI issue has just started to show up by causing a BUG_ON in the slab debugging code. The timer issue never shows up because there's an eiem work around in our irq.c The fix is to label both these as SA_INTERRUPT which causes the generic irq code not to enable interrupts. I also suspect the smp_call_function timeouts we're seeing might be connected with the fact that we disable IPIs when handling any other type of interrupt. I've put a WARN_ON in the code for executing smp_call_function() with IPIs disabled. Signed-off-by: James Bottomley <jejb@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.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!