From: Jan Kiszka <jan.kiszka@domain.hid>
To: Johan Borkhuis <j.borkhuis@domain.hid>
Cc: Xenomai-help@domain.hid
Subject: Re: [Xenomai-help] Porting driver to RTDM
Date: Thu, 24 May 2007 10:01:09 +0200 [thread overview]
Message-ID: <46554645.90806@domain.hid> (raw)
In-Reply-To: <46543598.8030909@domain.hid>
[-- 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 --]
prev parent reply other threads:[~2007-05-24 8:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-23 12:37 [Xenomai-help] Porting driver to RTDM Johan Borkhuis
2007-05-24 8:01 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46554645.90806@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=Xenomai-help@domain.hid \
--cc=j.borkhuis@domain.hid \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.