From: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>
To: "Yu, Luming" <luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>,
"Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Moore,
Robert" <robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Fu,
Michael" <michael.fu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Re: [PATCH] Teach OSL to handle multiple interrupts [1/2]
Date: Sat, 20 Nov 2004 03:32:40 +0000 [thread overview]
Message-ID: <20041120033240.GJ1108@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC098@pdsmsx403>
On Fri, Nov 19, 2004 at 12:41:54AM +0800, Yu, Luming wrote:
> 1. Current ACPI CA seems to have defect when handling
> case if there have duplicate GPE interrupt level.
> It's due to all acpi_gpe_xrupt_info
> are hooked onto a global list of acpi_gbl_gpe_xrupt_list_head.
> And, if found a duplicate interrupt, the old acpi_gpe_xrupt_info
> will be override by new one, Please take a look at
> acpi_ev_get_gpe_xrupt_block. So you patch need to avoid
> duplication of GPE interrupt level at this moment.
> I'm not sure if this limitation is NOT ACPI CA 's bug. ( I will figure
> it out)
I think this is just a misreading. There's one acpi_gpe_xrupt_info per
interrupt. There can be multiple gpe blocks per acpi_gpe_xrupt_info.
See acpi_ev_install_gpe_block():
gpe_xrupt_block = acpi_ev_get_gpe_xrupt_block (interrupt_level);
acpi_os_acquire_lock (acpi_gbl_gpe_lock, ACPI_NOT_ISR);
if (gpe_xrupt_block->gpe_block_list_head) {
next_gpe_block = gpe_xrupt_block->gpe_block_list_head;
while (next_gpe_block->next) {
next_gpe_block = next_gpe_block->next;
}
next_gpe_block->next = gpe_block;
gpe_block->previous = next_gpe_block;
}
else {
gpe_xrupt_block->gpe_block_list_head = gpe_block;
}
> 2. Due to the global list of acpi_gbl_gpe_xrupt_list_head,
> All GPEs will be checked at each GPE interrupt level,
> This is not the expected behaviour of just checking GPE at GPE's
> interrupt
> level.
I think this misunderstanding follows from the above misunderstanding.
> 3. Interrupt Source Overrides are necessary to describe variances
> between the IA-PC standard dual 8259 interrupt definition and the
> platform's implementation.
>
> Please take a look at ACPI SPEC
> 5.2.11.8 Interrupt Source Overrides
OK, but that doesn't explain why we have two copies of the FADT. Or,
for that matter, why we only override SCI INT in one copy of the FADT
and not the other.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
next prev parent reply other threads:[~2004-11-20 3:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-18 16:41 Re: [PATCH] Teach OSL to handle multiple interrupts [1/2] Yu, Luming
2004-11-20 3:32 ` Matthew Wilcox [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-11-21 17:08 Yu, Luming
2004-11-18 16:21 Yu, Luming
2004-11-17 2:27 Yu, Luming
2004-11-17 20:49 ` Matthew Wilcox
2004-11-16 17:57 Yu, Luming
2004-11-16 17:49 Yu, Luming
2004-11-12 17:28 Yu, Luming
2004-11-16 3:22 ` Matthew Wilcox
[not found] ` <20041116032218.GF1108-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>
2004-11-16 18:46 ` Matthew Wilcox
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=20041120033240.GJ1108@parcelfarce.linux.theplanet.co.uk \
--to=matthew-ztpu424noj8@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=luming.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=michael.fu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=robert.moore-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