El 11 de octubre de 2011 19:12, Alexis Berlemont <[email protected]
> escribió:
[...]


>  I took some time to compare both versions of code (comedi and
> analogy). I did not find anything interesting in mite.c. I was about
> to ask you to increase verbosity (debug + a specific patch) when I got
> a glimpse on the allocation of the asynchronous buffer on the comedi
> side.
>
> The methods are not the same at that level:
> - comedi: n * dma_alloc_coherent  + a vmap at the end
> - analogy:  a big vmalloc + n * page_to_phys(vmalloc_to_page(vaddr)
>

Hmmm, quoting http://www.mjmwired.net/kernel/Documentation/DMA-mapping.txt:


If you acquired your memory via the page allocator
(i.e. __get_free_page*()) or the generic memory allocators
(i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from
that memory using the addresses returned from those routines.

This means specifically that you may _not_ use the memory/addresses

returned from vmalloc() for DMA.  It is possible to DMA to the
_underlying_ memory mapped into a vmalloc() area, but this requires
walking page tables to get the physical addresses, and then

translating each of those pages back to a kernel address using
something like __va().  [ EDIT: Update this when we integrate
Gerd Knorr's generic code which does this. ]


So, I guess analogy indeed took the walking approach mentioned there? If I
understand it right, the following loop in "a4l_buf_alloc()":

for (vaddr = vabase; vaddr < vabase + buf_desc->size;
         vaddr += PAGE_SIZE)
        buf_desc->pg_list[(vaddr - vabase) >> PAGE_SHIFT] =
            (unsigned long) page_to_phys(vmalloc_to_page(vaddr));

does exactly this, by holding a list of the physical addresses of all the
logical pages of the buffer, even if they may be non-contiguous. Then, the
MITE is able to scatter data across the ring descriptors calculated in
a4l_mite_buf_change()? What is the benefit of using vmalloc? Copying from/to
user space is easier so?

According to my previous test, the addresses calculated are all indeed
larger than 2^32. This makes sense as well, since this machine appears to
have 6GB of memory:

[    0.000000] Memory: 5992084k/7208960k available (5325k kernel code,
919428k absent, 297448k reserved, 3285k data, 920k init)

The comedi drivers and kernel were not installed by myself, so reinstalling
them is somewhat more involved. If you still feel it would be useful to
check them out I will reinstall them, but this looks to me like the possible
source of the problem.

Best regards,
Fernando
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to