[Xenomai-help] RT context

[Xenomai-help] RT context

[Wayne Call]

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

In the heartbeat example, there is the following comment:

 

                /* Note: The I-pipe patch for blackfin ensures that
gpio_set_value

                * (among other services) can safely be called from RT
context. */

 

So this states that the gpio_set_value can be called from an RT context.

 

What about an I2C driver, or an SPI driver?  There are linux kernel drivers
to support these devices.  Does it make sense to continue to use these
drivers in the linux kernel, and somehow have an RT context that can tap
into this data?  Does an RT context take precedence over the linux kernel
I2C and SPI drivers?  The Xenomai is its own kernel and somehow interacts
and works together with the linux kernel.  Do I have to re-structure a linux
kernel I2C driver completely into a Xenomai I2C driver?

 

In the past I have written a linux kernel driver on top of the I2C driver to
collect I2C data into a buffer.  I also wrote a Xenomai driver that makes
calls into this top level linux kernel I2C driver to get the data.  And
there is a Xenomai user application, running an RT context, that gets the
data from the Xenomai driver.

 

Is there a particular strategy I should be using for the I2C and SPI
interfaces?

 

Wayne

 

 


[-- Attachment #2: Type: text/html, Size: 3521 bytes --]

Re: [Xenomai-help] RT context

[Gilles Chanteperdrix]

Wayne Call wrote:
> In the heartbeat example, there is the following comment:
> 
>  
> 
>                 /* Note: The I-pipe patch for blackfin ensures that
> gpio_set_value
> 
>                 * (among other services) can safely be called from RT
> context. */
> 
>  
> 
> So this states that the gpio_set_value can be called from an RT context.

The reason for this is that, usually, toggling a GPIO is just a matter
of writing some bit to some IO memory. On some hardware, this operation
is atomic due to the nature of the hardware interface (separated
registers allow to set or clear a bit). On other hardware, where a
read-modify-write operation may be needed on a hardware register, this
operation may be protected by a spinlock, and what the I-pipe does is
simply replace the spinlock with an "I-pipe aware" to make it safe to be
used from the primary domain. I do not know in what case the blackfin
architecture is, but what this comment tells you is just that: this
function is safe to be called from primary domain.

But there is nothing preventing you from using the same GPIO from both
Xenomai domain and Linux domain, and chances are that it is not what you
want.

> What about an I2C driver, or an SPI driver?  There are linux kernel drivers
> to support these devices.  Does it make sense to continue to use these
> drivers in the linux kernel, and somehow have an RT context that can tap
> into this data?  Does an RT context take precedence over the linux kernel
> I2C and SPI drivers?  The Xenomai is its own kernel and somehow interacts
> and works together with the linux kernel.  Do I have to re-structure a linux
> kernel I2C driver completely into a Xenomai I2C driver?
> 
>  
> 
> In the past I have written a linux kernel driver on top of the I2C driver to
> collect I2C data into a buffer.  I also wrote a Xenomai driver that makes
> calls into this top level linux kernel I2C driver to get the data.  And
> there is a Xenomai user application, running an RT context, that gets the
> data from the Xenomai driver.
>  
> 
> Is there a particular strategy I should be using for the I2C and SPI
> interfaces?

an I2C driver or an SPI driver are much more complicated than basic
gpiolib drivers, and are harder to be made easy to be used from primary
domain, if at all possible.

In the case of the I2C, in particular, some bus drivers rely on the
"wait_for_completion/complete" API, which requires interaction with
Linux scheduler.

So, if your I2C driver is in that case, some driver has to be rewritten
for Xenomai, and if you want to also allow Linux to access the hardware,
you will have to handle the mutual exclusion. This has to be assessed on
a driver by driver basis, but I would tend to think that the most common
case is that a new driver has to be written specifically for Xenomai.

-- 
                                                                Gilles.

[Xenomai-help] rt context

[Peter Hua]

Thank you, Philippe.  This issue is resolved.  One follow-on question: the
CSW field of /proc/Xenomai/stat indicates the number of switches between
user-mode and kernel-mode, correct?


Regards,
Peter





-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org] 
Sent: Tuesday, January 17, 2012 12:37 AM
To: Peter Hua
Cc: xenomai-help-owner@domain.hid
Subject: Re: help rejected

On 01/17/2012 02:06 AM, Peter Hua wrote:
> Hi Philippe,
>
> I retract my previous statement.  The call to rtdm_in_rt_context() 
> returned '1'.  So the task was in RT context, but I don't understand 
> how?  Is there a way to force it to be non-rt?

There is no way you can do that from kernel space; mode switches are
implemented during the syscall transition between user and kernel. 
Memory mapping operation is usually part of the init chores of a driver, in
which case this would be a non-issue since RTDM runs the .open call in
non-rt kernel context (.open_rt is deprecated and even removed in latest
versions).

If your code tries to issue this mapping call from .ioctl_rt, then you
should move this particular ioctl command to the .ioctl_nrt handler instead.
Xenomai first tries the .ioctl_rt handler if present, then downgrades to
.ioctl_nrt if the former returned -ENOSYS. So, if both .ioctl_rt and
.ioctl_nrt have to coexist in your driver, then you should follow this
pattern:

static int foo_ioctl_rt(struct rtdm_dev_context *context,
		     rtdm_user_info_t *user_info,
		     unsigned int cmd, void *arg)
{
	switch (cmd) {

	case IOC_WHATEVER_MMAP:
		/* Tell Xenomai to offload to _nrt handler. */
		return -ENOSYS;
	...
	}
}

static int foo_ioctl_rt(struct rtdm_dev_context *context,
		     rtdm_user_info_t *user_info,
		     unsigned int cmd, void *arg)
{
	switch (cmd) {

	case IOC_WHATEVER_MMAP:
		ret =rtdm_mmap_to_user(...);
	...
	}
}

PS: I see you are now subscribed to Xenomai-help, so you should be allowed
to post there.

>
>
> Regards,
> Peter
>
>
>
>
>
> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Monday, January 16, 2012 1:53 PM
> To: Peter Hua
> Cc: xenomai-help-owner@domain.hid
> Subject: Re: help rejected
>
> On 01/16/2012 05:40 PM, Peter Hua wrote:
>>
>> Hello,
>>
>> My request for help was rejected.  Also, I did not get a confirmation 
>> for the subscription request.  Please help.
>
> I'll check your subscription asap, but for the time being, the answer 
> to your question is that you may not call that routine from a 
> real-time context. This is callable only from kernel module init, and 
> any other plain linux (kernel) context, not from Xenomai -rt context in
kernel space.
>
>>
>> Regards,
>> Peter
>>
>>
>>
>>
>> -----Original Message-----
>> From: xenomai-help-bounces@domain.hid
>> [mailto:xenomai-help-bounces@domain.hid] On Behalf Of 
>> xenomai-help-owner@domain.hid
>> Sent: Friday, January 13, 2012 12:17 PM
>> To: phua@domain.hid
>> Subject: rtdm_mmap_to_user call failed
>>
>> You are not allowed to post to this mailing list, and your message 
>> has been automatically rejected.  If you think that your messages are 
>> being rejected in error, contact the mailing list owner at
> xenomai-help-owner@domain.hid.
>>
>
>
> --
> Philippe.
>
>
>


--
Philippe.