From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: acpi-devel@lists.sourceforge.net, "Brown,
Len" <len.brown@intel.com>, David Mosberger <davidm@hpl.hp.com>,
Andi Kleen <ak@suse.de>, "Nakajima, Jun" <jun.nakajima@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: [ACPI] Re: [PATCH] ACPI PCI IRQ routing rework
Date: Mon, 17 May 2004 15:41:35 +0000 [thread overview]
Message-ID: <200405170941.35673.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <941A6821ACE16D4BBB8A958A0EB047F7264554@pdsmsx404.ccr.corp.intel.com>
On Monday 17 May 2004 3:58 am, Li, Shaohua wrote:
> For the IOSAPIC, your patch mask interrupts in initialization, but
> should we mask platform interrupt?
I mask the interrupt in the IOSAPIC when programming the RTE.
This IOSAPIC programming happens before request_irq(), so I
think it makes sense to leave the RTE masked, because there's
nothing set up to do anything with an interrupt if it occurs.
If somebody's actually interested in the interrupt, there should
be a later request_irq() call, which will unmask the RTE via the
request_irq->setup_irq->startup path.
The only ia64 platform interrupt we do anything with is
ACPI_INTERRUPT_CPEI. My usual test boxes don't support CPEI,
but from reading the code, iosapic_register_platform_intr()
programs the RTE (leaving it masked) when we parse the MADT.
Then ia64_mca_init() looks up the vector assigned for CPEI
and calls setup_irq() for it, which will unmask the RTE.
Maybe we could do a little rework to make ia64_mca_init() use
request_irq() (similar to how acpi_os_install_interrupt_handler()
works), but I think the current scheme should work. Or do you
have evidence to the contrary?
Bjorn
next prev parent reply other threads:[~2004-05-17 15:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-17 9:58 [ACPI] Re: [PATCH] ACPI PCI IRQ routing rework Li, Shaohua
2004-05-17 15:41 ` Bjorn Helgaas [this message]
2004-05-17 16:16 ` Kenji Kaneshige
2004-05-17 18:41 ` Bjorn Helgaas
2004-05-18 9:30 ` Kenji Kaneshige
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=200405170941.35673.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=ak@suse.de \
--cc=davidm@hpl.hp.com \
--cc=jun.nakajima@intel.com \
--cc=len.brown@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=shaohua.li@intel.com \
/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