summaryrefslogtreecommitdiffstats
path: root/arch/ia64/kernel/iosapic.c
Commit message (Collapse)AuthorAgeFilesLines
* [IA64] Manual merge fix for 3 filesTony Luck2005-09-081-8/+14
|\ | | | | | | | | | | | | | | arch/ia64/Kconfig arch/ia64/kernel/acpi.c include/asm-ia64/irq.h Signed-off-by: Tony Luck <tony.luck@intel.com>
| * [ACPI] fix ia64 build issues resulting from Lindent and mergeMAEDA Naoaki2005-08-161-2/+2
| | | | | | | | | | | | Signed-off-by: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Brown, Len <len.brown@intel.com>
| * [ACPI] Merge acpi-2.6.12 branch into 2.6.13-rc3Len Brown2005-08-051-9/+15
| |\ | | | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| | * [ACPI] iosapic_register_intr() now returns error instead of panicKenji Kaneshige2005-08-051-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | error condition is passed along by acpi_register_gsi(). Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
* | | [IA64] Minor cleanups - remove CONFIG_ACPI_DEALLOCATE_IRQKenji Kaneshige2005-09-071-2/+0Star
|/ / | | | | | | | | | | | | | | The config option 'CONFIG_ACPI_DEALLOCATE_IRQ' is no longer needed. This patch removes it. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | [IA64] assign_irq_vector() should not panicKenji Kaneshige2005-07-111-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* | [PATCH] ACPI based I/O APIC hot-plug: ia64 supportKenji Kaneshige2005-06-281-21/+113
|/ | | | | | | | | This is an ia64 implementation of acpi_register_ioapic() and acpi_unregister_ioapic() interfaces. Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [IA64] iosapic.c: typo ... s/spin_unlock_irq/spin_unlock/Kenji Kaneshige2005-04-251-1/+1
| | | | | | | vector sharing patch had a typo ... mismatched spin_lock() with a spin_unlock_irq(). Fix from Kenji Kaneshige. Signed-off-by: Tony Luck <tony.luck@intel.com>
* [IA64] vector sharing (Large I/O system support)Kenji Kaneshige2005-04-251-86/+272
| | | | | | | | | | | | | | | 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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
* Linux-2.6.12-rc2Linus Torvalds2005-04-171-0/+827
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!