On Wed, 25 Jan 2012 00:56:53 -0500 Len Brown <lenb@xxxxxxxxxx> wrote: > On 01/24/2012 12:42 PM, Guillaume Knispel wrote: > > > Hi, > > > > I'm building a PC platform with additional non-PCI and non-ISA devices: > > they are basically simple telecom chipsets connected to an SPI and an > > old school parallel bus (Intel LEB bus) and GPIO pins that can be used > > as interrupts through the IO APIC which exposes 40 GSI. From the point > > of view of the software the SPI, LEB, and GPIO are provided by PCI > > devices (in reality they are embedded controllers in an Intel SoC > > 80579). Anyway I'm not sure the additional GSI are described anywhere > > in whatever black magic ACPI / legacy BIOS table they could be > > (but I've complete control over the FW, so I can had whatever is > > needed when I know it). > > What is the benefit of implementing ACPI on this custom system? For our short term project it seems to be more a necessity than a benefit. ACPI is supported by the SoC, tables are already largely provided by Coreboot, the whole x86 ecosystem including Linux is more or less based around ACPI, and my whole interrogation comes from the fact that *acpi*_register_gsi() seems to be necessary to configure a GSI in the APIC but is not exported anymore, so my guess is that if I can't call it explicitly from my LKM, there should better be a way to make it be called when an ACPI thing is done, or maybe a legacy table parsed. As we first target an unmodified (if possible) 2.6.32 kernel from Debian Squeeze, I can't just re-export acpi_register_gsi() and call it a day. (If I've no other choice I'll obviously do it, but this would be quite bad for future maintenance). Now if we consider the long term / big picture and ask ourselves what is the benefit of ACPI for x86 systems with completely free designs and running exclusively free operating systems, I consider it more as a huge hindrance than as a benefit... Who understands that mess to begin with? If people dedicated at building only COTS motherboards with proprietary designs and BIOSes don't get it and repetitively make buggy DSDT, I doubt than I or other people building complete free systems with hugely limited resources would do very much better. But to leverage major Linux distributions that kind of hardware platform builders can be inclined to target existing kernels, so if there is no pre-built alternative in them the whole ACPI stack will continue to be used. So I'm both looking for pointers to how to configure custom GSI in existing kernels and if I need to do that through ACPI I'm also interested in pointers to alternatives in Linux on x86 systems where we could put that kind of description of the hardware platform in future kernels (device-tree maybe?), because we are very interested in contributing upstream to try to make our life easier for our next products using a modern kernel. -- Guillaume Knispel Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
