From: Dan Malek <dan@embeddededge.com>
To: Andy Lowe <andy_lowe@mvista.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: [PATCH and RFC] Remove request_8xxirq
Date: Fri, 21 Jun 2002 00:35:06 -0400 [thread overview]
Message-ID: <3D12ACFA.1070005@embeddededge.com> (raw)
In-Reply-To: DIEAKNAFAEAMABGFAOOKCEIKDIAA.andy_lowe@mvista.com
Andy Lowe wrote:
> .... My motivation for doing this in the first place was to
> make request_irq() work ....
Any 8xx that included a PCI configuration had request_irq() defined.
One of the things Wolfgang did was to map callers of request_irq() to
interrupts that made sense on a particular hardware design. That is
the only change that should have been necessary. None of the other
changes, especially to change all of the other irq requests to call
request_irq() were necessary.
> ..... but if it came down to it I would
> prefer to stick a #ifdef in an ISA device driver to hardcode a different IRQ
> vector than to stick a #ifdef in every PCI and PCMCIA device driver to make
> them call request_8xxirq or cpm_install_handler instead of request_irq.
The proper solution is to implement a request_irq() function that will
map interrupts properly for the board design, not modify everything to use
that function. You can have a board design that connects the PCI interrupt
lines to GPIOs or external interrupt lines, and in that case request_irq()
would have to know what PCI interrupt numbers are used and would map them
to a CPM interrupt. Along with that comes other special SIU configuration,
so it's uniqueness is quite evident.
This patch works for exactly one board design like the MBX, that uses an 8259
connected in a particular way for PCI interrupts. It isn't a general solution
and may not work properly for the example I mentioned above.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-06-21 4:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-21 2:32 [PATCH and RFC] Remove request_8xxirq Andy Lowe
2002-06-21 4:35 ` Dan Malek [this message]
2002-06-21 4:54 ` Andy Lowe
[not found] <15635.16331.965632.877856@argo.ozlabs.ibm.com>
2002-06-23 16:54 ` Stephan Linke
[not found] <3D124DF4.6060505@embeddededge.com>
2002-06-20 22:02 ` Wolfgang Denk
[not found] <20020620214551.GI16052@opus.bloom.county>
2002-06-20 21:58 ` Wolfgang Denk
[not found] ` <20020620221016.GK16052@opus.bloom.county>
[not found] ` <3D12F667.30902@bluewin.ch>
2002-06-24 17:00 ` Tom Rini
2002-06-24 17:49 ` Dan Malek
2002-06-24 17:59 ` Tom Rini
[not found] ` <3D1793E1.3030509@bluewin.ch>
[not found] ` <20020624224100.GL3489@opus.bloom.county>
2002-06-25 0:03 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 20:34 Tom Rini
2002-06-20 21:04 ` Dan Malek
2002-06-20 21:39 ` Tom Rini
2002-06-20 22:03 ` Dan Malek
2002-06-20 16:58 ` Benjamin Herrenschmidt
2002-06-20 22:34 ` Tom Rini
2002-06-20 21:16 ` Wolfgang Denk
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=3D12ACFA.1070005@embeddededge.com \
--to=dan@embeddededge.com \
--cc=andy_lowe@mvista.com \
--cc=linuxppc-embedded@lists.linuxppc.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;
as well as URLs for NNTP newsgroup(s).