Bugs in the PPC/shared interrupt code + dec21140

[Valette Eric]

Till Straumann wrote:
> Eric,
> 
> it seems that you didn't really use priorities that much
> (on the shared/PPC BSP) ;-)

Yes because anyway the only interrupt that was important for performance 
on MCP750 was the ethernet one and that measured throuhput was correct 
with theses settings.

BTW, you should know that the port to MCP750 was a kind of exercise for 
me in order to offer to CRF people two choices as reference hardware 
platform : Intel PC compatible, and high end PPC. For PPC I choose the 
MCP750 as it was pci and some drivers can be shared (ethernet dec one 
for example). We had tree OS on each reference platforms : ChorusOS, 
RTEMS, and Linux.

Later, mainly for cost reasons, the only CRF project that choose PPC 
hardware choose a 8XX processor... So port status is still a kind of 
exercise. When I see the number of people that managed to use it and 
reported sucess, I'm quite happy and rather confident, the software 
architecture for moto_shared and 6xx PPC was pretty good...

BUT definitively : yes this is an unfinished and unpolished work. 
Please make it better. This is the magic of OSS : you do something share 
it, and other enhance it and you get your initial investment back or 
even more than expected.

The mbx8XX status is somewhat better but as the 8XX hardware we used 
is/was proprietary, it was not possible nor even realistic for deadline 
reasons to retrofit all the code... So it is not because you do not see 
the irq priority used in actual rtems code, that it is not on real 
applications...

I retrofitted the most important things and as much as possible to RTEMS 
mbx8XX but not all...

>  - The generic openpic_init() routine sets all priorities
>    to 8

I think that, in general, the default irq initialisation should set so 
that for all interrupt, when entering the handler only the current one 
is masked  but as mentionned in my requirements I whish it could be 
changed later on so that drivers can indeed program their irq priorities...

NB : we do have application on Intel that indeed use the

int BSP_rtems_irq_mngt_set(rtems_irq_global_settings* config);
int BSP_rtems_irq_mngt_get(rtems_irq_global_settings**);

To define priorities that are different than the initial ones. I would 
even add that if we do not reconfigure irq prio, the whole applications 
fails because it cannot handle the necessary throuput for a specific 
interrupt (video stream).

But, unless you have a real application in mind, there is no way to know 
"a priori" what the best priorities are for the final application so the 
generic code should program a default behavior. And this is why, and API 
to reprogram them is also necessary.


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


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

When I see linux PPC openpic management code, and the number of page of 
openpic docs you have probably read, you probably understand even more 
accurately now that PIC management should not be let to device driver 
writer...

I think all this mail is wonderfull and comes exactly at the right time 
because it illustrates by concrete examples many of the things I have 
requested for the IRQ design based on my personnal experience. But using 
your experience for justifying things is always difficult because other 
have (less/other/different) experience... That is why I have CC'ed joel.

I hope that allthough it will require unexpected work to fix the actual 
code, it will be usefull for you to propose a better IRQ API design...

-- eric