RFC: i8259.c cleanup

[Dag Nygren]

> 
> hollis at austin.ibm.com 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.

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.

> 
> > 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


-- 
Dag Nygren                               email: dag at newtech.fi
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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: vg4.diff.gz
Type: application/x-gzip
Size: 1501 bytes
Desc: vg4.diff.gz
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20011107/82830656/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vg4.newfiles.gz
Type: application/x-gzip
Size: 16380 bytes
Desc: vg4.newfiles.gz
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20011107/82830656/attachment-0001.bin>