- 14 8月, 2007 1 次提交
-
-
由 Kenji Kaneshige 提交于
Add base support for implementing platform_irq_to_vector(), and then use it on SN2. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Acked-by: NJohn Keller <jpk@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 18 7月, 2007 3 次提交
-
-
由 Yasuaki Ishimatsu 提交于
Add support for IRQ migration across vector domain. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Yasuaki Ishimatsu 提交于
Add fundamental support for multiple vector domain. There still exists only one vector domain even with this patch. IRQ migration across domain is not supported yet by this patch. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Yasuaki Ishimatsu 提交于
Add mapping tables between irqs and vectors, and its management code. This is necessary for supporting multiple vector domain because 1:1 mapping between irq and vector will be changed to n:1. The irq == vector relationship between irqs and vectors is explicitly remained for percpu interrupts, platform interrupts, isa IRQs and vectors assigned using assign_irq_vector() because some programs might depend on it. And I should consider the following problem. When pci drivers enabled/disabled devices dynamically, its irq number is changed to the different one. Therefore, suspend/resume code may happen problem. To fix this problem, I bound gsi to irq. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 09 5月, 2007 1 次提交
-
-
由 Jack Steiner 提交于
This patch adds an optional method for purging the TLB on SN IA64 systems. The change should not affect any non-SN system. Signed-off-by: NJack Steiner <steiner@sgi.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 30 6月, 2006 1 次提交
-
-
由 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: NIngo Molnar <mingo@elte.hu> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 22 6月, 2006 1 次提交
-
-
由 Mark Maule 提交于
Abstract IA64_FIRST_DEVICE_VECTOR/IA64_LAST_DEVICE_VECTOR since SN platforms use a subset of the IA64 range. Implement this by making the above macros global variables which the platform can override in it setup code. Also add a reserve_irq_vector() routine used by SN to mark a vector's as in-use when that weren't allocated through assign_irq_vector(). Signed-off-by: NMark Maule <maule@sgi.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 08 9月, 2005 1 次提交
-
-
由 Ashok Raj 提交于
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: NAshok Raj <ashok.raj@intel.com> Acked-by: NZwane Mwaikambo <zwane@holomorphy.com> Grudgingly-acked-by: NAndi Kleen <ak@muc.de> Signed-off-by: NCoywolf Qi Hunt <coywolf@lovecn.org> Signed-off-by: NAshok Raj <ashok.raj@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 12 7月, 2005 1 次提交
-
-
由 Kenji Kaneshige 提交于
Current assign_irq_vector() will panic if interrupt vectors is running out. But I think how to handle the case of lack of interrupt vectors should be handled by the caller of this function. For example, some PCI devices can raise the interrupt signal via both MSI and I/O APIC. So even if the driver for these device fails to allocate a vector for MSI, the driver still has a chance to use I/O APIC based interrupt. But currently there is no chance for these driver to use I/O APIC based interrupt because kernel will panic when assign_irq_vector() fails to allocate interrupt vector. The following patch changes assign_irq_vector() for ia64 to return -ENOSPC on error instead of panic (as i386 and x86_64 versions do). Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 26 4月, 2005 1 次提交
-
-
由 Kenji Kaneshige 提交于
Current ia64 linux cannot handle greater than 184 interrupt sources because of the lack of vectors. The following patch enables ia64 linux to handle greater than 184 interrupt sources by allowing the same vector number to be shared by multiple IOSAPIC's RTEs. The design of this patch is besed on "Intel(R) Itanium(R) Processor Family Interrupt Architecture Guide". Even if you don't have a large I/O system, you can see the behavior of vector sharing by changing IOSAPIC_LAST_DEVICE_VECTOR to fewer value. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-