Re: [pok-devel] [Discussion] IRQ handling: chaining && pending IRQs

[Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>]

Hi,

in my current working version, POK can administer one interrupt handler
per partition plus one for the kernel.
If a kernel interrupt handler is registered, it is called first and then
the handler of the currently scheduled partition, if one is registered.

To register a interrupt handler from inside a partition, I introduced a
new syscall: POK_SYSCALL_IRQ_REGISTER_HANDLER (25). In syscall.c I have
a #ifdef i386 guard (i386 is set by gcc), as the functionality is x86
only and syscall.c is shared among all architectures.

So far I tested it with a little application on qemu. The kernel and
partition handler got notified. The offset between them - the partition
handler is registered later - was constant for the first 1k ticks.

Another change is the invokation of pok_pic_eoi. This is now done, by
_C_isr_handler, before it calls the first handler.

Comments? Objections? Questions?

Source code:
https://github.com/phipse/pok

Cheers,
Philipp



On 08/18/2013 01:07 AM, Philipp Eppelt wrote:
> Hi,
> 
> I have the interrupt handling up and running.
> 
> I still don't count interrupts to deliver them to not scheduled, but
> registered partitions.
> 
> I just wrote a blog post including source code excerpts:
> http://phipse.github.io/rtems/blog/2013/08/17/pok-hardware-interrupt-handling/
> 
> I haven't run the full testsuite yet, but if I fiddle with the
> POK_NEEDS_GETTICK switch I can print the occurred ticks with a test
> application and they are not just 0. So at least the clock tick is
> working correctly.
> 
> ToDo:
> - Rewrite all HW IRQ handler, as they use the old macro.
> - Modify all functions registering HW IRQs to use
> pok_bsp_irq_register_hw function.
> - POK_NEEDS_GETTICK issue.
> - Test more examples.
> 
> Source code:
> https://github.com/phipse/pok
> 
> 
> Cheers,
> Philipp
> 
>