Driver for device behind a PCI-VME bridge

Driver for device behind a PCI-VME bridge

[Konstantin Boyanov]

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

Hi list,

I'm currently reading the LDD 3rd Edition and trying to create a device
driver for a custom device located on VME bus. I have already linux
2.6.15running on the master board, as well as the device driver for
the PCI-VME
bridge. The main problem I have is understanding how to "attach" my driver
for the custom device to the bridge device driver.
The bridge device driver is implemented as a class, i.e. doesn't define a
new bus type. Should I define a new class for my driver, or should I connect
it somehow to the existing one (maybe by something as "subclass")?
All I want to do is to redirect I/O reads and writes to the VME bus, but I
got no clue as to how to use the existing VME bridge driver for this
purpose. After I get through this I think all other things (VME interrupt
registration & handling, etc.) will be straightforward.
The LDD 3rd book states that defining a new bus type is the last thing one
would like to do, instead defining a class is far better approach. Why is
that?

Any recommendations and sharing of practical experience are highly
appreciated.

Best Regards,
Konstantin

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

Re: Driver for device behind a PCI-VME bridge

[Johan Borkhuis]

Hello Konstantin,

Konstantin Boyanov wrote:
> Hi list,
>
> I'm currently reading the LDD 3rd Edition and trying to create a 
> device driver for a custom device located on VME bus. I have already 
> linux 2.6.15 running on the master board, as well as the device driver 
> for the PCI-VME bridge. The main problem I have is understanding how 
> to "attach" my driver for the custom device to the bridge device driver.
> The bridge device driver is implemented as a class, i.e. doesn't 
> define a new bus type. Should I define a new class for my driver, or 
> should I connect it somehow to the existing one (maybe by something as 
> "subclass")?
> All I want to do is to redirect I/O reads and writes to the VME bus, 
> but I got no clue as to how to use the existing VME bridge driver for 
> this purpose. After I get through this I think all other things (VME 
> interrupt registration & handling, etc.) will be straightforward.
> The LDD 3rd book states that defining a new bus type is the last thing 
> one would like to do, instead defining a class is far better approach. 
> Why is that?
>
> Any recommendations and sharing of practical experience are highly 
> appreciated.
I am also working on a VME-board. What I did was use mmap to map 
specific parts of the VME-memory into user space.

BTW: what kind of board and Linux-flavor are you using?

Kind regards,
    Johan Borkhuis

Re: Driver for device behind a PCI-VME bridge

[Konstantin Boyanov]

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

Hi Johan,

I already went through the user space stuff with the help of other people on
this list, but now I want to do reads and writes in kernel space, in other
words on driver level.
Main reason for the development of a driver for the device is interrupt
handling and signal sending to user space processes by the custom device in
short time frames (within miliseconds), e.g. proper and fast respond is
crutial. But for now I don't know how to do a simple read/write...

I'm using MVME6100 with ELinOS-based distro, kernel 2.6.15.

Regards,
Konstantin

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

Re: Driver for device behind a PCI-VME bridge

[Konstantin Boyanov]

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

Hi again,

After some googling I came to the conclusion that the best approach to
understanding how to write a driver for a device behind a PCI-XXX bridge is
to look at the source for the USB subsystem, although the USB subsystem is
actually a bus subssytem and not a class.

Correct me if I'm wrong.

Regards,
Konstantin

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

Re: Driver for device behind a PCI-VME bridge

[Johan Borkhuis]

Konstantin Boyanov wrote:
>
> Hi again,
>  
> After some googling I came to the conclusion that the best approach to 
> understanding how to write a driver for a device behind a PCI-XXX 
> bridge is to look at the source for the USB subsystem, although the 
> USB subsystem is actually a bus subssytem and not a class.

I also work with devices on the VME bus. The approach we took is to map 
all the devices into userspace, and use Xenomai for RT performance. This 
avoids the need to write drivers for all the devices. The RT-performance 
of Xenomai is quite good: the jitter on a timer-interrupt is always less 
than 20usec, even under high load, where standard Linux only achieves 
this in a no load situatieo, under high load standard Linux has a jitter 
of over 10 msec.

The setup we choose was to have a RT-interrupt handler and a RT IOCTL 
call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the 
Motorola driver (I guess that you also use the Tundra chipset to access 
the VME-bus). Here you can wait for a specific VME interrupt-level, and 
it returns the vector number. So you can have several applications 
connect to the same VME driver, but all on different levels.

Kind regards,
    Johan Borkhuis

Re: Driver for device behind a PCI-VME bridge

[Konstantin Boyanov]

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

Hi again,

I also work with devices on the VME bus. The approach we took is to map
> all the devices into userspace, and use Xenomai for RT performance. This
> avoids the need to write drivers for all the devices. The RT-performance
> of Xenomai is quite good: the jitter on a timer-interrupt is always less
> than 20usec, even under high load, where standard Linux only achieves
> this in a no load situatieo, under high load standard Linux has a jitter
> of over 10 msec.


Good advice, I will investigate in this direction.

The setup we choose was to have a RT-interrupt handler and a RT IOCTL
> call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the
> Motorola driver (I guess that you also use the Tundra chipset to access
> the VME-bus).


Yes, I do. It is the Tsi148 in fact. I'll be interested to see some sample
code of yours, if it doesn't violate some restrictions ofcourse.

Here you can wait for a specific VME interrupt-level, and
> it returns the vector number. So you can have several applications
> connect to the same VME driver, but all on different levels.


So, if I understand you correctly, you altered the Motorola driver in order
for it to be able to communicate with user spae programms through Xenomai.
Which version of Xenomai ws that? I tried to test Xemonai 2.0 on my setup
but it iterfred somehow with SSH configuration and thats why i dropped it.

Many thanks,
Konstantin

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

Re: Driver for device behind a PCI-VME bridge

[Konstantin Boyanov]

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

Hi again,

First of all thanks for reply.


> I attached a diff to the 3.7 version of the Motorola patch. I hope this
> will help you. This is not the Xenomai version, but the standard version
> with VME interrupts per level. The mechanism for Xenomai is identical,
> but I don't know yet about the legal status of this. The attached patch
> has also been provided to Motorola.


I've got the 3.5 version of the driver, and tried to find newer one. Where
do you get this new releases and patches?
Nevertheless thanks for the patch.

I also had some ssh problems, but AFAICR I had to enable UNIX98PTYS and
> BSDPTYS, and create the entries in /dev/ for the BSD ptys (/dev/ttypXX
> and /dev/ptyXX).


I also had these two options enabled, but still the kernel hangs at boot
time just after trying to initialize SCSI devices... Without Xenomai this
problem doesn't occur. I'm wondering what is that makes Xenomai mess up
things so badly?

Best regards,
Konstantin Boyanov

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

Re: Driver for device behind a PCI-VME bridge

[Johan Borkhuis]

Konstantin Boyanov wrote:
> Hi again,
>  
> First of all thanks for reply.
>  
>
>     I attached a diff to the 3.7 version of the Motorola patch. I hope
>     this
>     will help you. This is not the Xenomai version, but the standard
>     version
>     with VME interrupts per level. The mechanism for Xenomai is identical,
>     but I don't know yet about the legal status of this. The attached
>     patch
>     has also been provided to Motorola.
>
>  
> I've got the 3.5 version of the driver, and tried to find newer one. 
> Where do you get this new releases and patches?
> Nevertheless thanks for the patch.

We got this patch directly from Motorola. Officially Motorola does not 
support Linux, but you can ask Ajit Prem (Ajit.Prem@motorola.com) for 
the latest version of the patch. As far as I know there is a patch 
availeble for 2.6.14 and 2.6.20, but as you have a patch for 2.6.15 
already it should not be to difficult to move the 2.6.14 patch to 2.6.15.

>
>     I also had some ssh problems, but AFAICR I had to enable
>     UNIX98PTYS and
>     BSDPTYS, and create the entries in /dev/ for the BSD ptys
>     (/dev/ttypXX
>     and /dev/ptyXX).
>
>  
> I also had these two options enabled, but still the kernel hangs at 
> boot time just after trying to initialize SCSI devices... Without 
> Xenomai this problem doesn't occur. I'm wondering what is that makes 
> Xenomai mess up things so badly?

I did not try SCSI on my system I just disabled all devices that I don't 
need, including SCSI. You could try disabling these devices for the 
moment (or build them as modules and load these later by hand) and see 
if that works, or that there are other problems.
If the problem is still there, you could try the Xenomai mailing list 
(see www.xenomai.org).

Kind regards,
    Johan Borkhuis

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