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

[Frank Kaiser]

Hello, Geoffrey

I was busy with other tasks that delayed the feedback to your response below.
The first thing is that I do not understand what you are referring to with then wording "Iguana irq chip type".
Regarding the "irq < 32" check I have to mention that there is a GUMSTIX variant which supports more than 32 interrupts, and that that is supported in the L4 kernel. Having in mind that GUMSTIX seems to be your reference platform for the ARM architecture, I really wonder that you could come up with such a "hack", as you name it.
But my major concern is that LINUX expects to set certain interrupt properties which is not supported by the L4 kernel. The LINUX interrupt system deals with the properties IRQF_TRIGGER_RISING, IRQF_TRIGGER_FALLING, IRQF_TRIGGER_LOW, IRQF_TRIGGER_HIGH, but there is no means to handle these properties in the L4 kernel, although configuring the interrupt trigger behaviour is mandatory for a proper working hardware on almost every embedded platform. I think there should be an extension of the 'config interrupt' SYSCALL to handle this. And it should be possible to insert these properties into the driver definitions of a 'machines.py' file which would require an extension of the build scripts.
The AT91SAM926x platform handles interrupt priorities independently of the IRQ number (as opposed to the PC99 platform and its predecessors). Although the L4 kernel does not supported nested interrupts, the interrupt priority is significant to decide which interrupt is signaled first when more than one is pending. So it should be possible to set interrupt priorities explicitly by the 'config interrupt' SYSCALL.
Finally I'd like to know when you plan to deliver an improved interrupt handling for OK-Linux. The shortcoming of the current solution is a real problem for us, and we are about to apply some private fixes to overcome the current constraints (for instance the malfunction regarding enabling/disabling an interrupt by an LINUX driver).

Regards
Frank
> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Friday, September 26, 2008 7:56 AM
> To: Frank Kaiser
> Cc: developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 v2.1: Interrupt management offered toOK-
> Linux
> 
> 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