[lkml]   [2012]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to "register" a GSI for a non PCI non ISA device
    On Thu, Jan 26, 2012 at 9:22 AM, Guillaume Knispel
    <> wrote:
    > On Thu, 26 Jan 2012 10:32:39 -0500
    > Konrad Rzeszutek Wilk <> 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 <> 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.


     \ /
      Last update: 2012-01-26 18:27    [W:0.026 / U:0.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site