On Thu, Jan 26, 2012 at 9:22 AM, Guillaume Knispel <gknispel@xxxxxxxxxxxxxxxxx> wrote: > On Thu, 26 Jan 2012 10:32:39 -0500 > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > >> 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: >> > > >> > > > 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)? > > Sorry if I was unclear, I'll try to make things more explicit. > > We build the platform which obviously differs a little from a PC (but > just because of the presence of those additional non-ISA non-PCI > devices), but as far as software is concerned we are trying to make the > system run with a standard unmodified Linux kernel already built by > Debian (because rebuilding our own would shift the maintenance of > that kernel on us instead of Debian, and we would not be good at that) > > So what we can act on are the LKM and the system firmware, but not the > bzImage. > > The problem I'm facing is that I don't know how to setup a GSI, what > used to be done by directly calling acpi_register_gsi(), which was > possible from an LKM when it was exported (for example in 2.6.18, > which was the kernel used by Intel for their dev board). A driver should never need to use acpi_register_gsi() directly. It sounds like you have a non-PCI device that would be described as an ACPI device in the DSDT. In the Device definition, you include a _CRS method that tells the kernel what GSI it is using. The PNPACPI subsystem will parse _CRS and should do the acpi_register_gsi() for you. Then your driver would use pnp_register_driver() and pnp_irq() to learn the IRQ. drivers/tty/serial/8250_pnp.c is an example. Bjorn -- 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
