Re: [pok-devel] [Discussion] IRQ handling: chaining && pending IRQs |
[ Thread Index | Date Index | More lists.tuxfamily.org/pok-devel Archives ]
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?
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
>
>
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |