[Xenomai-help] Porting driver to RTDM

[Xenomai-help] Porting driver to RTDM

[Johan Borkhuis]

Hello,

I am working on porting a Linux VME driver to Xenomai. I am having some 
ideas on how to do this, but I would like to have some feedback on this.

There are 2 ways to communicate to devices on the VME bus: memory mapped 
and using interrupts. At this moment I setup the memory mapping when the 
system starts, and then use these mapped areas to read and write from 
the devices. The interrupts are processed using a standard interrupt 
handler, and a "Wait for interrupt" IOCTL-call is available to wait for 
a specific interrupt. The driver defines several VME devices: some 
control devices and some data devices.

My plans for the new driver are to have an RTDM driver next to the 
standard Linux driver. I will be using the standard driver for the setup 
of the system, like setting up the memory mapping. The RTDM driver will 
define a RT-control device to perform the interrupt handling and an RTDM 
IOCTL will be used to wait for the interrupts. This way I can have a 
RT-thread to process the interrupts.

The reason for this setup are:

    * I do not want to rewrite the current driver, as this driver
      already has all the functionality needed, except for the
      RT-performance.
    * The interface to VME devices is done using memory access and no
      other SW is needed for this. This means that during operational
      use no driver functions will be accessed.
    * The memory mapping is not as straight forward in RTDM as it is in
      standard Linux: for example there is no mmap function in the
      device structure.
    * I can still use drivers for VME devices that depend on the current
      driver.


Is this the right way to do this, or are there other ways to implement a 
driver like this one?

Kind regards,
    Johan Borkhuis

Re: [Xenomai-help] Porting driver to RTDM

[Jan Kiszka]

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

Johan Borkhuis wrote:
> Hello,
> 
> I am working on porting a Linux VME driver to Xenomai. I am having some 
> ideas on how to do this, but I would like to have some feedback on this.
> 
> There are 2 ways to communicate to devices on the VME bus: memory mapped 
> and using interrupts. At this moment I setup the memory mapping when the 
> system starts, and then use these mapped areas to read and write from 
> the devices. The interrupts are processed using a standard interrupt 
> handler, and a "Wait for interrupt" IOCTL-call is available to wait for 
> a specific interrupt. The driver defines several VME devices: some 
> control devices and some data devices.
> 
> My plans for the new driver are to have an RTDM driver next to the 
> standard Linux driver. I will be using the standard driver for the setup 
> of the system, like setting up the memory mapping. The RTDM driver will 
> define a RT-control device to perform the interrupt handling and an RTDM 
> IOCTL will be used to wait for the interrupts. This way I can have a 
> RT-thread to process the interrupts.
> 
> The reason for this setup are:
> 
>     * I do not want to rewrite the current driver, as this driver
>       already has all the functionality needed, except for the
>       RT-performance.
>     * The interface to VME devices is done using memory access and no
>       other SW is needed for this. This means that during operational
>       use no driver functions will be accessed.
>     * The memory mapping is not as straight forward in RTDM as it is in
>       standard Linux: for example there is no mmap function in the
>       device structure.

OK, noted. I will check again if we can do something about this on next
major RTDM rework. I'm considering to refactor typical non-RT entry
points of RTDM drivers anyway.

>     * I can still use drivers for VME devices that depend on the current
>       driver.
> 
> 
> Is this the right way to do this, or are there other ways to implement a 
> driver like this one?

RTDM is not about forcing you do make abstractions if you don't want to.
You say that you already have a (basic) driver model, and so it is fine
to apply it on top of RTDM as well. When RTDM is not optimally providing
services for this, we need to recheck it.

But if you wanted to make your device interface generic, maybe portable
to other hardware of that class, then things need to be looked at from a
different angle.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]