Re: How to "register" a GSI for a non PCI non ISA device

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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@oracle.com> 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@kernel.org> 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.