• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1698 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/DRA725: Pass physical address to IPU for encoder failed

user4643736
Intellectual 920 points

Part Number: DRA725

Tool/software: Linux

Hello,

I want alloc continuous physical address to do encoder in GLSDK, and add the below code in videnc2test.c :

unsigned int out_pa = 0;
unsigned int *out_buf = NULL;

CMEM_AllocParams params;

params.type = CMEM_HEAP;
params.alignment = 0;
params.flags = CMEM_CACHED;

out_buf = CMEM_alloc2(CMEM_CMABLOCKID, output_size, &params);
out_pa = CMEM_getPhys(out_buf);

enc->output_bo = omap_bo_new_paddr(enc->dev, output_size, out_pa, OMAP_BO_CACHED);
enc->cdata = CMEM_map(out_pa, output_size);

When i rebuild and run videnc2test, get some error form kernel:

“[  113.163800] rpmsg_rpc rpmsg-dce: error from rproc_pa_to_da, rproc = df75ec00, pa = 0x90000000 ret = -22

[  113.178281] rpmsg_rpc rpmsg-dce: unwinding UVA to RDA translations! translation = 0

113.211200] rpmsg_rpc rpmsg-dce: failed to translate all pointers for remote core!”

The CMEM's memory was alloced  form CMA  "global" memory pool, and to use omap_bo_new_paddr(), I use some patches from infoadas ,the patches in attach zip file.

Does the encoder(IPU) support  continuous physical mem which allocated from MPU side? Maybe i need do some mem change in IPUMM,but I dont know how to implementation it.

Regards,

0008-libdrm-Add-support-for-paddr-ioctls.zip

  • 0
    TI__Mastermind 42515 points
    Hi,

    I have forwarded your question to graphics expert to comment.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    TI__Expert 5130 points
    Hi,

    The omap_bo_new_paddr () is not supported in GLSDK. Can you please confirm how this patch was arrived at?

    Regards,
    Anand
  • 0 in reply to Anand Balagopalakrishnan
    Intellectual 920 points
    Hi Anand,
    Thanks for your reply. The omap_bo_new_paddr() was implemented , Which i use some patches from the infoadas . It was work fine on GLSDK.
    And i already used it to get dma_buf alloced in VIP and Display. But it dont work out on encoder(IPU) , the local TI FAE engineer told me it could be the cmem mem space not maping to
    the encoder(IPU) side.
    There are three patches in above attach zip file:
    1. The "0006-HACK-drm-omap-creating-gem-handle-for-a-buffer-with-.patch" and "0007-omapdrm-fix-cache_flush-issue-for-paddr-gem.patch" ware worked in kernel omap_gem driver module.
    2. And the "0008-libdrm-Add-support-for-paddr-ioctls.patch" was worked in libdrm.
    If you need the modified omap_gem driver module and libdrm_omap.so, i could give to you. otherwise , you could use patches to add omap_bo_new_paddr().
    Regards,
    Sid
  • 0 in reply to user4643736
    TI__Expert 5130 points
    Hi Sid,

    Ah, I understand. As mentioned in the patch itself, it was hack only for INFOADAS and not meant to be used with GLSDK.

    I would recommend moving to PSDKLA 3.02 with corresponding INFOADAS release. On this version, we have a more robust support for your use case support using DMABUF implementation. All the processing blocks (INFOADAS, DSS, SGX, etc) have support for dmabuf import which makes buffer passing easy.

    We also have a demo of GStreamer based Car Blackbox which encodes stitched Surround View content.

    Regards,
    Anand