From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: linuxppc-dev@lists.linuxppc.org
Cc: Sven.Dickert@planb.de, davidm@amberdata.demon.co.uk,
hollis@austin.ibm.com, paubert@iram.es
Subject: Re: RFC: i8259.c cleanup
Date: Wed, 7 Nov 01 14:43:28 PST [thread overview]
Message-ID: <0111072243.AA06516@ivan.Harhan.ORG> (raw)
Gabriel Paubert <paubert@iram.es> wrote:
> > Would you say poking the 8259 directly is more "right" than using 0xbffffff0
> > (or equivalent)?
>
> Certainly not. Most ISA bridges (which are the part which contains the
> dual 8259 Pathetic Interrupt Controller), are tested in an x86
> environment, which generate PCI interrupt acknowledge cycles. So hitting
> hardware bugs is much less likely than with polling.
In the PPC world, however, this requires the following assumptions:
1. That the 8259 pair is in a PCI-to-ISA south bridge.
2. That the above bridge is connected to the PPC-to-PCI host bridge by an
uninterrupted PCI bus. PCI-to-PCI bridges in between may not pass Interrupt
Acknowledge cycles. There is an SBS board coming up that will have a GT64260
host bridge, a VT82C686B south bridge, and a P2P bridge in between. I don't
know if the P2P bridge will pass Interrupt Acknowledge cycles, but I don't
think there is a requirement that it does. If it does, great, but if it
doesn't, I'm not going to tell the hardware engineers to change their
design. We've proven the VT82C686B working on the Adirondack, and the
Adirondack port in the current linuxppc_2_4_devel works beautifully with the
i8259.c code using polls.
3. The host bridge must allow you to generate Interrupt Acknowledge cycles, and
you have to know how it does it, as all host bridges do it differently.
MS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2001-11-07 22:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-07 22:43 Michael Sokolov [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-11-07 23:04 RFC: i8259.c cleanup Michael Sokolov
2001-11-07 23:00 Michael Sokolov
2001-11-07 22:55 Michael Sokolov
2001-11-07 21:22 Michael Sokolov
2001-11-07 21:26 ` Geert Uytterhoeven
2001-11-07 21:13 Michael Sokolov
2001-11-07 21:22 ` Geert Uytterhoeven
2001-11-07 20:31 Michael Sokolov
2001-11-07 4:43 Michael Sokolov
2001-11-07 6:31 ` Dag Nygren
2001-11-07 7:00 ` Dan Malek
2001-11-07 7:09 ` Dag Nygren
2001-11-07 6:38 ` Dan Malek
2001-11-06 23:15 hollis
2001-11-07 6:37 ` Dan Malek
2001-11-07 9:31 ` Geert Uytterhoeven
2001-11-07 9:40 ` Gabriel Paubert
2001-11-07 9:38 ` Gabriel Paubert
2001-11-07 17:06 ` hollis
2001-11-07 17:17 ` Geert Uytterhoeven
2001-11-07 21:17 ` Gabriel Paubert
2001-11-07 22:01 ` hollis
2001-11-07 20:46 ` Val Henson
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=0111072243.AA06516@ivan.Harhan.ORG \
--to=msokolov@ivan.harhan.org \
--cc=Sven.Dickert@planb.de \
--cc=davidm@amberdata.demon.co.uk \
--cc=hollis@austin.ibm.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=paubert@iram.es \
/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).