On 01/05/2012 11:53 PM, Terry Fryar wrote:
So, this would cover the rtdm_event_timedwait(), for example??  This would
*not* work in a non-realtime thread..correct??

Correct.

-----Original Message-----
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:44 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi

On 01/05/2012 11:28 PM, Terry Fryar wrote:
Ah...simple enough!  One question though...are the xenomai sync
services items and irq functions available for non-RT kernel threads??

IRQ related routines? like request, enable, disable: yes. It's even
recommended to use them in that context actually.

Xenomai blocking services can only be used over a Xenomai thread, that is a
golden rule. Reason: to wait for a sync, the thread has to be held by the
scheduler of the kernel in question while it sleeps. Only Xenomai threads
have the required internal data to allow the Xenomai scheduler to hold them.


-----Original Message-----
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, January 05, 2012 4:25 PM
To: Terry Fryar
Cc: xenomai-help@gna.org
Subject: Re: [Xenomai-help] RTDM and spi

On 01/05/2012 11:12 PM, Terry Fryar wrote:
Using the RTDM api with Xen 2.6 to develop a linux driver.
Basically have an ISR registered using *rtdm_irq_request*()that is
triggered from a gpio pin. ISR works fine. Inside ISR, the only thing
done is a *rtdm_event_signal*() on an event.
Then, I have a task created using *rtdm_task_init*() that is waiting
on the event using *rtdm_event_timedwait*().
So far, so good...all works. But, in the task I am making an SPI call
after the event is signaled using spi_message_add_tail() and
spi_sync() and that's where I get this:
BUG: sleeping function called from invalid context at
kernel/mutex.c:278 [ 98.449178] in_atomic(): 1, irqs_disabled(): 0, pid:
-555875760, name:
vÿÿýÿ¿·½ÿ§ÿÿõ>ÿÿýw¿@ÞÞPÞÞ
[ 98.458686] INFO: lockdep is turned off.
[ 98.462811] [<c00572ac>] (unwind_backtrace+0x0/0xe0) from
[<c04639bc>]
(mutex_lock_nested+0x24/0x384)
[ 98.472501] [<c04639bc>] (mutex_lock_nested+0x24/0x384) from
[<c033ca48>] (__spi_sync+0x88/0xd8) [ 98.481730] [<c033ca48>]
(__spi_sync+0x88/0xd8) from [<bf007180>]
(irqdrv_task+0x44/0xd4 [irqdrv])
[ 98.491149] [<bf007180>] (irqdrv_task+0x44/0xd4 [irqdrv]) from
[<c00e93d0>] (xnarch_thread_trampoline+0x20/0x2c)
[ 98.501845] [<c00e93d0>] (xnarch_thread_trampoline+0x20/0x2c) from
[<c00e5adc>] (__xnpod_schedule+0x5cc/0xa54) [ 98.512355] [<c00e5adc>]
(__xnpod_schedule+0x5cc/0xa54) from [<fff7febf>] (0xfff7febf) [
98.520674] Xenomai: suspending kernel thread bf008180 ('irqdrvTask')
at 0xc00a92f8 after exception #0x0 I have tried this inside a kthread
and it works fine. I can also try the spi stuff without being
triggered by an IRQ, and I get the same error. I know this is
something simple???

You may not call the regular Linux kernel routines from a real-time
context.
You have two kernels running side by side, Linux and Xenomai,
unsynchronized. Your RTDM driver is entering __spi_sync() over a
non-Linux context, this can't work since that context may have
preempted Linux anywhere, including in the middle of what Linux thinks is
an atomic section.

Any kernel code you want to call from the real-time co-kernel has to
be adapted to support this. Specifically, you cannot run the regular
SPI stack over a real-time RTDM context.




_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help




--
Philippe.




--
Philippe.

_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Reply via email to