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

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

[Guillaume Knispel]

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).

But as my devices are neither PCI nor ISA, I don't know how i can get
access to the custom GSI interrupt from a LKM. acpi_register_gsi() used
to be exported but is not anymore and I guess this is mandatory that
this function is called to prepare internal structures (maybe irq_desc)
and most importantly to configure to level triggering active low.

So I'm thinking about writing black magic DSDT stuffs or whatever,
which i might be able to sort of do after reading the fabulous ACPI
specifications. Any feedback or pointer would be highly welcome.

BTW when Linux devs says that bios writers are writing shit, yeah, they
do, and given the state of complexity of the PC platform, I'm at the
risk to do it too because I'm not supposed to delay the production of
our system by one additional year just to completely learn how the
shitty PC "standards" are supposed to work. From a more personal
point of view when I'm reading the ACPI or other related specs tainted
by MS and their desire to put GUID everywhere and other terrible ideas,
I would rather prefer being high to not endure that much pain.

As more and more x86 systems are directly designed to run Linux and
only tested with it, with some of those (like our own) being built
by people having complete control on the board and firmware (Coreboot),
maybe it is time to define a legacy-free variant of the x86 plateform
(especially on the FW/OS interface) for the free software and free
hardware design world, so that we aren't restricted and slowed down by
retro-compatible technologies dedicated at running MS-DOS and created
with the explicit goal to be hard to use for anything else than
Windows NT.

Cheers!
-- 
Guillaume Knispel
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux

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

[Len Brown]

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?

-Len

> But as my devices are neither PCI nor ISA, I don't know how i can get
> access to the custom GSI interrupt from a LKM. acpi_register_gsi() used
> to be exported but is not anymore and I guess this is mandatory that
> this function is called to prepare internal structures (maybe irq_desc)
> and most importantly to configure to level triggering active low.
> 
> So I'm thinking about writing black magic DSDT stuffs or whatever,
> which i might be able to sort of do after reading the fabulous ACPI
> specifications. Any feedback or pointer would be highly welcome.
> 
> BTW when Linux devs says that bios writers are writing shit, yeah, they
> do, and given the state of complexity of the PC platform, I'm at the
> risk to do it too because I'm not supposed to delay the production of
> our system by one additional year just to completely learn how the
> shitty PC "standards" are supposed to work. From a more personal
> point of view when I'm reading the ACPI or other related specs tainted
> by MS and their desire to put GUID everywhere and other terrible ideas,
> I would rather prefer being high to not endure that much pain.
> 
> As more and more x86 systems are directly designed to run Linux and
> only tested with it, with some of those (like our own) being built
> by people having complete control on the board and firmware (Coreboot),
> maybe it is time to define a legacy-free variant of the x86 plateform
> (especially on the FW/OS interface) for the free software and free
> hardware design world, so that we aren't restricted and slowed down by
> retro-compatible technologies dedicated at running MS-DOS and created
> with the explicit goal to be hard to use for anything else than
> Windows NT.
> 
> Cheers!

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

[Guillaume Knispel]

On Wed, 25 Jan 2012 00:56:53 -0500
Len Brown <lenb@kernel.org> 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

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

[Konrad Rzeszutek Wilk]

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:
> 
> > 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

Hm, isn't it __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
> 
> 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?

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

[Guillaume Knispel]

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
from mainline x86, compiled built-in? My goal is to only touch LKM and
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 :)

-- 
Guillaume Knispel
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux

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

[Konrad Rzeszutek Wilk]

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.

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

[Guillaume Knispel]

On Thu, 26 Jan 2012 10:32:39 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@oracle.com> 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).

Because acpi_register_gsi() is not exported anymore, I'm trying to find
a way to make it be called during system startup. My current best guess
is that if I write the right magic spell somewhere in the DSDT or maybe
a kind of legacy BIOS table, the acpi_register_gsi() will be called
during the boot and will configure the GSI with the desired level
triggering, so that the LKM will just have to request_irq() (but on
which irq number? same as gsi number?) and everything will work fine.

I don't think I've to replace acpi_register_gsi() by my own
implementation; the GSI in question is a standard one on the only
IO APIC in the system. So everything looks pretty simple. The only
question is how to make use of that GSI from the software side,
first how to configure it to level trigger active low, then how to
request it from a LKM given that the LKM in question does not drive
a PCI device that makes use of the interrupt we want.

The simplified architecture is the following:

 Intel 80579 System on Chip                | External chip
                                           |
+----------+            +-----+            |  +---------+
| CPU + NB |--- PCI ----| LEB |--- // bus ----| telecom |
+----------+            +-----+            |  |  chip   |
     |                                     |  +---------+
 +--------+                                |   |
 | IOAPIC |----------------- GSI 32 -----------+
 +--------+                                |

The LKM will register as a driver for the PCI enumerable LEB then use
it to drive the telecom chip. GSI 32 is unrelated to the LEB.

> 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.

-- 
Guillaume Knispel
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux

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

[Bjorn Helgaas]

On Thu, Jan 26, 2012 at 9:22 AM, Guillaume Knispel
<gknispel@proformatique.com> wrote:
> On Thu, 26 Jan 2012 10:32:39 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@oracle.com> 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

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

[Guillaume Knispel]

On Thu, 26 Jan 2012 10:24:31 -0700
Bjorn Helgaas <bhelgaas@google.com> wrote:

> 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.

Thanks a lot, I'll look into it.

-- 
Guillaume Knispel
Avencall - 10 bis, rue Lucien Voilin - 92800 Puteaux