[Xenomai-help] Problem with semaphores in an RTDM driver

[Xenomai-help] Problem with semaphores in an RTDM driver

[Johan Borkhuis]

Hello,

I am trying to use semaphores inside my driver. It is a driver that can 
be used as standard Linux driver and RTDM driver.

However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt 
function I get a -1 return value, indicating EPERM. When I look at the 
thread state I see a value of 0x00400080, which indicates a standard 
Linux thread. The rtdm-context is 0x00000001.
The userspace thread has a thread state of 00300380.

What am I doing wrong here? How can I get a semaphore or other sync 
mechanism to work inside my RTDM driver?

We are using Xenomai 2.4.1 on Linux 2.6.20 for powerpc.

Kind regards,
    Johan Borkhuis

-- 
Johan Borkhuis                                  Dutch Space BV
email:        j.borkhuis@domain.hid          Newtonweg 1
phone:        071-5245788                       Leiden
fax:          071-5245499                       The Netherlands

Re: [Xenomai-help] Problem with semaphores in an RTDM driver

[Sebastian Smolorz]

Johan Borkhuis wrote:
> I am trying to use semaphores inside my driver. It is a driver that can 
> be used as standard Linux driver and RTDM driver.
> 
> However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt 
> function I get a -1 return value, indicating EPERM.

Your read_nrt function is only for non real-time tasks. So if you use a 
call to a service which requires primary execution mode of Xenomai it 
consequentially fails.

> When I look at the 
> thread state I see a value of 0x00400080, which indicates a standard 
> Linux thread. The rtdm-context is 0x00000001.
> The userspace thread has a thread state of 00300380.
> 
> What am I doing wrong here? How can I get a semaphore or other sync 
> mechanism to work inside my RTDM driver?

Use RTDM services inside the *_rt functions and plain Linux services 
inside the *_nrt functions of your driver.

-- 
Sebastian

Re: [Xenomai-help] Problem with semaphores in an RTDM driver

[Jan Kiszka]

Johan Borkhuis wrote:
> Hello,
> 
> I am trying to use semaphores inside my driver. It is a driver that can 
> be used as standard Linux driver and RTDM driver.
> 
> However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt 

Calling those blocking RT services over a non-RT RTDM handler is a
strong indication that you are doing something fundamentally wrong.

(BTW, for consistency reasons, you shouldn't use native API services in
RTDM drivers. Technically, this can be OK, but it is at least very unclean.)

> function I get a -1 return value, indicating EPERM. When I look at the 
> thread state I see a value of 0x00400080, which indicates a standard 
> Linux thread. The rtdm-context is 0x00000001.
> The userspace thread has a thread state of 00300380.
> 
> What am I doing wrong here? How can I get a semaphore or other sync 
> mechanism to work inside my RTDM driver?

RT resources are for RT threads in _primary_ mode. Why do you want to
pend on those resources while the threads are in secondary ("nrt") more?

> 
> We are using Xenomai 2.4.1 on Linux 2.6.20 for powerpc.
> 
> Kind regards,
>     Johan Borkhuis
> 

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] Problem with semaphores in an RTDM driver

[Johan Borkhuis]

Jan Kiszka wrote:
> Johan Borkhuis wrote:
>   
>> Hello,
>>
>> I am trying to use semaphores inside my driver. It is a driver that can 
>> be used as standard Linux driver and RTDM driver.
>>
>> However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt 
>>     
>
> Calling those blocking RT services over a non-RT RTDM handler is a
> strong indication that you are doing something fundamentally wrong.
>
> (BTW, for consistency reasons, you shouldn't use native API services in
> RTDM drivers. Technically, this can be OK, but it is at least very unclean.)
>   

This is true, but as the RTDM sem's did not work for me I moved to the 
rt_sem, which also did not work for the same reason.

>> function I get a -1 return value, indicating EPERM. When I look at the 
>> thread state I see a value of 0x00400080, which indicates a standard 
>> Linux thread. The rtdm-context is 0x00000001.
>> The userspace thread has a thread state of 00300380.
>>
>> What am I doing wrong here? How can I get a semaphore or other sync 
>> mechanism to work inside my RTDM driver?
>>     
>
> RT resources are for RT threads in _primary_ mode. Why do you want to
> pend on those resources while the threads are in secondary ("nrt") more?
>   

The main problem is is that part of the driver (especially the interrupt 
handler) is running in primary mode. The application itself is running 
partly in secondary mode. I need some mechanism to have the application 
waiting for a signal from the interrupt handler.
Do I need to implement this using rtdm_nrtsig, or are there other ways 
to send signals from primary to secondary mode?

Kind regards,
    Johan Borkhuis

-- 
Johan Borkhuis                                  Dutch Space BV
email:        j.borkhuis@domain.hid          Newtonweg 1
phone:        071-5245788                       Leiden
fax:          071-5245499                       The Netherlands

Re: [Xenomai-help] Problem with semaphores in an RTDM driver

[Jan Kiszka]

Johan Borkhuis wrote:
> Jan Kiszka wrote:
>> Johan Borkhuis wrote:
>>  
>>> Hello,
>>>
>>> I am trying to use semaphores inside my driver. It is a driver that
>>> can be used as standard Linux driver and RTDM driver.
>>>
>>> However, when I use rt_sem_p or rtdm_sem_timeddown in my read_nrt     
>>
>> Calling those blocking RT services over a non-RT RTDM handler is a
>> strong indication that you are doing something fundamentally wrong.
>>
>> (BTW, for consistency reasons, you shouldn't use native API services in
>> RTDM drivers. Technically, this can be OK, but it is at least very
>> unclean.)
>>   
> 
> This is true, but as the RTDM sem's did not work for me I moved to the
> rt_sem, which also did not work for the same reason.
> 
>>> function I get a -1 return value, indicating EPERM. When I look at
>>> the thread state I see a value of 0x00400080, which indicates a
>>> standard Linux thread. The rtdm-context is 0x00000001.
>>> The userspace thread has a thread state of 00300380.
>>>
>>> What am I doing wrong here? How can I get a semaphore or other sync
>>> mechanism to work inside my RTDM driver?
>>>     
>>
>> RT resources are for RT threads in _primary_ mode. Why do you want to
>> pend on those resources while the threads are in secondary ("nrt") more?
>>   
> 
> The main problem is is that part of the driver (especially the interrupt
> handler) is running in primary mode. The application itself is running
> partly in secondary mode. I need some mechanism to have the application
> waiting for a signal from the interrupt handler.
> Do I need to implement this using rtdm_nrtsig, or are there other ways
> to send signals from primary to secondary mode?

rtdm_nrtsig is the way to go if some Linux-only task is to be woken up.
If your pending task is in fact a Xenomai thread that just executes most
of the time in secondary mode, you are also fine with implementing
read_rt (dropping read_nrt). Then the caller will be switched to primary
mode when invoking read() on your RTDM device.

The latter approach is required if there are also cases where waking up
is part of some RT-critical path. The former approach via rtdm_nrtsig
can be more efficient because the signaling path is shorter, but also
non-deterministic (for the waiting, the waker remains deterministic).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux