Menu
▾
▴
Re: [ACPI] Re: [RFC] ACPI IRQ proposal
|
From: MAEDA N. <mae...@jp...> - 2004-03-29 01:29:49
|
Hi, Kochi-san.
Thank you for your explanation of what may cause the problem.
As you guessed, the SCI of my machine is active-high, level interrupt.
I had to notice that the following kernel messages were printed.
tiger4 kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
tiger4 kernel: register_intr: changing vector 39 from IO-SAPIC-edge to IO-SAPIC-level
In order to make sure that the spurious interrupts were caused by this problem,
I have tried to simply change the 2nd argument of acpi_register_gsi() to
ACPI_ACTIVE_HIGH, and then the spurious interrupts are gone.
Thanks,
Naoaki Maeda
From: Takayoshi Kochi <t-...@bq...>
Subject: [ACPI] Re: [RFC] ACPI IRQ proposal
Date: Fri, 26 Mar 2004 17:56:30 +0900 (JST)
> Hi Maeda-san, Bjorn,
>
> Although the ACPI spec says that SCI is 'active-low, level' interrupt,
> there are many platforms that doesn't follow the rule (what I've seen
> are almost active-high, level). I think Maeda-san's case is just
> a wrong polarity.
>
> Usually those platforms would describe the polarity and trigger of
> SCI in 'interrupt source override' record in the ACPI MADT table.
>
> The polarity and trigger are programmed in iosapic when MADT
> parsing is done, so we don't want to force 'ACPI_ACTIVE_LOW,
> ACPI_LEVEL_SENSITIVE' when SCI is enabled.
>
> So maybe acpi_register_gsi() would take only one argument (u32 gsi)
> and the acpi_register_gsi() by itself will derive polarity and trigger
> from override table or iosapic_intr_info[]?
>
> From: MAEDA Naoaki <mae...@jp...>
> Subject: Re: [RFC] ACPI IRQ proposal
> Date: Fri, 26 Mar 2004 14:39:30 +0900 (JST)
>
> > 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 <bjo...@hp...>
> > 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?
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> > the body of a message to maj...@vg...
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acp...@li...
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
|