[okl4-developer] OKL4 v2.1: Interrupt management offered to OK-Linux

[Geoffrey Lee]

On Tue, Sep 23, 2008 at 03:21:30PM +0200, Frank Kaiser wrote:
> Hello
> 
>  

Hi Frank

There are a number of limitations currently with the interrupt
implementation in OK Linux.  We are aware of the problems
that you listed below.

The irq < 32 was a hack to allow hardware interrupts and Iguana
virtual devices to co-exist, but this scheme breaks if your
hardware interrupts on an irq >= 32.  As for the empty functions,
they are no-op function pointers for the Iguana irq chip type.

	-gl


> 
> When a Linux driver wants to use a hardware interrupt, it seems to be
> expected to use some functions provided by file
> arch/l4/kernel/sys_iguana.c. When adapting a touch screen driver to our
> AT91SAM9263 board we found that the driver lost the interrupt completely
> after a disable/enable cycle. This phenomenon seems to be related to a
> dubious implementation in the mentioned file. It provides 5 functions:
> 
> *       iguana_startup_irq(unsigned int irq)
> If irq < 32 (why that?), hardware_register_interrupt() is called which
> sends and IPC to the Iguana Server which invokes L4_RegisterInterrupt().
> The rationale of this indirection seems to be to overcome the missing
> security control for the caller of the function. Independently of of the
> irq number the function iguana_enable_irq() is called.
> 
> *       iguana_ack_irq(unsigned int irq)
> This function is empty, so why is it there?
> 
> *       iguana_end_irq(unsigned int irq)
> This function calls iguana_enable_irq(), if the irq state is not
> disabled or in progress. What shall be ended here?
> 
> *       iguana_disable_irq(unsigned int irq)
> If irq < 32 (why that?), L4_UnregisterInterrupt() is called, otherwise a
> bit in the variable irq_mask is masked. The bit is determined by the
> operation 1UL << irq which leads to nothing since irq_mask is of type
> unsigned long int which is of size 32 bit, while the shift operation
> leads to a value bigger than that. Apparently the direkt call of
> L4_UnregisterInterrupt() works, although it should be rejected if the
> security control for the caller is not given.
> 
> *       iguana_enable_irq(unsigned int irq)
> If irq < 32 (why that?), L4_AcknowledgeInterruptOnBehalf() is called,
> otherwise the already mentioned meaningless operation on the variable
> irq_mask is applied. I do not see how this enables an interrupt at L4
> kernel level which has been unregistered (= disabled) before.
> 
> The observed behaviour is that the call of iguana_startup_irq()
> activates an interrupt at L4 kernel level, the call of
> iguana_disable_irq() deactivates it and the call of iguana_enable_irq()
> never reactivates it again. Adding to this the many FIXME comments in
> the file, I have some doubt that this file is fully functional. We are
> not reluctant to repair this mess, but before doing so we have to
> understand what this assembly of 5 interrupt management functions is
> expected to do, and what, among others, is the purpose of the check
> against this magic value 32. Can anybody tell?
> 
>  
> 
> Regards
> 
> Frank
> 

> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer


--