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.

using memory from POOL_alloc

Good afternoon,

I am using dsplink_1_61_03 with its default configuration.  I am sending a data buffer from DSP to ARM.

On the DSP, I call POOL_alloc() then  I send its address to the ARM in a message.

Quoting the Programmer's Guide, "If the buffer is allocated on DSP-side, the DSP address received on the GPP can be translated using

 

POOL_translateAddr".

I therefore make this call to POOL_translateAddr():
POOL_translateAddr(MYAPP_POOL_ID, addyToUseInMyGppApp, AddrType_Usr, dspAddyFromMsg, AddrType_Dsp);

The Programmer's Guide says that the DSP can use direct memory reads and writes for the buffer from the pool.  I am doing this in my DSP application.

Now here are my questions:

(1) Can my GPP application access the shared buffer directly using the translated address I got from POOL_translateAddr()?  This is working for me, but I need confirmation that this is safe and portable.  I like this method since I am trying to minimize copy operations in my GPP application.

(2) Or am I supposed to use the PROC_read/PROC_write API to access the buffer from the POOL?  The Programmer's Guide is not specific on whether I am allowed to access the memory directly with a pointer in my userspace app or if PROC_read()/PROC_write is a requirement.

Please let me know if direct access is safe from the GPP side or if I need to use PROC_read/PROC_write to access the pool.

Thanks!

  • Chris,

    Please find my answers inline:

    (1) Can my GPP application access the shared buffer directly using the translated address I got from POOL_translateAddr()?  This is working for me, but I need confirmation that this is safe and portable.  I like this method since I am trying to minimize copy operations in my GPP application.

    [Deepali]: Yes the GPP can use the shared buffer directly. This is safe and portable. Please note that reads/writes to the POOL buffer need to be protected by the application. For e.g. application starts reading from a buffer which is still not being filled by DSP, then your application will face data integrity error.  So either you protect the access using MPCS module or synchronize access.

    (2) Or am I supposed to use the PROC_read/PROC_write API to access the buffer from the POOL?  The Programmer's Guide is not specific on whether I am allowed to access the memory directly with a pointer in my userspace app or if PROC_read()/PROC_write is a requirement.

    [Deepali]: PROC_read/Proc_write is another way to access the data. I will update the document to be more specific about both options.

    Deepali

     

     

  • Hi Deepali,

    Thank you for answering my questions and also for your advice on protecting the buffer.  I'm presently using NOTIFY from DSP to GPP to inform the GPP that the DSP has updated the buffer.  I use a second NOTIFY from GPP to DSP for GPP to acknowledge that it has read the buffer.  This synchronization is working well so far.

    Regards,

    Chris Norris
    Sr. Firmware Engineer
    Embla Systems, Inc.

  • Hi,

       I am allocating the POOL at ARM side, updating the pool with data, translating the address and sending it to DSP using Notify. After this DSP reads and modifies the contents of the POOL. It then notifies the ARM about the change. BUT now when i read the POOL i dont see any changes done by DSP. 

    Am i missing some step ? Please help.

     

    Regards

    Pavan

  • Hi Pavan,

    On the DSP side, after you modify the data, you need to call HAL_cacheWbInv() on the data.  This invalidates the cache and updates the actual shared memory so the ARM can see your changes.

    One area I'm still unclear on regarding HAL_cacheWbInv() is the address range.  Can we restrict it to only the data that changed, does the range need to be cache aligned, or does it have to be be called on the whole POOL buffer being changed?  If it's a large buffer and we just change a small section, calling HAL_cacheWbInv() on the entire buffer seems wasteful.  Maybe someone from TI could help answer this part.

    Regards,
    Chris

  • Chris,

    Chris Norris said:

    One area I'm still unclear on regarding HAL_cacheWbInv() is the address range.  Can we restrict it to only the data that changed, does the range need to be cache aligned, or does it have to be be called on the whole POOL buffer being changed?  If it's a large buffer and we just change a small section, calling HAL_cacheWbInv() on the entire buffer seems wasteful.  Maybe someone from TI could help answer this part.

    You can call HAL_cacheWbInv () or the other cache coherence functions on a specific address range. You can restrict it to only the data that changed if you are aware of the range. The data range needs to be cache line aligned. i.e. the start address needs to be on a cache line boundary (128 bytes in this case) and the size that you are making cache coherence calls on, needs to be a multiple of the cache line size, i.e. 128 or (128 * n) bytes. If these are not cache line aligned, the function call will not fail, but internally it will align itself to the cache line boundary and take care of the cache coherence, which may result in additional data range undergoing cache write-back or invalidate than was your intention.

    Regards,
    Mugdha

  • Mugdha,

    Thanks for explaining what is going on internally.  In my own application, I call HAL_cacheWbInv() on certain ranges of data without worrying about the alignment.  Now I understand that there is extra cache write-back to align with the cache line, but that is ok for my current DSP and ARM applications.  DSPLink makes it easy for us!  :)

    Regards,
    Chris Norris