• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 103 subscribers
  • Views 6770 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Callback from M4 processor to application processor in dra7xx

Shashank Hegde86
Prodigy 120 points

Hi,

GLSDK for dra7xx contains DCE framework for multimedia operations/transactions from App processor to IVAHD  (m4 processor). There is no callback interface defined for IVAHD to app processor (OMX had and now OMX is not there). Is there a callback facility in new DCE framework? If yes, can you let me know where I can search for it.

  • 0
    TI__Mastermind 30480 points

    Hi Shashank,

    DCE API calls like VIDDEC3_process, VIDENC2_process etc are blocking calls. So there is no need for IVAHD to call back the applciation when it is done.

    Can you let me know for what purpose you are expecting a callback?

  • 0 in reply to Ramprasad
    Prodigy 120 points
    Ramprasad,

    I am expecting for get data function, put data function and get buffer function in VIDDEC3 and VIDENC2 dynamic parameters.

    Ex: videnc2DynamicParams.putDataFxn
  • 0 in reply to Shashank Hegde86
    TI__Mastermind 30480 points
    Hi Shashank,
    Your application has to implement those call-back functions to send and receive data in slice modes.
    Refer the UserGuide and the sample-application(h264dec and h264enc) provided with the GLSDK package.
  • 0 in reply to Ramprasad
    Prodigy 120 points
    Ramprasad,

    In earlier SDKs, OMX interface implemented all the callbacks (OMX running on HDVICP took care of IPC as callbacks are called from encoder engine). In the latest GLSDK package as OMX is not present, DCE framework has to be used directly. But DCE does not have these interfaces defined. Hence I was wondering, if I have missed anything. Though, I register the callbacks from my application, these callbacks will be called from IVAHD. Here, I did not see any interface/layer enabling the IPC for callback handling in DCE.
  • 0 in reply to Shashank Hegde86
    TI__Intellectual 2540 points
    Hi Shashank,
    The DCE Framework doesn't support a callback facility. The encoding using DCE Framework is only supporting Entire Frame only; it does not support the sub frame level data communication.
    LIBDCE component on the MPU side will call IPC interface MmRpc_call(), and the implementation of MmRpc_call() is done synchronously.
  • 0 in reply to Buddy L.
    Prodigy 120 points

    Is it enough to update DCE framework to support or should Mmrpc be updated?

  • 0 in reply to Shashank Hegde86
    TI__Intellectual 2540 points

    Hi Shashank,

    If you look into the IPC packages \packages\ti\ipc\mm\MmRpc.h, which will show you that LIBDCE on the MPU (Cortext A-15) will call this API and it is a synchronous call.

    int MmRpc_call(MmRpc_Handle handle, MmRpc_FxnCtx *ctx, int32_t *ret);

    In order to support Asynchronous, then MmRpc needs to be update to provide an interface that will immediately return without waiting for the result from Cortext M4 side. Along with that, the client "eg. LIBDCE component", needs to be able to register a callback function. So that when Cortext M4 component (DCE or codec) completes the task, MmRpc can call the callback function.

    Those functionality is currently not there.

  • 0 in reply to Buddy L.
    Prodigy 120 points
    Hi,

    I am trying to access physical memory from the DCE for the above update. Is there a way to get memory map for DRA7xx GLSDK?
  • 0 in reply to Shashank Hegde86
    Intellectual 310 points
    Hi,

    Would you guys please provide the memory map info for DRA7XX?
  • 0 in reply to Shashank Hegde86
    TI__Intellectual 2540 points
    Hi Shashank,
    Are you looking for the firmware "dra7-ipu2-fw.xem4" map file?
    If that is the case, then can you tell me which GLSDK version that you are using?
    Thanks.
    //Buddy
  • 0 in reply to Buddy L.
    Prodigy 120 points
    Hi,

    We are using GLSDK version 6_04_00_02. We want to know, which memory regions (physical addresses) are exclusive to A15, ipu1, ipu2, dsp1 and dsp2? Which are the shared regions between them?
    Could you also tell whether can we directly operate on physical addresses in DCE? If so, is there a sample app to refer?

    Thanks,
    Shashank
  • 0 in reply to Shashank Hegde86
    TI__Intellectual 2540 points

    Hi,

    I don't have the information on IPU1, DSP1, or DSP2 since those are not being used for DCE component.

    For Multimedia DCE, it is only used IPU2, this is the memory configuration:

    MEMORY CONFIGURATION

            name            origin    length      used     unused   attr    fill

    ----------------------  --------  ---------  --------  --------  ----  --------

     L2_ROM                00000000   00004000  00000664  0000399c  RWIX

     EXT_CODE              00004000   005fc000  003314fc  002cab04  RW X

     L2_RAM                20000000   00010000  00000000  00010000  RWIX

     OCMC_RAM1             40300000   00080000  00000000  00080000  RWIX

     OCMC_RAM2             40400000   00100000  00000000  00100000  RWIX

     OCMC_RAM3             40500000   00100000  00000000  00100000  RWIX

     EXT_DATA              80000000   00200000  00056fe4  001a901c  RW  

     EXT_HEAP              80200000   02900000  02800000  00100000  RW  

     TRACE_BUF             9f000000   00060000  00008000  00058000  RW  

     EXC_DATA              9f060000   00010000  00000000  00010000  RW  

     PM_DATA               9f070000   00020000  0001027c  0000fd84  RW X

    The DCE component is ultilizing

    "EXT_CODE" (~6MB) - used for the HW accelerator codec.

    "EXT_DATA" (2MB) - used for the HW accelerator codec.

    "EXT_HEAP" (41MB) - the heap memory used by the codec to handle 2 instances of 1080P MPEG4 and 1 instance of 1080P H.264 encoder High Profile L4.1 

    "TRACE_BUF" (384KB) for traces.

    Since we don't have a sample app that directly operate on physical addresses in DCE, I cannot really say that you can directly operate on physical addresses in DCE. From the MPU side, as long as you are able to get the MPU virtual address that can be mapped into the IPU virtual address. Then you probably can get the IPU physical address.

    From the TI Linux team, they states that you can perform for IPU2 - 55082000:

    cat /sys/kernel/debug/omap_iommu/55082000.mmu/pagetable

    to get the IOMMU page table entries.

    Most of the entries we use today are L1 entries only so Table 20-4 from TRM suffices to find the physical address.

    Thanks.

    //Buddy

  • 0 in reply to Buddy L.
    Intellectual 310 points
    Hi,

    Is there any memory region in DDR that is shared between A15 and IPU2?

    Regards,
    Mahi
  • 0 in reply to Mahi
    TI__Intellectual 2540 points
    For GLSDK Linux, there are no memory region in DDR that is shared between A15 and IPU2.
    Linux team states that "memory has to be reserved by kernel either using memblock API or better yet do it using DTS utilizing the reserved-memory node."
  • 0 in reply to Buddy L.
    Intellectual 310 points
    Thanks for the info.

    Using "cat /sys/kernel/debug/memblock/reserved", I get the following info from which I could see there are already certain memory blocks that are reserved by kernel

    0: 0x80004000..0x80007fff
    1: 0x80008200..0x80f7a83f
    2: 0x83ff5000..0x83fff23a
    3: 0x8e000000..0x8effffff
    4: 0x95800000..0x9f7fffff
    5: 0xa0000000..0xa17fffff
    6: 0xab785000..0xab7fefff
    7: 0xab7ffec0..0xaf7fffff


    1. Is it okay if I use any of the above memory blocks?
    2. If it is possible to use any of the memory block does it need to be cached when I use it on IPU2?
    3. How can I enable caching for a memory block if required?

    Thank you in advance

    Regards,
    Mahi
  • 0 in reply to Mahi
    Intellectual 310 points
    Any help regarding the above info I have asked for?

    Thank you in advance
    regards,
    Mahi
  • 0 in reply to Mahi
    TI__Intellectual 2540 points

    Hi Mahi,

    I think you might want to post the questions to Embedded Linux forum: since it is more about using Linux kernel reserved memory. I am not even sure if those are related to IPU2 memory sections.

    Since I am not an expert in Linux Kernel memory space, I can only give my opinion:

    1) I don't think it will be okay since those are Linux kernel reserved memory block meaning those memories are reserved for specific purposes.

    2) If you are going to use the memory ONLY on IPU2 then it doesn't need to be cached; but for performance, caching usually help with a drawback that you need to make you flush and writeback properly to avoid reading a wrong data from cache. Same situation for the memory shared between A15-IPU2. It doesn't need to be cached, but the performance will get hit since all read and write directly to physical memory.

    3) You might want to see this: https://e2e.ti.com/support/embedded/tirtos/f/355/t/307135. It is a similar concept. GLSDK 6.04.00.02 is using IPC 3.21.00.07 (http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ipc/3_21_00_07/index_FDS.html), you can see the example of IPU2 AMMU configuration at /ipc_3_21_00_07/packages/ti/ipc/tests/IpuAmmu_vayu.cfg.  The IPUMM default firmware is currently using the same Ammu configuration as the one defined by the IPC.

    The original question on this thread should already been answered with: https://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/p/391725/1455053#1455053

    as NO Callback on DCE from M4 processor to application processor in dra7xx

    Thanks.

    //Buddy

  • 0 in reply to Buddy L.
    Intellectual 310 points
    Hi Buddy,

    Thanks for sharing your opinion. We understood that currently there is no callback mechanism from M4. We are asking for the above info to see the feasibility of whether communication can be facilitated from M4 to A15 using some shared memory and any suitable memory region is available in DRA7xx to do that

    Regards,
    Mahi
  • 0 in reply to Mahi
    TI__Intellectual 2540 points
    Hi Mahi,
    For shared memory between A15 and M4, it is probably best to create another Linux driver (/dev/xxx instead of using /dev/mem) for memory carveout that utilizes CMEM (software-dl.ti.com/.../cmem_8h.html) as described at processors.wiki.ti.com/.../CMEM_Overview especially on the CMEM FAQ section "In Linux, how do I set aside the memory carveout that CMEM uses?".

    Another example on using CMEM is from IPC package: \ipc_3_xx_xx_xx\linux\src\tests\nano_test.c on how they utilize CMEM API and using IPC MessageQ API to send and receive data between 2 different processors.
    Thanks.
    //Buddy