From: Jan Kiszka <jan.kiszka@domain.hid>
To: "Merilainen, Jussi (GE Healthcare)" <jussi.merilainen@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] User-space DMA transfer and I/O access from Xenomai API
Date: Tue, 20 Jun 2006 13:11:46 +0200 [thread overview]
Message-ID: <4497D7F2.9090001@domain.hid> (raw)
In-Reply-To: <923F5E294B7B194EA41B7B11DAE5330B1A9F3990@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]
Merilainen, Jussi (GE Healthcare) wrote:
>
>
> I'm porting a PCI driver for a custom board from VxWorks to Xenomai/Linux. My goal is to keep the driver as much as possible in user-space. Implementing the HW interrupt handler should be quite straight forward as presented in 'Writing user-space device drivers' in Native-API-Tour manual.
> My concern is the PCI DMA transfer. Does the Xenomai API provide any support for this in user-space? Does anyone have experience on this subject?
Actually, this need not be a Xenomai-specific issue. User space device
drivers are of increasing common interest in the Linux community. I only
collected some projects so far, I did not dig into the APIs:
- libpci as part of the pciutils provides ways to access device
information, don't know if it also allows to map DMA memory to user
space.
- The Gelato project [1] developed some libs and kernel patches for user
level drivers.
- Don't know if it is related to the former, but this research project
[2] implemented user-level drivers as well.
- David Schleef's usddk [3] is another user space driver development
lib, but it looks a bit premature.
Why am I listing these? Xenomai is not providing PCI access functions,
and I'm not sure yet if it actually has to do this on its own (in user
space, in kernel definitely not). All init/cleanup work can perfectly
use standard Linux infrastructure - if there is one of course. Only
services which may need rescheduling in time-critical contexts (IRQ
handlers, RT tasks) have to be mapped on the Xenomai infrastructure.
Nevertheless, user space support for RTDM, Xenomai's driver model, is
planned, so I'm already collecting input on what services are
additionally required and may have to be provided by RTDM itself (and
not some third-party lib). So, if you find some solution or anyone else
has ideas, please let me know.
> Another thing is the Device I/O handling from user-space. Simple question: how do I perform read/write operations? In VxWorks, I have for example following function for reading an I/O register of the board:
> ...
On x86, iopl() or ioperm() opens in/out to a user space process. Memory
mapped I/O should be accessible via /dev/mem on any arch.
Jan
[1] http://www.gelato.unsw.edu.au/IA64wiki/UserLevelDrivers
[2] http://www.ertos.nicta.com.au/research/uldd/
[3] http://www.schleef.org/usddk/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2006-06-20 11:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 9:21 [Xenomai-core] User-space DMA transfer and I/O access from Xenomai API Merilainen, Jussi (GE Healthcare)
2006-06-20 11:11 ` Jan Kiszka [this message]
2006-06-20 11:30 ` Gilles Chanteperdrix
2006-06-20 11:43 ` Jan Kiszka
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=4497D7F2.9090001@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=jussi.merilainen@domain.hid \
--cc=xenomai@xenomai.org \
/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.