user/sven/linux.git/kernel/irq/proc.c, branch v2.6.14.7

[PATCH] x86/x86_64: deferred handling of writes to /proc/irqxx/smp_affinity

2005-09-07T23:57:15Z

When handling writes to /proc/irq, current code is re-programming rte entries directly. This is not recommended and could potentially cause chipset's to lockup, or cause missing interrupts. CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the interrupt is pending. The same needs to be done for /proc/irq handling as well. Otherwise user space irq balancers are really not doing the right thing. - Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for lack of a generic name. - added move_irq out of IRQ_BALANCE, and added this same to X86_64 - Added new proc handler for write, so we can do deferred write at irq handling time. - Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead it now shows only active cpu masks, or exactly what was set. - Provided a common move_irq implementation, instead of duplicating when using generic irq framework. Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off. Tested UP builds as well. MSI testing: tbd: I have cards, need to look for a x-over cable, although I did test an earlier version of this patch. Will test in a couple days. Signed-off-by: Ashok Raj Acked-by: Zwane Mwaikambo Grudgingly-acked-by: Andi Kleen Signed-off-by: Coywolf Qi Hunt Signed-off-by: Ashok Raj Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix irq_affinity write from /proc for ia64

2005-03-28T11:55:27Z

Made GENERIC_HARDIRQ mechanism work for ia64 and CPU hotplug. When write to /proc/irq is handled it is not appropriate to perform set_rte immediatly, since there is a race when the interrupt is asserted while the re-program is happening. Hence such programming is only safe when we do the re-program at the time of servicing an interrupt. This got broken when GENERIC_HARDIRQ got introduced for ia64. - added CONFIG_PENDING_IRQ so default /proc/irq write handler can do the right thing. TBD: We currently dont handle redirectable hint either in the display, or when we handle writes to /proc/irq/XX/smp_affinity. We need an arch specific way to account for the presence of "r" hint when we handle the proc write. Signed-off-by: Ashok Raj Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] irq_affinity: fix build when CONFIG_PROC_FS=n

2005-02-02T00:30:31Z

Need 'irq_affinity' array when CONFIG_PROC_FS=n. With CONFIG_PROC_FS=n, the irq_affinity[NR_IRQS] array is not available in arch/i386/kernel code: arch/i386/kernel/built-in.o(.text+0x10037): In function `do_irq_balance': : undefined reference to `irq_affinity' arch/i386/kernel/built-in.o(.text+0x101a9): In function `do_irq_balance': : undefined reference to `irq_affinity' Signed-off-by: Randy Dunlap Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Allow multiple cpus in irq affinity call

2004-12-02T23:45:40Z

The generic irq affinity code limits us to a single cpu target regardless of what the architecture supports. If required this should be done in the architecture specific ->set_affinity call. With this patch ppc64 is able to select all cpus affinity again. Signed-off-by: Anton Blanchard Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Disable SW irqbalance/irqaffinity for E7520/E7320/E7525 v2

2004-10-18T16:02:26Z

As part of the workaround for the "Interrupt message re-ordering across hub interface" errata (page #16 in http://developer.intel.com/design/chipsets/specupdt/30288402.pdf), BIOS may enable hardware IRQ balancing for E7520/E7320/E7525(revision ID 0x9 and below) based platforms. Add pci quirks to disable SW irqbalance/affinity on those platforms. Move balanced_irq_init() to late_initcall so that kirqd will be started after pci quirks. Signed-off-by: Suresh Siddha Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] generic irq subsystem: core

2004-10-18T15:55:37Z

The main goal of this patch is to consolidate all the different but still fundamentally similar arch/*/kernel/irq.c code into the kernel/irq/ subsystem. There are 4 new files in the kernel/irq/ directory: - handle.c: core bits: __do_IRQ() and handle_IRQ_event(), callable from arch-specific irq.c code. - manage.c: the main driver apis - spurious.c: the handling of buggy interrupt sources. - autoprobe.c: probing of interrupts - older code but still in use. - proc.c: /proc/irq/ code. - internals.h for irq-core-internal interfaces not visible to drivers nor arch PIC code. An architecture enables the generic hardirq code by defining CONFIG_GENERIC_HARDIRQS in its arch Kconfig. People doing this conversion should check out the x86/x64/ppc/ppc64 patches for details - the conversion is quite straightforward but every converted function (i.e. every function removed from the arch irq.c) _must_ be matched to the generic version and if there is any detail that the generic code should do it has to be added to the generic code. All of the currently converted 4 architectures were converted like that, and the generic code was extended/fixed along the way. Other changes related to this patchset: - clean up the irq include files (linux/irq.h, linux/interrupt.h, linux/hardirq.h) and consolidate asm-*/[hard]irq.h. Note, to keep all non-touched architectures in an untouched state this consolidation is done carefully and strictly under CONFIG_GENERIC_HARDIRQS. Once the consolidation is done we can do a couple of final cleanups to reach the following logical splitup of 3 include files: linux/interrupt.h: driver-visible APIs and details linux/irq.h: core irq and arch-PIC code, internals asm-*/irq.h: arch PIC and irq delivery details the following include files will likely vanish: linux/hardirq.h merges into linux/irq.h asm-*/hardirq.h: merges into asm-*/irq.h asm-*/hw_irq.h: merges into asm-*/irq.h Christoph would like to do these once the current wave of cleanups gets in. Signed-off-by: Ingo Molnar Signed-off-by: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds