All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
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:43:52 +0200	[thread overview]
Message-ID: <4497DF78.7020508@domain.hid> (raw)
In-Reply-To: <17559.56387.507326.790229@domain.hid>

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > 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.
> 
> libpci allow user-space to retrieve the bus addresses of memory
> regions of each PCI device. Mmaping this memory may be done using
> /dev/mem. But usually, PCI devices do DMA the other way around: they are
> passed the physical address of some RAM, become bus-master and write
> directly to this RAM. So what is needed is:
> - to map some physically contiguous RAM region to user-space;
> - get the physical addres of this region in order to pass it to the PCI
>   device to program the DMA.
> 
> Xenomai allow you to map to user-space some physically contiguous RAM
> region (using either native heaps or posix shared memory smaller than
> 128K), but does not provide accessors to the RAM physical
> address. Is it what you need ?
> 

I think we are primarily looking for some user space
dma_map_*/dma_unmap_* support here - which also has to be RT-safe.

Jan


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

      reply	other threads:[~2006-06-20 11:43 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
2006-06-20 11:30   ` Gilles Chanteperdrix
2006-06-20 11:43     ` 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=4497DF78.7020508@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --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.