Bugs in the PPC/shared interrupt code + dec21140

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > Till Straumann wrote:
 > 
 > >  - one more interesting quirk: The dec21140 driver reads
 > >    the PCI_INTERRUPT_LINE from PCI config space. It actually
 > >    misses to add the BSP_PCI_IRQ_LOWEST_OFFSET to that number
 > >    before connecting the interrupt handler.
 > >    So, why does it work in spite of that?
 > >      a) The MVME2306 (for sake of backwards compat) actually
 > >         routes some PCI interrupts (ethernet, universe)
 > >         to the ISA PIC AS WELL.
 > >      b) The firmware stores the ISA interrupt number in
 > >         PCI config space
 > 
 > There is a way to program the openpic as passthrough for the legacy 
 > devices... Maybe the firmware program it on some board and it is not 
 > correctly changed afterwards. Maybe we should check if the code has been 
 > changed since E. Raguet made the initial driver submission to see if 
 > indeed the libchip shared code does not work or works only for code that 
 > use openpic legacy mode... Could joel check CVS to see what irq number 
 > was used when we submitted the driver? NB : the code is probably in an 
 > deleted MPC750 BSP directory...
 > 
 > When I say that even having a symbolic name is a pain for connecting the 
 > interrupt this is a rather concerete example...

It seems that RTEMS simply uses the default content of the
PCI_INTERRUPT_LINE register, blindly using it as the vector.  It would
be useful to include something in the revised irq api to provide some
means of allocating vectors rather than simply picking arbitrary ones.
Would traversing the vector list to find unused entries be enough?

 > 
 > 
 > >  --> fix to this would require the dec21140 driver to
 > >      a) add the correct PIC_IRQ_LOWEST_OFFSET to the
 > >         PCI_INTERRUPT_LINE
 > >      b) bootloader would have to do some fixup on the
 > >         PCI_INTERRUPT_LINE register to replace the
 > >         ISA interrupt lines with the OpenPIC ones.
 > > --> submitted as PR#361
 > > 
 > > Interesting
 > 

I'm completely overhauling the dec21140 driver right now to put it
into line with the existing vectoring api and to support multiple
units.  Right now the built-in dec21140 still works (whew...), and the
2nd unit is addressing OK but having interrupt problems.  I'll give
the above a try.

I REALLY wish somebody would tell me where to go to find and/or submit
PRs.  www.rtems.com has been inaccessible to me all weekend.

Gregm