From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wayne Call" Date: Fri, 28 Jan 2011 13:27:53 -0700 Message-ID: <002601cbbf29$d77f4e40$867deac0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CBBEEF.2B207640" Content-Language: en-us Subject: [Xenomai-help] RT context Reply-To: wcall@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xenomai-help@domain.hid This is a multi-part message in MIME format. ------=_NextPart_000_0027_01CBBEEF.2B207640 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0027_01CBBEEF.2B207640 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

In the = heartbeat example, there is the following comment:

 

         &= nbsp;      /* Note: The I-pipe patch for = blackfin ensures that gpio_set_value

         &= nbsp;      * (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

 

 

------=_NextPart_000_0027_01CBBEEF.2B207640--