[Xenomai-help] RTDM mmap and DMA

[Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

Hi,

Currently, I write an RTDM module and I would like to do DMA and mmap to
perform transfers who have hard constraints.
I would like to know if there is an example in a driver who would help me to
do this.


Regards,
Perrine

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

Re: [Xenomai-help] RTDM mmap and DMA

[Stéphane ANCELOT]

Hi,
Do you need ONLY mmap call ?
Best Regards
Steph

Perrine Martignoni a écrit :
> Hi,
> 
> Currently, I write an RTDM module and I would like to do DMA and mmap to
> perform transfers who have hard constraints.
> I would like to know if there is an example in a driver who would help
> me to do this.
> 
> 
> Regards,
> Perrine
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] RTDM mmap and DMA

[Jan Kiszka]

Perrine Martignoni wrote:
> Hi,
> 
> Currently, I write an RTDM module and I would like to do DMA and mmap to
> perform transfers who have hard constraints.
> I would like to know if there is an example in a driver who would help me to
> do this.

There is code using the related rtdm_mmap_to_user service, but it is
unpublished. So let me sketch to basic patter:

1. Define some IOCTL that allocate the DMA area statically and maps it
   to the requesting user's address space with rtdm_mmap_to_user.

2. Register pieces of the DMA buffer with the hardware and let it
   perform the transfer

3. Signal the transfer completion to the user (who may be waiting on it
   in some other IOCTL)

4. The user signals via an IOCTL (may be the same as in 3.) that he's
   done with some piece of the buffer so that it can be reused with the
   hardware.

5. Goto 2.

HTH,
Jan

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

On Dec 18, 2007 10:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>
> Perrine Martignoni wrote:
> > Hi,
> >
> > Currently, I write an RTDM module and I would like to do DMA and mmap to
> > perform transfers who have hard constraints.
> > I would like to know if there is an example in a driver who would help me to
> > do this.
>
> There is code using the related rtdm_mmap_to_user service, but it is
> unpublished. So let me sketch to basic patter:
>
> 1. Define some IOCTL that allocate the DMA area statically and maps it
>    to the requesting user's address space with rtdm_mmap_to_user.
>
> 2. Register pieces of the DMA buffer with the hardware and let it
>    perform the transfer
>
> 3. Signal the transfer completion to the user (who may be waiting on it
>    in some other IOCTL)
>
> 4. The user signals via an IOCTL (may be the same as in 3.) that he's
>    done with some piece of the buffer so that it can be reused with the
>    hardware.
>
> 5. Goto 2.

A special note about ARM: to get DMA to work on ARM, you will need to
flush the cache before passing a buffer to hardware with data for
hardware, or invalidate the cache before passing the buffer to
hardware for the hardware to write data to it. That is because
peripherals, when they access processor RAM, do not access it through
the processor cache.

Another thing about ARMs is that most of them (the old ones, those
that everybody uses) have a VIVT cache, which means that if the same
piece of memory is mapped at two different different addresses, it has
a different cache depending on the virtual address used to address
this piec e of memory. Sharing memory between user-space processes
works because the context switch routine flushes the cache entirely
(ever wondered why the context switch took so long on ARM ?).

When you allocate a heap and map it in user-space, the heap is mapped
at two different addresses, one in kernel-space and one in user-space.
If you flush/invalidate the cache through the heap address in
kernel-space, it will not work, you have to invalidate/flush the cache
through the user-space address. And I do not think that calling the
cache invalidate/flush instructions from user-space will work, they
are probably privileged instructions.

So, the conclusion is that if you want your DMA to work, you will have
to invalidate/flush the cache in the method (probably ioctl ?)
triggering the DMA, using the user-space mapping address of the heap.
-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

>
> Sorry, I don't specify that I work on PowerQuick2Pro, no more on ARM.
>



>
>
> A special note about ARM: to get DMA to work on ARM, you will need to
> flush the cache before passing a buffer to hardware with data for
> hardware, or invalidate the cache before passing the buffer to
> hardware for the hardware to write data to it. That is because
> peripherals, when they access processor RAM, do not access it through
> the processor cache.
>
> Another thing about ARMs is that most of them (the old ones, those
> that everybody uses) have a VIVT cache, which means that if the same
> piece of memory is mapped at two different different addresses, it has
> a different cache depending on the virtual address used to address
> this piec e of memory. Sharing memory between user-space processes
> works because the context switch routine flushes the cache entirely
> (ever wondered why the context switch took so long on ARM ?).
>
> When you allocate a heap and map it in user-space, the heap is mapped
> at two different addresses, one in kernel-space and one in user-space.
> If you flush/invalidate the cache through the heap address in
> kernel-space, it will not work, you have to invalidate/flush the cache
> through the user-space address. And I do not think that calling the
> cache invalidate/flush instructions from user-space will work, they
> are probably privileged instructions.
>
> So, the conclusion is that if you want your DMA to work, you will have
> to invalidate/flush the cache in the method (probably ioctl ?)
> triggering the DMA, using the user-space mapping address of the heap.
> --
>                                               Gilles Chanteperdrix
>

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

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

On Dec 18, 2007 11:16 AM, Perrine Martignoni <perrmart@domain.hid> wrote:
>
> >
> >
> > Sorry, I don't specify that I work on PowerQuick2Pro, no more on ARM.

Good for you !


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

Thanks for the explanation.
But how can I do to allocate the DMA area ? with the Dma-api of Linux or
Xenomai offers the possibility to do this ? and what about memory heap with
H_DMA ?
I'm a bit confused with all of this.

On Dec 18, 2007 10:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:

> Perrine Martignoni wrote:
> > Hi,
> >
> > Currently, I write an RTDM module and I would like to do DMA and mmap to
> > perform transfers who have hard constraints.
> > I would like to know if there is an example in a driver who would help
> me to
> > do this.
>
> There is code using the related rtdm_mmap_to_user service, but it is
> unpublished. So let me sketch to basic patter:
>
> 1. Define some IOCTL that allocate the DMA area statically and maps it
>   to the requesting user's address space with rtdm_mmap_to_user.
>
> 2. Register pieces of the DMA buffer with the hardware and let it
>   perform the transfer
>
> 3. Signal the transfer completion to the user (who may be waiting on it
>   in some other IOCTL)
>
> 4. The user signals via an IOCTL (may be the same as in 3.) that he's
>   done with some piece of the buffer so that it can be reused with the
>   hardware.
>
> 5. Goto 2.
>
> HTH,
> Jan
>
>

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

Re: [Xenomai-help] RTDM mmap and DMA

[Jan Kiszka]

Perrine Martignoni wrote:
> Thanks for the explanation.
> But how can I do to allocate the DMA area ? with the Dma-api of Linux or
> Xenomai offers the possibility to do this ? and what about memory heap with
> H_DMA ?
> I'm a bit confused with all of this.

Yes, allocation and registration (pci_map*/pci_unmap*) is intended to
run via normal Linux. H_DMA (if you were using heaps here), which leads
to GFP_DMA, is only involved for old ISA hardware.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

On Dec 18, 2007 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> Perrine Martignoni wrote:
> > Thanks for the explanation.
> > But how can I do to allocate the DMA area ? with the Dma-api of Linux or
> > Xenomai offers the possibility to do this ? and what about memory heap with
> > H_DMA ?
> > I'm a bit confused with all of this.
>
> Yes, allocation and registration (pci_map*/pci_unmap*) is intended to
> run via normal Linux. H_DMA (if you were using heaps here), which leads
> to GFP_DMA, is only involved for old ISA hardware.

GFP_DMA may also make a big difference on some ARMs. See
arch/arm/common/dmabounce.c for details.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

So, if I understand, I have to use the Dma Api of Linux (linux/dma-mapping.h)
to allocate a dma buffer and then call rtdm_mmap_to_user to map it in user
space.
Isn't it disadvantageous to do it in regular Linux ?


On Dec 18, 2007 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:

> Perrine Martignoni wrote:
> > Thanks for the explanation.
> > But how can I do to allocate the DMA area ? with the Dma-api of Linux or
> > Xenomai offers the possibility to do this ? and what about memory heap
> with
> > H_DMA ?
> > I'm a bit confused with all of this.
>
> Yes, allocation and registration (pci_map*/pci_unmap*) is intended to
> run via normal Linux. H_DMA (if you were using heaps here), which leads
> to GFP_DMA, is only involved for old ISA hardware.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>

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

Re: [Xenomai-help] RTDM mmap and DMA

[Jan Kiszka]

Perrine Martignoni wrote:
> So, if I understand, I have to use the Dma Api of Linux (linux/dma-mapping.h)
> to allocate a dma buffer and then call rtdm_mmap_to_user to map it in user
> space.
> Isn't it disadvantageous to do it in regular Linux ?

Of course, memory allocation and releasing must never happen over RT
context, but rather during (non-RT) open/close etc.

Mapping/unmapping is a trivial and safe operation on many archs, but not
on all (beware of some IOMMU being involved, then mapping becomes
indeterministic). If unsure, check for your target if it is running
through complex and potentially memory-allocating code paths, e.g. via
lxr.linux.no. If there are problems (not expected on today's mid- to
low-end HW), you have to manage also the mappings during init and keep
them during runtime. Standard pattern for RT development.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

Ok thanks.

On Dec 18, 2007 3:22 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:

> Perrine Martignoni wrote:
> > So, if I understand, I have to use the Dma Api of Linux (linux/dma-
> mapping.h)
> > to allocate a dma buffer and then call rtdm_mmap_to_user to map it in
> user
> > space.
> > Isn't it disadvantageous to do it in regular Linux ?
>
> Of course, memory allocation and releasing must never happen over RT
> context, but rather during (non-RT) open/close etc.
>
> Mapping/unmapping is a trivial and safe operation on many archs, but not
> on all (beware of some IOMMU being involved, then mapping becomes
> indeterministic). If unsure, check for your target if it is running
> through complex and potentially memory-allocating code paths, e.g. via
> lxr.linux.no. If there are problems (not expected on today's mid- to
> low-end HW), you have to manage also the mappings during init and keep
> them during runtime. Standard pattern for RT development.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>

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

Re: [Xenomai-help] RTDM mmap and DMA

[Fillod Stephane]

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

Perrine Martignoni wrote:
>Currently, I write an RTDM module and I would like to do DMA and mmap
to perform transfers who have hard constraints.
>I would like to know if there is an example in a driver who would help
me to do this.

I'm looking for the same need, except I'm not using RTDM, and everything
is in userland. Using the attached patch against Xenomai 2.4.0, I hope
to make it to work with something like this:

        RT_HEAP_INFO info;
        RT_HEAP heap;
        void *user_addr;	/* DMA buffer, user access */
        unsigned long dma_addr;	/* for use with the DMA controller */

        /* Allocate memory, suitable for DMA. This occurs before
entering RT land. */
        err = rt_heap_create (&heap,
                        name,
                        heapsz,
                        H_SHARED|H_DMA);
        if (err) { /* ... */ }

        err = rt_heap_alloc (&heap, 0, TM_INFINITE, &user_addr);
        if (err) { /* ... */ }

        err = rt_heap_inquire (&heap, &info);
        if (err) { /* ... */ }

        dma_addr = info.phys_addr;

Any comments?
-- 
Stephane

[-- Attachment #2: heap_dma.patch --]
[-- Type: application/octet-stream, Size: 1633 bytes --]

--- ksrc/nucleus/heap.c	8 Dec 2007 09:15:19 -0000	1.1.1.5
+++ ksrc/nucleus/heap.c	14 Dec 2007 13:36:16 -0000
@@ -1180,7 +1180,15 @@
 		 * space. Assume that we can wait to get the required memory.
 		 */
 
-		ptr = kmalloc(size, kmflags | GFP_KERNEL);
+#define MAX_KMALLOC_SIZE (128*1024)
+		if (size <= MAX_KMALLOC_SIZE)
+			ptr = kmalloc(size, kmflags | GFP_KERNEL);
+		else {
+			unsigned long order;
+			for (order = 0; ((1UL << order) << PAGE_SHIFT) < size; order++)
+				;
+			ptr = (void*) __get_free_pages(kmflags | GFP_KERNEL, order);
+		}
 
 		if (!ptr)
 			return NULL;
@@ -1212,7 +1220,14 @@
 		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
 			ClearPageReserved(virt_to_page(vaddr));
 
-		kfree(ptr);
+		if (size <= MAX_KMALLOC_SIZE)
+			kfree(ptr);
+		else {
+			unsigned long order;
+			for (order = 0; ((1UL << order) << PAGE_SHIFT) < size; order++)
+				;
+			free_pages((unsigned long)ptr, order);
+		}
 	}
 }
 
--- ksrc/skins/native/heap.c	10 Dec 2007 09:59:07 -0000	1.5
+++ ksrc/skins/native/heap.c	14 Dec 2007 13:36:16 -0000
@@ -730,6 +730,7 @@
 	info->usablemem = xnheap_usable_mem(&heap->heap_base);
 	info->usedmem = xnheap_used_mem(&heap->heap_base);
 	info->mode = heap->mode;
+	info->phys_addr = (heap->mode & H_SINGLE) ? virt_to_phys(heap->sba):0;
 
       unlock_and_exit:
 
--- include/native/heap.h	25 Nov 2007 16:50:04 -0000	1.1.1.3
+++ include/native/heap.h	14 Dec 2007 13:36:29 -0000
@@ -48,6 +48,8 @@
 
     char name[XNOBJECT_NAME_LEN]; /* !< Symbolic name. */
 
+    unsigned long phys_addr;	/* !< Physical address. */
+
 } RT_HEAP_INFO;
 
 typedef struct rt_heap_placeholder {

Re: [Xenomai-help] RTDM mmap and DMA

[Perrine Martignoni]

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

I don't know how memory heaps really work but it seems that memory heaps are
shared between user and kernel spaces.
So, if I do like this I don't need mmap, am I wrong ?
How is done the DMA transfer after ?

Thanks

On Dec 14, 2007 2:59 PM, Fillod Stephane <stephane.fillod@domain.hid>
wrote:

> Perrine Martignoni wrote:
> >Currently, I write an RTDM module and I would like to do DMA and mmap
> to perform transfers who have hard constraints.
> >I would like to know if there is an example in a driver who would help
> me to do this.
>
> I'm looking for the same need, except I'm not using RTDM, and everything
> is in userland. Using the attached patch against Xenomai 2.4.0, I hope
> to make it to work with something like this:
>
>        RT_HEAP_INFO info;
>        RT_HEAP heap;
>        void *user_addr;        /* DMA buffer, user access */
>        unsigned long dma_addr; /* for use with the DMA controller */
>
>        /* Allocate memory, suitable for DMA. This occurs before
> entering RT land. */
>        err = rt_heap_create (&heap,
>                        name,
>                        heapsz,
>                        H_SHARED|H_DMA);
>        if (err) { /* ... */ }
>
>        err = rt_heap_alloc (&heap, 0, TM_INFINITE, &user_addr);
>        if (err) { /* ... */ }
>
>        err = rt_heap_inquire (&heap, &info);
>        if (err) { /* ... */ }
>
>        dma_addr = info.phys_addr;
>
> Any comments?
> --
> Stephane
>

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

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

Fillod Stephane wrote:
 > Perrine Martignoni wrote:
 > >Currently, I write an RTDM module and I would like to do DMA and mmap
 > to perform transfers who have hard constraints.
 > >I would like to know if there is an example in a driver who would help
 > me to do this.
 > 
 > I'm looking for the same need, except I'm not using RTDM, and everything
 > is in userland. Using the attached patch against Xenomai 2.4.0, I hope
 > to make it to work with something like this:
 > 
 >         RT_HEAP_INFO info;
 >         RT_HEAP heap;
 >         void *user_addr;	/* DMA buffer, user access */
 >         unsigned long dma_addr;	/* for use with the DMA controller */
 > 
 >         /* Allocate memory, suitable for DMA. This occurs before
 > entering RT land. */
 >         err = rt_heap_create (&heap,
 >                         name,
 >                         heapsz,
 >                         H_SHARED|H_DMA);
 >         if (err) { /* ... */ }
 > 
 >         err = rt_heap_alloc (&heap, 0, TM_INFINITE, &user_addr);
 >         if (err) { /* ... */ }
 > 
 >         err = rt_heap_inquire (&heap, &info);
 >         if (err) { /* ... */ }
 > 
 >         dma_addr = info.phys_addr;
 > 
 > Any comments?

You patch looks OK. However, a small detail: can not we use the constant
KMALLOC_MAX_SIZE defined in linux/slab.h instead of defining our own
constant ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 568 bytes --]

Fillod Stephane wrote:
 > Perrine Martignoni wrote:
 > >Currently, I write an RTDM module and I would like to do DMA and mmap
 > to perform transfers who have hard constraints.
 > >I would like to know if there is an example in a driver who would help
 > me to do this.
 > 
 > I'm looking for the same need, except I'm not using RTDM, and everything
 > is in userland. Using the attached patch against Xenomai 2.4.0, I hope
 > to make it to work with something like this:

I propose the attached modifications. Is it Ok for you ?

-- 


					    Gilles Chanteperdrix.

[-- Attachment #2: heap_dma.2.patch --]
[-- Type: text/plain, Size: 2263 bytes --]

Index: ksrc/nucleus/heap.c
===================================================================
--- ksrc/nucleus/heap.c	(revision 3301)
+++ ksrc/nucleus/heap.c	(working copy)
@@ -1180,7 +1180,11 @@
 		 * space. Assume that we can wait to get the required memory.
 		 */
 
-		ptr = kmalloc(size, kmflags | GFP_KERNEL);
+		if (size <= KMALLOC_MAX_SIZE)
+			ptr = kmalloc(size, kmflags | GFP_KERNEL);
+		else
+			ptr = (void*) __get_free_pages(kmflags | GFP_KERNEL,
+						       get_order(size));
 
 		if (!ptr)
 			return NULL;
@@ -1212,7 +1216,10 @@
 		for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
 			ClearPageReserved(virt_to_page(vaddr));
 
-		kfree(ptr);
+		if (size <= KMALLOC_MAX_SIZE)
+			kfree(ptr);
+		else
+			free_pages((unsigned long)ptr, get_order(size));
 	}
 }
 
Index: ksrc/skins/native/heap.c
===================================================================
--- ksrc/skins/native/heap.c	(revision 3301)
+++ ksrc/skins/native/heap.c	(working copy)
@@ -730,6 +730,7 @@
 	info->usablemem = xnheap_usable_mem(&heap->heap_base);
 	info->usedmem = xnheap_used_mem(&heap->heap_base);
 	info->mode = heap->mode;
+	info->phys_addr = (heap->mode & H_SINGLE) ? virt_to_phys(heap->sba):0;
 
       unlock_and_exit:
 
Index: include/native/heap.h
===================================================================
--- include/native/heap.h	(revision 3301)
+++ include/native/heap.h	(working copy)
@@ -48,6 +48,8 @@
 
     char name[XNOBJECT_NAME_LEN]; /* !< Symbolic name. */
 
+    unsigned long phys_addr;	/* !< Physical address. */
+
 } RT_HEAP_INFO;
 
 typedef struct rt_heap_placeholder {
Index: include/asm-generic/wrappers.h
===================================================================
--- include/asm-generic/wrappers.h	(revision 3301)
+++ include/asm-generic/wrappers.h	(working copy)
@@ -27,6 +27,7 @@
 
 #include <linux/version.h>
 #include <linux/module.h>
+#include <linux/slab.h>
 #include <asm/io.h>
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
@@ -281,4 +282,8 @@
 #define trace_mark(ev, fmt, args...)	do { } while (0)
 #endif /* CONFIG_MARKERS */
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)
+#define KMALLOC_MAX_SIZE 131072
+#endif /* !KMALLOC_MAX_SIZE */
+
 #endif /* _XENO_ASM_GENERIC_WRAPPERS_H */

Re: [Xenomai-help] RTDM mmap and DMA

[Fillod Stephane]

Perrine Martignoni wrote:
> I don't know how memory heaps really work but it seems that memory
heaps are shared between user and kernel spaces.
> So, if I do like this I don't need mmap, am I wrong ?

Indeed. rt_heap's take care of mmap'ing as long as the H_MAPPABLE is
set.

http://www.xenomai.org/documentation/trunk/html/api/group__native__heap.
html

>How is done the DMA transfer after ?

You're the only one who knows how to program your DMA (i.e. read your
chip reference
manual). Generally, embedded DMA only "speak" physical addresses. Hence
the patch
sent previously in this discussion.
-- 
Stephane

Re: [Xenomai-help] RTDM mmap and DMA

[Fillod Stephane]

Gilles Chanteperdrix wrote:
>On Dec 18, 2007 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Perrine Martignoni wrote:
>> > Thanks for the explanation.
>> > But how can I do to allocate the DMA area ? with the Dma-api of
Linux or
>> > Xenomai offers the possibility to do this ? and what about memory
heap with
>> > H_DMA ?
>> > I'm a bit confused with all of this.
>>
>> Yes, allocation and registration (pci_map*/pci_unmap*) is intended to
>> run via normal Linux. H_DMA (if you were using heaps here), which
leads
>> to GFP_DMA, is only involved for old ISA hardware.
>
>GFP_DMA may also make a big difference on some ARMs. See
>arch/arm/common/dmabounce.c for details.

Not only ARMs. The H_DMA flag appears to work fine with PowerPCs (PQ).
This is quite 
handy in order to obtain physically contiguous memory, from a user task
context. 
The question though is whether there's the below 16 MB address mask in
action,
which is kind of stupid most of the time on embedded PowerPCs.
The patch I sent previously about rt_heap_inquire is also useful to get 
the physical address of the buffer (hint hint: care to commit it?),
which
is needed by most embedded DMAs.

-- 
Stephane

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

On Dec 18, 2007 6:40 PM, Fillod Stephane <stephane.fillod@domain.hid> wrote:
> Gilles Chanteperdrix wrote:
> >On Dec 18, 2007 1:47 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> >> Perrine Martignoni wrote:
> >> > Thanks for the explanation.
> >> > But how can I do to allocate the DMA area ? with the Dma-api of
> Linux or
> >> > Xenomai offers the possibility to do this ? and what about memory
> heap with
> >> > H_DMA ?
> >> > I'm a bit confused with all of this.
> >>
> >> Yes, allocation and registration (pci_map*/pci_unmap*) is intended to
> >> run via normal Linux. H_DMA (if you were using heaps here), which
> leads
> >> to GFP_DMA, is only involved for old ISA hardware.
> >
> >GFP_DMA may also make a big difference on some ARMs. See
> >arch/arm/common/dmabounce.c for details.
>
> Not only ARMs. The H_DMA flag appears to work fine with PowerPCs (PQ).
> This is quite
> handy in order to obtain physically contiguous memory, from a user task
> context.

> The question though is whether there's the below 16 MB address mask in
> action,
> which is kind of stupid most of the time on embedded PowerPCs.

The way I understand the GFP_DMA flags, its aim is not to obtain
physically contiguous memory, memory obtained with get_free_pages is
always contiguous anyway. The aim seems rather to allocate in a
machine dependent memory zone that will allow memory to be used for
DMA (for example, allocating it below a 16 MB limit).

> The patch I sent previously about rt_heap_inquire is also useful to get
> the physical address of the buffer (hint hint: care to commit it?),
> which
> is needed by most embedded DMAs.

I have not looked at the patch, but I think that it is indeed a good
idea to have a way to obtain the physical address of a heap.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] RTDM mmap and DMA

[Fillod Stephane]

Gilles Chanteperdrix wrote:
>Fillod Stephane wrote:
> > Perrine Martignoni wrote:
> > >Currently, I write an RTDM module and I would like to do DMA and
mmap
> > to perform transfers who have hard constraints.
> > >I would like to know if there is an example in a driver who would
help
> > me to do this.
> > 
> > I'm looking for the same need, except I'm not using RTDM, and
everything
> > is in userland. Using the attached patch against Xenomai 2.4.0, I
hope
> > to make it to work with something like this:
>
>I propose the attached modifications. Is it Ok for you ?

Yes, your patch is much cleaner, esp. wrt KMALLOC_MAX_SIZE which I was
not aware of.

The documentation needs an update, and a link to RT_HEAP_INFO.
Does any Doxygen guru knows how to make rt_heap_inquire a hyperlink
in the above chunk?

--- ksrc/skins/native/heap.c    17 Dec 2007 14:36:15 -0000      1.6
+++ ksrc/skins/native/heap.c    27 Dec 2007 15:23:06 -0000
@@ -201,8 +201,8 @@
  *
  * - H_DMA causes the block pool associated to the heap to be
  * allocated in physically contiguous memory, suitable for DMA
- * operations with I/O devices. A 128Kb limit exists for @a heapsize
- * when this flag is passed.
+ * operations with I/O devices. The physical address of the
+ * heap can be obtained by a call to rt_heap_inquire.
  *
  * @return 0 is returned upon success. Otherwise:
  *
--- include/native/heap.h       17 Dec 2007 14:36:09 -0000      1.2
+++ include/native/heap.h       27 Dec 2007 15:34:22 -0000
@@ -34,6 +34,10 @@
 #define H_SINGLE   0x400       /* Manage as single-block area. */
 #define H_SHARED   (H_MAPPABLE|H_SINGLE) /* I.e. shared memory segment.
*/

+/** Structure containing heap-information useful to users.
+ *
+ *  @see rt_heap_inquire()
+ */
 typedef struct rt_heap_info {

     int nwaiters;              /* !< Number of pending tasks. */

Thanks!
-- 
Stephane

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

On Dec 27, 2007 4:39 PM, Fillod Stephane <stephane.fillod@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
> >Fillod Stephane wrote:
> > > Perrine Martignoni wrote:
> > > >Currently, I write an RTDM module and I would like to do DMA and
> mmap
> > > to perform transfers who have hard constraints.
> > > >I would like to know if there is an example in a driver who would
> help
> > > me to do this.
> > >
> > > I'm looking for the same need, except I'm not using RTDM, and
> everything
> > > is in userland. Using the attached patch against Xenomai 2.4.0, I
> hope
> > > to make it to work with something like this:
> >
> >I propose the attached modifications. Is it Ok for you ?
>
> Yes, your patch is much cleaner, esp. wrt KMALLOC_MAX_SIZE which I was
> not aware of.
>
> The documentation needs an update, and a link to RT_HEAP_INFO.
> Does any Doxygen guru knows how to make rt_heap_inquire a hyperlink
> in the above chunk?

I seem to remember that you have to write ::rt_heap_inquire or rt_heap_inquire()

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] RTDM mmap and DMA

[Gilles Chanteperdrix]

Fillod Stephane wrote:
 > Gilles Chanteperdrix wrote:
 > >Fillod Stephane wrote:
 > > > Perrine Martignoni wrote:
 > > > >Currently, I write an RTDM module and I would like to do DMA and
 > mmap
 > > > to perform transfers who have hard constraints.
 > > > >I would like to know if there is an example in a driver who would
 > help
 > > > me to do this.
 > > > 
 > > > I'm looking for the same need, except I'm not using RTDM, and
 > everything
 > > > is in userland. Using the attached patch against Xenomai 2.4.0, I
 > hope
 > > > to make it to work with something like this:
 > >
 > >I propose the attached modifications. Is it Ok for you ?
 > 
 > Yes, your patch is much cleaner, esp. wrt KMALLOC_MAX_SIZE which I was
 > not aware of.
 > 
 > The documentation needs an update, and a link to RT_HEAP_INFO.
 > Does any Doxygen guru knows how to make rt_heap_inquire a hyperlink
 > in the above chunk?

Ok. I merged the patch I sent, as well as this patch (fixed to make
rt_heap_inquire a hyperlink) in trunk. However, I did not commit it in
the v2.[34].x branch, since it is a patch which breaks the ABI (size of
the rt_heap_info structure changes). Should I increment the ABI revision
?

 > 
 > --- ksrc/skins/native/heap.c    17 Dec 2007 14:36:15 -0000      1.6
 > +++ ksrc/skins/native/heap.c    27 Dec 2007 15:23:06 -0000
 > @@ -201,8 +201,8 @@
 >   *
 >   * - H_DMA causes the block pool associated to the heap to be
 >   * allocated in physically contiguous memory, suitable for DMA
 > - * operations with I/O devices. A 128Kb limit exists for @a heapsize
 > - * when this flag is passed.
 > + * operations with I/O devices. The physical address of the
 > + * heap can be obtained by a call to rt_heap_inquire.
 >   *
 >   * @return 0 is returned upon success. Otherwise:
 >   *
 > --- include/native/heap.h       17 Dec 2007 14:36:09 -0000      1.2
 > +++ include/native/heap.h       27 Dec 2007 15:34:22 -0000
 > @@ -34,6 +34,10 @@
 >  #define H_SINGLE   0x400       /* Manage as single-block area. */
 >  #define H_SHARED   (H_MAPPABLE|H_SINGLE) /* I.e. shared memory segment.
 > */

Beware: your mailer broke your patch by adding a newline. It may be a
better idea to send the patch as a plain text attachment, it avoids such
surprises. I have already seen a site explaining how to teach your
mailer not to do this, but I do not have the URL at hand.

 > 
 > +/** Structure containing heap-information useful to users.
 > + *
 > + *  @see rt_heap_inquire()
 > + */
 >  typedef struct rt_heap_info {
 > 
 >      int nwaiters;              /* !< Number of pending tasks. */
 > 
 > Thanks!
 > -- 
 > Stephane


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] RTDM mmap and DMA

[Fillod Stephane]

Gilles Chanteperdrix wrote:
[...]
> Ok. I merged the patch I sent, as well as this patch (fixed to make
> rt_heap_inquire a hyperlink) in trunk. However, I did not commit it in
> the v2.[34].x branch, since it is a patch which breaks the ABI (size
of
> the rt_heap_info structure changes). Should I increment the ABI
revision
?

Albeit it is a minor ABI break, I guess this is the policy expected by 
Xenomai dev.

> Beware: your mailer broke your patch by adding a newline. It may be a
> better idea to send the patch as a plain text attachment, it avoids
such
> surprises. I have already seen a site explaining how to teach your
> mailer not to do this, but I do not have the URL at hand.

Sorry about that. My MUA is a corporate crap, not even able to respect
the References: field. I'll make sure to always use attached files in
the future.
-- 
Stephane