Bugs in the PPC/shared interrupt code + dec21140
eric.valette at free.fr
Sat Feb 22 11:00:57 UTC 2003
Till Straumann wrote:
> 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
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);
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
> 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
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
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...
More information about the users