From: Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Cc: acpi-dev
<acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
Krzysztof Oledzki <olel-gcSpNFQc7Gg@public.gmane.org>,
ambx1-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org
Subject: Re: PNP device interrupt type?
Date: Thu, 22 Sep 2005 08:55:51 +0800 [thread overview]
Message-ID: <1127350552.3961.11.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <200509210916.51581.bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Hi,
Sorry, I wrongly cc-ed the maillist address in previous email.
On Wed, 2005-09-21 at 23:16 +0800, Bjorn Helgaas wrote:
> On Wednesday 21 September 2005 8:59 am, Krzysztof Oledzki wrote:
> > On Wed, 21 Sep 2005, Bjorn Helgaas wrote:
> >
> > > On Tuesday 20 September 2005 7:32 pm, Li, Shaohua wrote:
> > >> Is it possible PNP devices use level trigger interrupt?
> > >> IIRC, PNP devices always use edge trigger interrupt under x86,
> > >> how about the IA64 case?
> > >
> > > I'm not aware of any reason why ACPI devices should always
> > > be edge triggered on ia64.
> > >
> > >> If PNP devices always use edge trigger
> > >> interrupt,
> > >> we might ignore BIOS setting.
> > >> We have a bug BIOS assign wrong interrupt info to RTC
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=5243
> > >
> > > ACPI can describe any combination of edge/level, high/low,
> > > so I think it would be a bad idea to throw away the information
> > > the firmware is giving us.
> > >
> > > We might have to figure out ways to work around firmware
> > > defects. But that seems better to me than just ignoring
> > > what the firmware tells us. That will lead to situations
> > > where the hardware and firmware are perfectly legal and
> > > correct, but Linux doesn't work (i.e., the hardware uses
> > > level triggered interrupts for some device, and Linux ignores
> > > that and treats it as edge-triggered).
> >
> > As far as i understand question, it was not about *ALL* ACPI devices
> but
> > only about PNP ones.
>
> What is the difference between a "PNP" ACPI device and a "non-PNP"
> ACPI device? It looks to me like PNPACPI will expose all ACPI
> devices as PNP devices (with a couple exceptions, like things that
> don't have any _CRS method).
>
> > And IMO the real problem is only RTC on x86 so the
> > workaround can only force this type of interrupt.
>
> Any workaround should be applied as narrowly as possible, to
> minimize the chance of breaking a platform that legitimately
> chooses to use a level-triggered interrupt. If there's a
> spec or convention that requires RTC to be edge-triggered
> on x86, I don't object to reflecting that in the code somehow.
Ok, maybe we could do this workaround for x86 and report a warning.
Let's see if it breaks anything.
Thanks,
Shaohua
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
next parent reply other threads:[~2005-09-22 0:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200509210916.51581.bjorn.helgaas@hp.com>
[not found] ` <200509210916.51581.bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
2005-09-22 0:55 ` Shaohua Li [this message]
[not found] ` <1127350552.3961.11.camel-ECwVeV2eNyQD0+JXs3kMbRL4W9x8LtSr@public.gmane.org>
2005-10-01 19:44 ` PNP device interrupt type? Krzysztof Oledzki
[not found] ` <Pine.LNX.4.62.0510012142300.11416-2hlNpRK6mjE3b3fIMdp3XWZHpeb/A1Y/@public.gmane.org>
2005-10-10 1:49 ` Shaohua Li
[not found] ` <1128908977.3955.1.camel-ECwVeV2eNyQD0+JXs3kMbRL4W9x8LtSr@public.gmane.org>
2005-10-10 12:04 ` Krzysztof Oledzki
2005-10-20 12:28 ` Krzysztof Oledzki
2005-11-17 16:45 ` Krzysztof Oledzki
2005-10-11 1:15 Li, Shaohua
2005-10-11 8:26 ` Krzysztof Oledzki
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=1127350552.3961.11.camel@linux-hp.sh.intel.com \
--to=shaohua.li-ral2jqcrhueavxtiumwx3w@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=ambx1-IBH0VoN/3vPQT0dZR+AlfA@public.gmane.org \
--cc=bjorn.helgaas-VXdhtT5mjnY@public.gmane.org \
--cc=olel-gcSpNFQc7Gg@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