• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 929 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/TDA2: Cannot EDMA transfer between OSA_memAllocSR() and aligned_alloc() allocated buffers

Nick Cage
Intellectual 730 points
Part Number: TDA2


Tool/software: Linux

Hello, I'm using Processor SDK 3.03, building for custom board with TDA2 chip.

So far I have successfully transferred data between two buffers allocated using OSA_memAllocSR() in a PSDK usecase. I did this by calling OSA_memVirt2Phys() to get physical addresses of those buffers and forwarded that information to an EDMA utility driver that I've written. Now, I need to transfer data between a buffer allocated with OSA_memAllocSR() and a buffer allocated with aligned_alloc() from POSIX. However, I don't know how to get physical address of the one allocated with aligned_alloc(). I would like to know how it could be done so that the EDMA transfer can work.

Thank you in advance.

Regards,

Nick

  • 0
    TI__Genius 14650 points
    Hi,

    What you're trying to achieve isn't possible through a simple aligned_alloc() call. The aligned_alloc call provides a scattered list, which isn't continous. You need a special allocator such as a CMA which provides a continuous memory region. Please refer this link for more information.

    lwn.net/.../

    The reason OSA_memVirt2Phys() works is because the allocation happens from M4 where the physical to virtual address mapping is 1-1, but this isn't the case on Linux.
    If you intend to use EDMA from Linux, then you will need to use CMA for allocation. You also need a way to inteface your application with the EDMA driver (in vision-SDK EDMA is on M4).
    If you intend to use EDMA from M4, I would recommend allocating from SR and passing the buffer to M4.

    Regards
    Shravan
  • 0 in reply to Shravan Karthik
    Intellectual 730 points
    Hi Shravan,

    Can you confirm that the CMA is integrated into the DMA subsystem of ARM in kernel 4.4.84 which is used in PSDK 3.03? If yes, then I suppose it is only a matter of allocating memory with dma_alloc_coherent().

    Regards,
    Nick
  • 0 in reply to Nick Cage
    TI__Genius 14650 points
    Hi Nick,

    Sorry about the delayed response, I was on leave.
    Yes you can use dma_alloc_coherent, and if the device is NULL / the device doesn't have a dedicated dma pool, it will allocate from CMA. You can then use this to program the EDMA (the call as such returns a virtual address, but one of the arguments passed contains the physical address).

    Regards
    Shravan
  • 0 in reply to Shravan Karthik
    Intellectual 730 points
    Hi Shravan,

    I managed to use dma_alloc_coherent() and perform an EDMA transfer between that and the one allocated with OSA_memAllocSR() so that worked out great.

    The next problem that I'm having is that the buffer allocated with dma_alloc_coherent() cannot be written to a file on SSD opened with O_DIRECT flag. I have posted on a few Linux related forums since I don't think it is related to TI specifically any more but I have got no answers. Do you have any experience with this? I will post this as a new question if you have an answer.

    Looking forward to hearing from you.

    Regards,
    Nick
  • 0 in reply to Nick Cage
    TI__Genius 14650 points
    Hi Nick,

    I don't think this is permitted since it security flaw to allow I/O on kernel pages mapped to user-space. There will have to be a copy into kernel space which can then be written through O_DIRECT.

    Regards
    Shravan
  • 0 in reply to Shravan Karthik
    Intellectual 730 points

    Hi Shravan,

    We have tried to write to SSD directly from the dma_alloc_coherent() buffers from a kernel module but we have found that writing to disk from kernel space is not encouraged and is only available via certain hacks so we gave up on that. What I would like to know now is something else but I will make another thread and link it here if you would like to look at it, basically we would like to write to SSD directly from OSA_memAllocSR buffers (which is the original problem that drove us into this one) but more details on the thread. It can be found here: https://e2e.ti.com/support/arm/automotive_processors/f/1021/t/729926

    Regards,
    Nick