Skip to contentSkip to conversation

RFC: i8259.c cleanup

DISCUSSION Michael Sokolov 3 participants 5 messages Nov 7, 2001

lore
Share & tools
lore

Michael Sokolov

author
#0 lore raw
Quoted 7 lines · [email protected] wrote:

Anyways, by reading from 0xbffffff0 we can get the active irq without having to play with the 8259 directly (which we were doing wrong; see above URL). This is true on the IBM PReP's because the 8259's are implemented in the Fire Coral SIO bridge (which is on the PCI bus), so it can respond to the PHB's interrupt request. (Unless I'm mistaken it's the PHB, in this case MPC105, which decodes 0xbffffff0 and asks the system interrupt controller to supply the active irq number.)

Different host bridges provide different means for generating PCI Interrupt Acknowledge cycles. None of the bridges I've worked with (IBM CPC700, IBM CPC710, and Galileo GT64260) does it via BFFFFFF0. CPC710 does it via a register in the IBM PHB structure for each of its two PCI interfaces, CPC700 has a special register, and GT64260 has special registers for PCI0 and PCI1 Interrupt Acknowledge in its internal registers space.

Quoted 2 lines

The following patch (to linuxppc_2_4_devel) does exactly that - it reads from 0xbffffff0 instead of the 8259 directly.

i8259.c is not specific to PREP, it's used by many platforms in the tree. Your patch as posted will break a lot of platforms in the tree, including all SBS boards which use one of the above host bridges and 8259s in a south bridge.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

#1 lore raw
Quoted 11 lines
Quoted 7 lines · [email protected] wrote:

Anyways, by reading from 0xbffffff0 we can get the active irq without having to play with the 8259 directly (which we were doing wrong; see above URL). This is true on the IBM PReP's because the 8259's are implemented in the Fire Coral SIO bridge (which is on the PCI bus), so it can respond to the PHB's interrupt request. (Unless I'm mistaken it's the PHB, in this case MPC105, which decodes 0xbffffff0 and asks the system interrupt controller to supply the active irq number.)

Quoted 6 lines

Different host bridges provide different means for generating PCI Interrupt Acknowledge cycles. None of the bridges I've worked with (IBM CPC700, IBM CPC710, and Galileo GT64260) does it via BFFFFFF0. CPC710 does it via a register in the IBM PHB structure for each of its two PCI interfaces, CPC700 has a special register, and GT64260 has special registers for PCI0 and PCI1 Interrupt Acknowledge in its internal registers space.

I think my suggestion for an improvement of the open_pic() interface could help you in this... I posted it on the linux_embedded list, but got no comments so far.

Quoted 7 lines
Quoted 3 lines

The following patch (to linuxppc_2_4_devel) does exactly that - it reads from 0xbffffff0 instead of the 8259 directly.

i8259.c is not specific to PREP, it's used by many platforms in the tree. Your patch as posted will break a lot of platforms in the tree, including all SBS boards which use one of the above host bridges and 8259s in a south bridge.

Yep.

I will attach my port for the SBS VG4 board, it uses the new open_pic() interface
and it would be nice if you checked it out.
If someone (?) could add it to the BK tree I would also appreciate it.

BRGDS

Signature · 28 lines
Dag Nygren                               email: [email protected]
Oy Espoon NewTech Ab                     phone: +358 9 8024910
Träsktorpet 3                              fax: +358 9 8024916
02360 ESBO                              Mobile: +358 400 426312
FINLAND


Here is a copy of the post to linux embedded:

Hi,

here is a working port for the VG4 PPC-board from SBS.

- The diffs are against an almost 1 week old linuxppc_2_4_devel from
BK, but there should be no big problemns there
- This port is using a new scheme for the openpic_init(), proposed
  by me some posts ago, but it was implemented in it's own
  copy of the open_pic code, open_pic2.c, and so it should be
  completely nonintrusive on the existing ports. Anyone doing
  a new port should IMH take a look at open_pic2 as it will
  make your work easier.
  It would of course be nice to get rid of the code duplication there
  is openpic <-> openpic2, preferrably by all ports beeing transferred
  to the new scheme.
- couldn't get the sym53c8xx driver in the BK kernel to work, so I
  downloaded a newer version, and this works fine. It is rather large
  so it is not included here, but if you need it, get it from it's homepage
  or send me a mail.
#2 lore raw
Quoted 3 lines · Dag Nygren

I think my suggestion for an improvement of the open_pic() interface could help you in this... I posted it on the linux_embedded list, but got no comments so far.

Yes, you did :-).

	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

#3 lore raw
Quoted 9 lines
Quoted 3 lines · Dag Nygren

I think my suggestion for an improvement of the open_pic() interface could help you in this... I posted it on the linux_embedded list, but got no comments so far.

Yes, you did :-).

Sure, but that was on the i8259 stuff.
It is not in this patch, I left that one out as it seemed like you did not like that ;-)

The patch I posted will not touch the i8259() ! It only replaces the openpic_init() function with one that describes the openpic a little better.

Actually I think that this description could easily be extended to something like the one you purposed.

Dag

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/