The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Till Straumann wrote:
> Valette Eric wrote:
> 
>> Great. BTW you did not answer about the possibility to mask the 
>> current opepnpic irq via a mask and issue the openpic acknowledge 
>> ASAP. I have'nt OPENPIC doc anymore but from memory I did not find 
>> means to do it. Maybe worth investaigating because as you pointed out, 
>> the code is suboptimal. You cannot find agains broken hardware API :-)
>>
> 
> I am just browsing a Raven OpenPIC doc - it seems that i DOES have a 
> 'mask' bit. It says:
> 
> "MASK. Setting this bit disables any further
> interrupts from this source. If the mask bit is
> cleared while the bit associated with this interrupt
> is set in the IPR (interrupt pending register), the
> interrupt request will be generated."
> 
> It seems, that indeed the EOI could be done prior to running the
> user handler although that would require managing
> interrupt priorities in software by means of the MASK bits
> or the "interrupt task priority register" (using the latter
> is probably a much better idea).
> (if EOI is done after running the user handler, we can
> use the hardware priority management)

Looking at how linux code for openpic management evolved, I think we 
should totally rewrite the openpic code :-(

And YES the actual linux code for openpic_ack_irq does exactly what you 
suggest : mask the current interrupt and send the EOI... Just old linux 
code did not and openpic specs are rather heavy and complex (in french 
we say gaz factory)...

On the other hand, I'm not sure the code is *so* broken because it does 
roughly what linux did on PPC 3 years ago and I was compilling linux on 
linux on PPC750 as well as running network performance benchmarks...

-- eric