From: Paul Mackerras <paulus@samba.org>
To: Dan Malek <dan@embeddededge.com>
Cc: acurtis@onz.com, Ppc Embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: 8260 Memory Management
Date: Sun, 25 Aug 2002 19:48:31 +1000 (EST) [thread overview]
Message-ID: <15720.42991.852001.315071@argo.ozlabs.ibm.com> (raw)
In-Reply-To: <3D6797F8.4000106@embeddededge.com>
Dan Malek writes:
> I was doing that as part of the 2.5 interrupt changes, but if you
> want to do it now we can try. On the 8260 it's not as bad as the 8xx,
> but you have to ensure the legacy and PCI interrupts are outside of
> the internal controller and CPM ranges.
Well... the #define request_irq request_8xxirq merely means that
including anything that calls request_irq will cause the kernel link
to fail. Which I assume you put in to make sure you weren't linking
in any drivers that might assume legacy ISA irq numbers.
By now you must have got the configs, makefiles, etc. sorted out so
that you aren't including any unwanted drivers. So the #define can be
removed. Removing the #define and changing all the calls to
request_8xxirq to request_irq won't actually change any object code or
any runtime behaviour, it'll just look cleaner in the source code. :)
PCI interrupts aren't a problem because the platform code assigns the
interrupt numbers for each slot, and the drivers then just use that
(i.e. pci_dev->irq), and if they don't we shoot them.
Legacy interrupts aren't a problem because you just don't include the
driver, or else you set up the header files etc. so that the driver
doesn't make the wrong assumptions (e.g. serial.h). So I don't see
any need to avoid using interrupt numbers 0-15 in general. We use
interrupts 0-15 on powermac (they are often DBDMA completion
interrupts) without any problems.
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-08-25 9:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-23 4:44 8260 Memory Management Allen Curtis
2002-08-23 5:01 ` Dan Malek
2002-08-23 13:58 ` Allen Curtis
2002-08-23 23:39 ` Dan Malek
2002-08-24 0:02 ` Paul Mackerras
2002-08-24 14:28 ` Dan Malek
2002-08-25 9:48 ` Paul Mackerras [this message]
2002-08-25 19:09 ` Tom Rini
-- strict thread matches above, loose matches on Subject: below --
2002-08-24 0:01 acurtis
2002-08-24 0:36 acurtis
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=15720.42991.852001.315071@argo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=acurtis@onz.com \
--cc=dan@embeddededge.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).