On Thu, Jan 26, 2012 at 04:07:19PM +0100, Guillaume Knispel wrote: > On Wed, 25 Jan 2012 14:02:14 -0500 > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > > > On Wed, Jan 25, 2012 at 06:23:14PM +0100, Guillaume Knispel wrote: > > > On Wed, 25 Jan 2012 00:56:53 -0500 > > > Len Brown <lenb@xxxxxxxxxx> wrote: > > > > > > > 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 > > > > Hm, isn't it __acpi_register_gsi? > > __acpi_register_gsi exists on recent kernels, it is the pointer to > the underlying implementation of that function depending on the > platform (x86 / xen-x86) and on the variant of the platform (pic/apic). > acpi_register_gsi still exists and it calls __acpi_register_gsi. > > > > 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. > > > > Can you do it the way xen does? Look in arch/x86/xen/pci.c > > Did not found this file. Besides, isn't Xen a separate architecture Duh! I meant arch/x86/pci/xen.c > from mainline x86, compiled built-in? My goal is to only touch LKM and Not anymore. It is dynamically on if the kernel detects its running under the hypervisor. I am still unclear what you are trying to do. Is it that you have _PRT ACPI tables and your want to have your module be called when those are parsed? If so, then __acpi_register_gsi is your guy - and you can over-write it to your platform. Granted at that point that function parameter should be guarded by some form of locking. Perhaps provide a acpi_register_gsi_fnc() that can be exported out. Would that work for you (I can cook up a patch for that)? But this a bit complicated by the fact that ACPI parsing is done early in the bootup processes - so your module should be compiled in - otherwise you might miss the the 'request_irq' calls done by drivers that are done _before_ your module is loaded. Unless you want to re-trigger the ACPI _PRT parsing and call your module once more for all interrupts? But that would imply unload all existing modules, then reload them once more.. Or is it that you just want to set the APIC parameters differently? Wouldn't then the be better of implementing an ' struct apic ' which would have most, of them set to the existing (apic_physflat) and just over-write the ones you really care about - like write and read? > system firmware if necessary. > > > > 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). > > > > Oh wow. That is ancient. 3.2? > > 3.2 when a Debian stable will feature 3.2 :) Ah OK. -- 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
