x86/sfi: fix ioapic gsi range
in [Kernel]
|
Prev: Fwd: EXT3 File System Corruption 2.6.34
Next: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Alan Cox on 8 Jun 2010 04:10 > > You may not use a 1-1 mapping if you don't have legacy irqs. Linux > > irqs 0-15 are the ISA irqs you may not use those irq numbers for Linux IRQ 0 is "no IRQ assigned", except buried in certain bits of arch specific historical knowledge. Also calling 1-15 ISA IRQ lines is also somewhat misleading given they are almost certainly routing for PCI devices. "PIC IRQ routing" maybe - but even that is not really true on a lot of PC hardware today except by convention. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 8 Jun 2010 14:20 On 06/08/2010 01:10 AM, Alan Cox wrote: >>> You may not use a 1-1 mapping if you don't have legacy irqs. Linux >>> irqs 0-15 are the ISA irqs you may not use those irq numbers for > > Linux IRQ 0 is "no IRQ assigned", except buried in certain bits of arch > specific historical knowledge. > > Also calling 1-15 ISA IRQ lines is also somewhat misleading given they > are almost certainly routing for PCI devices. "PIC IRQ routing" maybe - > but even that is not really true on a lot of PC hardware today except by > convention. Yes, but I gather IRQ/GSI 0 is an early-acquire primary timer on MRST on Moorestown just as on PC/AT... just a different one. Hence "special" in the same sort of way. I don't really care, personally, though. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 8 Jun 2010 15:50 jacob pan <jacob.jun.pan(a)linux.intel.com> writes: >> > Background: >> > In Moorestown/Medfield platforms, there is no legacy IRQs, all gsis >> > and irqs are one to one mapped, including those < 16. Specifically, >> > IRQ0 and IRQ1 are used for per-cpu timers. So without this patch, >> > IOAPIC pin to IRQ mapping is off by one. >> >> The patch looks mostly reasonable the comment is wrong. >> >> You may not use a 1-1 mapping if you don't have legacy irqs. Linux >> irqs 0-15 are the ISA irqs you may not use those irq numbers for >> something different on any architecture, but especially not on x86. >> The gsi numbers are firmware specific and you may treat however you >> want. > > [jacob pan] If we don't have ISA irqs, why can't we have gsi# = irq# > for the legacy IRQ range? On Moorestown, we are re-using legacy irqs. > e.g. > sh-4.0# cat /proc/interrupts > CPU0 CPU1 > 0: 1512 0 IO-APIC-edge apbt0 > 1: 0 1482 IO-APIC-edge apbt1 > 9: 0 0 IO-APIC-fasteoi dw_spi > 10: 0 0 IO-APIC-fasteoi mrst_i2c > 11: 0 0 IO-APIC-fasteoi mrst_i2c > 12: 0 0 IO-APIC-fasteoi mrst_i2c > 23: 0 0 IO-APIC-fasteoi intel_scu_ipc > 27: 21 0 IO-APIC-fasteoi At the ioapic and gsi level, and in your firmware interface reusing the numbers is fine. The issue is what acpi calls bus 0 irqs, and how drivers deal with them. We wind up having well know irqs: irqs 3 and 4 for serial ports, irq 7 for parallel ports. irqs 14, and 15 for ide. A bunch of these hardware devices we can get if someone connects up a lpc superio chip. Even if sfi is never implemented on a platform where that kind of hardware exists, the current sfi code is setup to coexist simultaneously in the kernel with all of the infrastructure of other platforms where those kinds of devices exist. Which means there can be drivers compiled into your kernel that make assumptions about special properties of the irqs 0-15. I have seen a lot of weird hard to track issues, because of a conflict in assumptions over the ISA irqs. It is easiest and safest just to let the first 16 linux irq numbers be reserved for the legacy oddness, so code can make assumptions and we don't have to worry about it. As for the question about using legacy_pic to detect the absence of an irq controller that Peter raised. We can't do that because it should be possible for an acpi system with all of the legacy hardware to exist without needing to implement an i8259, or ever run in the historical interrupt delivery mode of pcs. With the current code you should get all of the remapping of the gsi's out of the legacy irq space without needing to lift a finger, and if someone later decides we need an irq override so we can have an isa irq present on a weird embedded system on a chip the code will be able to handle that easily. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 8 Jun 2010 16:10 "H. Peter Anvin" <hpa(a)zytor.com> writes: > On 06/08/2010 01:10 AM, Alan Cox wrote: >>>> You may not use a 1-1 mapping if you don't have legacy irqs. Linux >>>> irqs 0-15 are the ISA irqs you may not use those irq numbers for >> >> Linux IRQ 0 is "no IRQ assigned", except buried in certain bits of arch >> specific historical knowledge. >> >> Also calling 1-15 ISA IRQ lines is also somewhat misleading given they >> are almost certainly routing for PCI devices. "PIC IRQ routing" maybe - >> but even that is not really true on a lot of PC hardware today except by >> convention. > > Yes, but I gather IRQ/GSI 0 is an early-acquire primary timer on MRST on > Moorestown just as on PC/AT... just a different one. Hence "special" in > the same sort of way. I don't really care, personally, though. Right. I have to admit I was stunned when I realized that request_irq works and has worked for a long time with irq 0. I think that might actually be a bug. setup_irq is traditionally used for irq 0. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 8 Jun 2010 16:10
> The issue is what acpi calls bus 0 irqs, and how drivers deal with > them. We wind up having well know irqs: irqs 3 and 4 for serial > ports, irq 7 for parallel ports. irqs 14, and 15 for ide. Only we don't. IRQ 3/4 for serial is not true on many boxes today that have serial - in fact its been iffy since about the Thinkpad 600 ! IRQ 7 for parallel is rarely used (and in fact we usually poll) IRQ 14/15 is wrong for ATA today as its AHCI based on modern boxes And all the drivers you list are *cross platform* already. > A bunch of these hardware devices we can get if someone connects up a > lpc superio chip. To an x86 PC class system using some very traditional (and no longer valid) bits of behaviour. > Even if sfi is never implemented on a platform where that kind of > hardware exists, the current sfi code is setup to coexist > simultaneously in the kernel with all of the infrastructure of other > platforms where those kinds of devices exist. Which means there can > be drivers compiled into your kernel that make assumptions about > special properties of the irqs 0-15. That would be a driver bug. It would be bite other systems beyond the legacy PC. In the PC world its been unsafe since PnP BIOS let alone ACPI. > With the current code you should get all of the remapping of the > gsi's out of the legacy irq space without needing to lift a finger, > and if someone later decides we need an irq override so we can have > an isa irq present on a weird embedded system on a chip the code will > be able to handle that easily. There is only one reason to care about this - that is ISA bus devices with software IRQ steering registers for the ISA lines. Now that might just about be a real reason, but as former maintainer of both serial and IDE (and part time fixer of parport) I'd say the other reasons are bunkum. Alan -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |