Yes, it seems to be the solution.
I performed the following patch and the problem is solved on my application
*** xenomai-2.5.4/include/native/heap.h 2010-06-16 14:31:04.000000000 +0200
--- xenomai-2.5.4_patchDMA32/include/native/heap.h 2010-10-13
15:40:01.000000000 +0200
***************
*** 34,39 ****
--- 34,40 ----
#define H_SINGLE 0x400 /* Manage as single-block area. */
#define H_SHARED (H_MAPPABLE|H_SINGLE) /* I.e. shared memory segment. */
#define H_NONCACHED 0x800
+ #define H_DMA32 0x1000 /* Use memory suitable for DMA32. */
/** Structure containing heap-information useful to users.
*
diff -crB xenomai-2.5.4/ksrc/skins/native/heap.c
xenomai-2.5.4_patchDMA32/ksrc/skins/native/heap.c
*** xenomai-2.5.4/ksrc/skins/native/heap.c 2010-05-18 20:31:16.000000000
+0200
--- xenomai-2.5.4_patchDMA32/ksrc/skins/native/heap.c 2010-10-13
15:40:24.000000000 +0200
***************
*** 205,210 ****
--- 205,215 ----
* operations with I/O devices. The physical address of the
* heap can be obtained by a call to rt_heap_inquire().
*
+ * - H_DMA32 causes the block pool associated to the heap to be
+ * allocated in physically contiguous memory, suitable for DMA32
+ * operations with I/O devices. The physical address of the
+ * heap can be obtained by a call to rt_heap_inquire().
+ *
* - H_NONCACHED causes the heap not to be cached. This is necessary on
* platforms such as ARM to share a heap between kernel and user-space.
* Note that this flag is not compatible with the H_DMA flag.
***************
*** 265,270 ****
--- 270,276 ----
err = xnheap_init_mapped(&heap->heap_base,
heapsize,
((mode & H_DMA) ? GFP_DMA : 0)
+ | ((mode & H_DMA32) ? GFP_DMA32 : 0)
| ((mode & H_NONCACHED) ?
XNHEAP_GFP_NONCACHED : 0));
if (err)
This patch or similar could be included in a next release.
Thanks for your help Gilles,
Regards
Jacques
-----Original Message-----
From: Gilles Chanteperdrix [mailto:[email protected]]
Sent: mercredi 13 octobre 2010 14:37
To: Daniel Jacques (Alten)
Cc: [email protected]
Subject: Re: [Xenomai-help] rt_heap and DMA32 zone
Daniel Jacques (Alten) wrote:
> Please find bellow and in attachment the requested information:
>
> Linux kernel: 2.6.32.15
> Adeos patch: adeos-ipipe-2.6.32.15-x86-2.7-01.patch
> Xenomai: 2.5.4
> Host Linux distribution: Based on Debian 5.0
> Compiler: gcc version 4.3.2
>
> Piece of code:
> #define HEAP_SIZE_IN_BYTES 16*1024*1024
> static int __init audioInit_module(void)
> {
> int status;
> RT_HEAP heap;
>
> ...
>
> /* Create the global heap */
> if( (status = rt_heap_create(&heap, "audioInputHeap", HEAP_SIZE_IN_BYTES,
> H_SHARED|H_DMA )) < 0 )
> {
> printk("rt_heap_create audioInputHeap error %d\n", status );
> return status;
> }
> else
> {
> printk ("Heap audioInputHeap created\n");
> }
>
> ...
>
> }
So, if I understand correctly, the problem is that Linux does not use
the DMA32 pool when it is passed the GFP_DMA flag? In that case, you
probably need an H_DMA32 flag, which get translated into GFP_DMA32 by
the rtheap code.
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
