From: Len Brown <len.brown@intel.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ross Dickson <ross@datscreative.com.au>,
linux-kernel@vger.kernel.org, AMartin@nvidia.com,
kernel@kolivas.org, Ian Kumlien <pomac@vapor.com>
Subject: Re: ACPI SCI IOAPIC bug (Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered)
Date: 31 Mar 2004 17:19:40 -0500 [thread overview]
Message-ID: <1080771580.31359.32.camel@dhcppc4> (raw)
In-Reply-To: <A6974D8E5F98D511BB910002A50A6647615F0C10@hdsmsx402.hd.intel.com>
On Wed, 2004-02-18 at 12:43, Maciej W. Rozycki wrote:
> Note that if changing an I/O APIC input was indeed needed, the
> replace_pin_at_irq() function could be used.
Why is it that all IRQs get their name from the
IOAPIC pin number, but the timer connected to
pin 2 is called IRQ0 instead of IRQ2?
Are there other exceptions to this rule,
or is all the code for re-naming IRQs & pins
effectively just for the timer?
I wonder if we should't be moving to at least a build option which
deletes support for multiple pins at an IRQ, and deletes
suport for non-identity pin->IRQ mapping.
> I still wonder why these arrangements are made so late in a boot --
> after
> all, ACPI IRQ configuration is table-driven and does not require any
> specific hardware initialization to work. So it could be done at the
> stage MP-table parsing happens, couldn't it?
While the ACPI table parsing is very early, the _PRT parsing
can happen only after the ACPI interpreter is up, because
the _PRT's are encoded in AML.
thanks,
-Len
next parent reply other threads:[~2004-03-31 22:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A6974D8E5F98D511BB910002A50A6647615F0C10@hdsmsx402.hd.intel.com>
2004-03-31 22:19 ` Len Brown [this message]
2004-04-01 11:52 ` ACPI SCI IOAPIC bug (Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered) Maciej W. Rozycki
[not found] <BF1FE1855350A0479097B3A0D2A80EE0023ED17F@hdsmsx402.hd.intel.com>
2004-02-14 2:31 ` Len Brown
2004-02-18 17:43 ` Maciej W. Rozycki
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=1080771580.31359.32.camel@dhcppc4 \
--to=len.brown@intel.com \
--cc=AMartin@nvidia.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@ds2.pg.gda.pl \
--cc=pomac@vapor.com \
--cc=ross@datscreative.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.