[Xenomai-help] install an interrupt-handler from a kernel module

[Xenomai-help] install an interrupt-handler from a kernel module

[Markus Franke]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Dear Xenomai-Users/Developers,

I have a basic question. Installing an interrupt handler is possible via
"rt_intr_create()", both from user-space and from a kernel module.
What happens when I do a "rt_intr_create()" from the module_init()
routine? By which priority, interrupts are delegated to my ISR? Do I
need to create an extra realtime task via "rt_task_create()" in order to
achieve hard realtime response, or is it enough to install the
interrupt-handler from module_init().


Thanks for help,
Markus Franke

[-- Attachment #2: Markus.Franke.vcf --]
[-- Type: text/x-vcard, Size: 245 bytes --]

begin:vcard
fn:Markus Franke
n:Franke;Markus
adr;quoted-printable:;;Vettersstra=C3=9Fe 64/722;Chemnitz;Saxony;09126;Germany
email;internet:Markus.Franke@domain.hid
x-mozilla-html:FALSE
url:http://www.tu-chemnitz.de/~franm
version:2.1
end:vcard

Re: [Xenomai-help] install an interrupt-handler from a kernel module

[Dmitry Adamushko]

On 20/12/06, Markus Franke <Markus.Franke@domain.hid> wrote:
> Dear Xenomai-Users/Developers,
>
> I have a basic question. Installing an interrupt handler is possible via
> "rt_intr_create()", both from user-space and from a kernel module.
> What happens when I do a "rt_intr_create()" from the module_init()
> routine? By which priority, interrupts are delegated to my ISR? Do I
> need to create an extra realtime task via "rt_task_create()" in order to
> achieve hard realtime response, or is it enough to install the
> interrupt-handler from module_init().

The key difference is in what context your ISR is executed.
If you register your ISR in kernel-space, the ISR will be called
asynchronously (when a dedicated interrupt occurs and interrupts are
on for this domain; otherwise - at the next point when interrupts will
be on again) preempting some running context. Sure, you shouldn't
access the preempted context or make any assumptions on its nature.

In this scheme per-ISR priorities are not supported. Of course, your
CPU may (and likely do) have some priority scheme (e.g. low-numbered
irqs are scheduled before higher numbered in case both are pending)
and, in fact, ipipe also has something similar (but you shoudn't rely
on this behaviour).

IOW, you don't need to create a separate task.

Another thing is registering an ISR in the user-space. In this case,
your ISR function "belongs" to your process'es address space and must
be called only in this context (on behalf of one of the threads of
your application). That's why normally one should create a dedicated
task to handle the ISR. As tasks may have different priorities, it
looks like ISRs (== a task) have priorities and may preempt each
other.


p.s. if you are about to write a real-time driver, consider using the
RTDM interface instead of the native skin.


-- 
Best regards,
Dmitry Adamushko

Re: [Xenomai-help] install an interrupt-handler from a kernel module

[Dmitry Adamushko]

On 20/12/06, Markus Franke <Markus.Franke@domain.hid> wrote:


Then I misundertood you. See below.


> My code for the kernel module looks something like that:
>
> ---snip---
> int myisr(xnintr_t* cookie)
> {
>         printk("interrupt fired")
> }
>
> module_init()
> {
>         rt_intr_create(...,my_isr,...);
>         rt_intr_enable(...);
>         register_chrdev(...);
> }
> ---snap---

that's ok.


>
> What about if I write something like that:
>
> ---snip---
> int myroutine()
> {
>         rt_intr_create(...,my_isr,...);
>         rt_intr_enable(...);
>         register_chrdev(...);
> }
>
> module_init()
> {
>         rt_task_create(...);
>         rt_task_start(...,myroutine,...);
> }
> ---snap---
>
> I can't see any difference whether to start a realtime task explicitly
> vi "rt_task_create" or not.

In this example, the "myroutine" task is used only to setup an ISR and
register a character device and then it _exits_. It's absolutely not
necessary and your first example is ok.

Look at docs for rt_intr_create()

 * This service can be called from:
 *
 * - Kernel module initialization/cleanup code
 * - Kernel-based task

The way how it's registered has no effect on deterministic behavior
wrt irq latencies.


-- 
Best regards,
Dmitry Adamushko