From: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>
To: bjorn.helgaas@hp.com
Cc: acpi-devel@lists.sourceforge.net, linux-ia64@vger.kernel.org,
maeda.naoaki@jp.fujitsu.com
Subject: Re: [RFC] ACPI IRQ proposal
Date: Fri, 26 Mar 2004 14:39:30 +0900 (JST) [thread overview]
Message-ID: <20040326.143930.41646618.maeda@jp.fujitsu.com> (raw)
In-Reply-To: <200403231537.14505.bjorn.helgaas@hp.com>
Hi, Bjorn.
I've tried your patch in tiger4, but it causes spurious acpi interrupts,
and finally the IRQ is disabled by note_interrupt().
I guess the difference causing this problem is your patch enables the acpi
interrupt on acpi_register_gsi() called by acpi_os_install_interrupt_handler(),
but original acpi_os_install_interrupt_handler() calls acpi_irq_to_vector(),
which does not enable the interrupt, instead.
I am not sure the reason, but probably the enabling timing is too early
for the acpi interrupt.
Didn't you hit this problem?
Thanks,
Naoaki Maeda
------- Original code
#if defined(CONFIG_IA64) || defined(CONFIG_PCI_USE_VECTOR)
irq = acpi_irq_to_vector(irq);
if (irq < 0) {
printk(KERN_ERR PREFIX "SCI (ACPI interrupt %d) not registered\n",
acpi_fadt.sci_int);
return AE_OK;
}
#endif
acpi_irq_handler = handler;
acpi_irq_context = context;
if (request_irq(irq, acpi_irq, SA_SHIRQ, "acpi", acpi_irq)) {
printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
return AE_NOT_ACQUIRED;
}
acpi_irq_irq = irq;
--------
-------- Patched code
irq = acpi_register_gsi(gsi, ACPI_ACTIVE_LOW, ACPI_LEVEL_SENSITIVE);
if (irq < 0) {
printk(KERN_ERR PREFIX "SCI (ACPI interrupt %d) not registered\n",
gsi);
return AE_OK;
}
acpi_irq_handler = handler;
acpi_irq_context = context;
if (request_irq(irq, acpi_irq, SA_SHIRQ, "acpi", acpi_irq)) {
printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
return AE_NOT_ACQUIRED;
}
--------
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: [RFC] ACPI IRQ proposal
Date: Tue, 23 Mar 2004 15:37:14 -0700
> I think the ACPI/platform interactions for IRQ setup are unnecessarily
> complex. Today we have:
>
> - boot-time parsing of all the _PRTs (platform subsys_initcall
> calls acpi_pci_irq_init(), which calls either mp_parse_prt()
> or iosapic_parse_prt() based on some #ifdefs).
>
> - pci_enable_device()-time IRQ enable (platform
> pcibios_enable_resources() calls acpi_pci_irq_enable(), which
> calls back to platform code, again based on some #ifdefs).
>
> By defining a new platform interface, we should be able to get rid of
> the boot-time _PRT parsing and do everything cleanly at
> pci_enable_device()-time:
>
> int /* Linux IRQ */
> acpi_register_gsi(int gsi,
> int polarity, /* active high or low */
> int trigger) /* edge or level */
>
> This is responsible for whatever APIC or IOSAPIC programming the
> platform needs, as well as allocating and returning a Linux IRQ.
>
> By doing this, we get
>
> - possibility of hot-plugging a PCI root bridge (w/ _PRT)
> - removal of architecture #ifdefs from pci_irq.c and osl.c
> - removal of some Linux IRQ junk from acpi/pci_irq.c
>
> If there are still some broken drivers that don't call pci_enable_device(),
> we still have the option of putting a hook somewhere that just calls
> acpi_pci_irq_enable() for all PCI devices.
>
> Sample patch below only cleans up ia64; i386 and x86_64 looks a
> little more complicated. Any comments?
next prev parent reply other threads:[~2004-03-26 5:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-23 22:37 [RFC] ACPI IRQ proposal Bjorn Helgaas
2004-03-23 22:59 ` David Mosberger
2004-03-26 5:39 ` MAEDA Naoaki [this message]
2004-03-26 8:56 ` Takayoshi Kochi
2004-03-27 0:00 ` Bjorn Helgaas
2004-03-29 1:24 ` [ACPI] " MAEDA Naoaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040326.143930.41646618.maeda@jp.fujitsu.com \
--to=maeda.naoaki@jp.fujitsu.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=bjorn.helgaas@hp.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox