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.

Freeing allocated CMEM Pool on DSP side

Expert 1940 points

Hi,

I am trying send some data from ARM to DSP. ARM is running on Linux OS and DSP on TI RTOS.

For this, I am allocating a buffer using CMEM_alloc2() in my Linux user space application.

The physical address for this buffer is being sent to DSP ( rpmsg packet) for retrieving data from the buffer and to process buffer data.

When I try to free CMEM in my user space application, I am getting 'failed to free memory' error.

At this point, my DSP program is not processing anything, it is just mapping the physical address to some virtual address using Resource_physToVirt() function.

Now I have a couple of questions here,

1. Am I seeing this CMEM error on the Linux side as a result of physical to virtual address mapping on the DSP side?

If yes, How does the CMEM module know that the address is mapped?

2. Eventually I will have to process data in the buffer. How can I handle freeing CMEM buffers on the Linux side without risking their reallocation, while data is processed on the DSP side?

Is there a way to free the CMEM buffer on the DSP side once I am done with data processing? I know there is no CMEM support for TI RTOS on the DSP.

Thanks

  • Girish Tummala said:
    1. Am I seeing this CMEM error on the Linux side as a result of physical to virtual address mapping on the DSP side?

    The DSP function Resource_physToVirt() is not doing any mapping, it is simply doing a lookup of the mapping as defined by the resource table.

    Girish Tummala said:
    If yes, How does the CMEM module know that the address is mapped?

    The CMEM module does a Linux mapping for the user-allocated buffer, which has nothing to do with the DSP mapping.

    The DSP mapping is achieved by way of the resource table entries.  One of them should be covering the whole of the CMEM physical memory, with the virtual address as defined by the resource table.  It is a fixed mapping that is live for the duration of the DSP application.

    Girish Tummala said:
    2. Eventually I will have to process data in the buffer. How can I handle freeing CMEM buffers on the Linux side without risking their reallocation, while data is processed on the DSP side?

    You need to establish an "ownership" protocol.  You said that you send the phys addr to the DSP via rpmsg packet, at which point the DSP "owns" the buffer.  When the DSP is done with the buffer it should send it back to the Linux side, at which point the Linux app "owns" the buffer and knows that the DSP is done with it.

    Girish Tummala said:

    Is there a way to free the CMEM buffer on the DSP side once I am done with data processing? I know there is no CMEM support for TI RTOS on the DSP.

    No, all CMEM operations are supported only on the Linux side.

    Girish Tummala said:
    When I try to free CMEM in my user space application, I am getting 'failed to free memory' error.

    I can't say why you're getting this failure, but it is not related to the DSP's usage of it, at least not directly.  For CMEM_HEAP-based allocations, when a CMEM buffer is freed it is placed on a free list, with the 'next' pointer being contained in the free buffer itself.  If the DSP were to continue to write into this freed buffer it could mess up the free list, so perhaps the DSP messed up the free list at some point in the past which causes your "current" free() to fail.  It's different for CMEM_POOL-based allocations, where the free and busy lists are maintained in memory separate from the pool buffers.

    Are there any console messages from CMEM when this 'failed to free memory' error happens?

    It might help to use the "debug" versions of both the CMEM library and the cmemk.ko module if there is not currently enough information to figure out what's happening.

    Regards,

    - Rob

  • Rob,
    Thanks for the reply.
    You are right, it looks like the free list might be messed up while filling the buffer.
    I am able to free memory now.

    Thanks!