public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
Cc: ACPI Developers
	<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
	linux-acpi <linux-acpi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: eisa_set_level_irq(acpi_fadt.sci_int)
Date: 22 Oct 2003 00:25:11 -0400	[thread overview]
Message-ID: <1066796711.2593.30.camel@dhcppc4> (raw)
In-Reply-To: <1066411716.2527.100.camel-D2Zvc0uNKG8@public.gmane.org>

Ducrot,
I've found at least 1 system where hardcoding the PIC SCI to
Level-Triggered fails, while leaving it as Edge Triggered succeeds.

The Intel SE7505VB2 "Vero Beach" when booted with "noapic" leaves IRQ9
as edge triggered.

When we force it to level triggered, we get no ACPI events.
If we leave it as edge triggered, we do get ACPI events.

The other systems in my office leave the PIC SCI in Level Triggered
mode, so Linux need do nothing to the trigger.

Today's patch prints a warning when the mode changes:

                printk(KERN_WARNING PREFIX "IRQ %d was Edge Triggered, "
                        "setting to Level Triggerd\n", irq);

But I'm thinking that by default we should _not_ change the trigger.
Instead we should do so only upon, say acpi=sci_level_trigger or some
such.  If there is a popular model that leaves SCI as edge and requires
level to work, then we can use DMI to set this param for it.

thanks,
-Len

On Fri, 2003-10-17 at 13:28, Len Brown wrote:
> On Fri, 2003-10-17 at 11:41, Ducrot Bruno wrote:
> > On Wed, Oct 15, 2003 at 05:48:04PM -0400, Len Brown wrote:
> > > What does eisa_set_level_irq() do for us?
> > > 
> > > As its presence breaks the !CONFIG_PCI build, I deleted it and found
> > > that ACPI in PIC mode seems to work just fine without it (at least on 2
> > > of 2 systems tested so far)
> > > 
> > 
> > This ensure SCI interrupt is correctly initialized for (poorly) written
> > BIOS.  Without it, this break one of my laptop, and certainly others as well.
> 
> Do ACPI interrupt work on this latop?  What happens on that system if
> you delete the call to eisa_set_level_irq()?
> 
> If we blindly program the PIC to be level senstive when the hardware is
> designed to be edge triggered, then we'll probably get no ACPI events on
> those systems, as the pulse may not be asserted long enough to provoke
> an interrupt.
> 
> We used to blindly program the APIC assuming the SCI was ACPI compliant,
> but we got burnt when we discovered that a significant set of system do
> _not_ have a level-triggered active-low SCI.  Most of those specified
> their deviation with an SCI-over-ride in the MADT, but some did not:
> http://bugzilla.kernel.org/show_bug.cgi?id=774
> 
> The APIC solution was to
> 1. don't hard-code level-triggered active-low
> 2. do whatever the SCI over-ride says
> 3. if no SCI over-ride, leave the interrupt trigger/polarity as the BIOS
> programmed it.
> 
> thanks,
> -Len
> 
> ps. this routine is mis-named, it it not EISA specific.  Further, it is
> mis-located in a PCI-specific file but is not PCI specific.  It should
> be in an X86 specific interrupt file and be named pic_something.  I'm
> thinking I'll clone it into our x86 acpi code and add a warning when we
> find that it actually _changes_ the polarity.
> 
> 
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54

  parent reply	other threads:[~2003-10-22  4:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-15 21:48 eisa_set_level_irq(acpi_fadt.sci_int) Len Brown
     [not found] ` <1066254483.2535.51.camel-D2Zvc0uNKG8@public.gmane.org>
2003-10-17 15:41   ` eisa_set_level_irq(acpi_fadt.sci_int) Ducrot Bruno
     [not found]     ` <20031017154107.GI8668-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2003-10-17 17:28       ` eisa_set_level_irq(acpi_fadt.sci_int) Len Brown
     [not found]         ` <1066411716.2527.100.camel-D2Zvc0uNKG8@public.gmane.org>
2003-10-22  4:25           ` Len Brown [this message]
     [not found]             ` <1066796711.2593.30.camel-D2Zvc0uNKG8@public.gmane.org>
2003-10-24  2:54               ` eisa_set_level_irq(acpi_fadt.sci_int) Sérgio Monteiro Basto
     [not found]                 ` <1066964092.1541.16.camel-4/PLUo9XfK/yXfm4dIG/yWZHpeb/A1Y/@public.gmane.org>
2003-10-24  3:13                   ` eisa_set_level_irq(acpi_fadt.sci_int) Len Brown
     [not found]                     ` <1066965206.3864.55.camel-D2Zvc0uNKG8@public.gmane.org>
2003-10-24  4:19                       ` eisa_set_level_irq(acpi_fadt.sci_int) Sérgio Monteiro Basto
     [not found]                         ` <1066969171.1608.32.camel-4/PLUo9XfK/yXfm4dIG/yWZHpeb/A1Y/@public.gmane.org>
2003-10-24  6:07                           ` eisa_set_level_irq(acpi_fadt.sci_int) Len Brown
     [not found]                             ` <1066975669.3861.84.camel-D2Zvc0uNKG8@public.gmane.org>
2003-10-24 20:03                               ` eisa_set_level_irq(acpi_fadt.sci_int) Sérgio Monteiro Basto
2003-10-25  1:50                               ` eisa_set_level_irq(acpi_fadt.sci_int) Sérgio Monteiro Basto
     [not found]                                 ` <1067046644.2219.9.camel-4/PLUo9XfK/yXfm4dIG/yWZHpeb/A1Y/@public.gmane.org>
2003-10-27 13:30                                   ` eisa_set_level_irq(acpi_fadt.sci_int) Ducrot Bruno
2003-10-24 13:12                           ` eisa_set_level_irq(acpi_fadt.sci_int) Ducrot Bruno
  -- strict thread matches above, loose matches on Subject: below --
2003-10-15 22:09 eisa_set_level_irq(acpi_fadt.sci_int) Grover, Andrew
     [not found] ` <F760B14C9561B941B89469F59BA3A8470255EF51-sBd4vmA9Se4Lll3ZsUKC9FDQ4js95KgL@public.gmane.org>
2003-10-17 10:39   ` eisa_set_level_irq(acpi_fadt.sci_int) Arndt Schoenewald

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=1066796711.2593.30.camel@dhcppc4 \
    --to=len.brown-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org \
    --cc=linux-acpi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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