[参考译文] TDA4AEN-Q1：MEM：错误：appMemCacheInv 的 DMA_BUF_IOCTL_SYNC 失败

您好 Q xn、

由于假日季和大多数工程师的假期计划、请预计回复会延迟。

此致

Suman

您好：

关于上述问题单、以下是一些附加要点：

1. 目前、我们有多个流程、即 Capture、AVM 和 Vision。 出现问题的过程是 AVM。 AVM 过程中的主图是 ALG_AVM→compress. srv_avm AVM 过程中的节点是上面提到的 GPU。 下面、我将附上捕获过程和 AVM 过程的图形流程图以供参考。

2. 验证后：通过分配的缓冲区 tivxMemAlloc 同时包含物理地址和 DMA FD。 在过程 A（发送方）中、使用从 DMA FD 转换的虚拟地址保存的映像看起来正常。 但是、在过程 B（接收器）中、使用从 DMA FD 转换的虚拟地址保存的图像属于异常情况、而使用从过程 B 中物理地址转换的虚拟地址保存的图像看起来正常。

   

   此致

您好：

对上述说明的补充：

1. 在进程 A（发送方）中、通过分配内存 tivxMemAlloc、然后创建 ImageBuffer。  ImageBuffer 然后将创建的内存填充到分配的内存中 tivxMemAlloc。 随后、使用函数 vxSwapImageHandle() 和执行转换 tivxMemTranslateVirtAddr()。 然后、将转换后的 DMA FD 发送到接收器。

2. 如前所述、在过程 A（发送方）和过程 B（接收者）中、DMA FD 都映射到虚拟地址、以从虚拟地址保存映像。 我用于将 DMA FD 映射到虚拟地址的函数是：

   mmap (NULL、BUFFER_SIZE、PROT_READ、MAP_SHARED、

   m_camData.MutableImage ().buffer_addr_dma[i]、0)； 

您好、

然后将转换后的 DMA FD 发送给接收器。

这是如何发送到接收者的过程?

您是否使用带有 CMSG 的 UNIX 套接字将 DMA buf FD 映射到另一个进程？

您能参考这个 FD_exchange 演示吗？

此致、
Gokul

您好：

1.我们使用的是共享内存。 发件人和收件人都打印物理地址和 dmafd。 与同一物理地址相对应的 dmafd 在发送方和接收方之间保持不变。 对于物理地址 0xc43f9000、发送端和接收端的 dmafd 均为 74。

您好、

dma fd 绑定到进程,如果您看到 tivxmemalloc () 它分配了内存,并创建了一个 dma fd ,该 fd 将在 g_app_mem_obj 表中更新,该表是进程的本地表。 调用 tivxMemTranslateVirtAddr() 时、它将从表中检索 DMA FD 号码。

DMA FD 编号在不同的过程中可以相同、但这并不意味着它映射到正确的地址。 因此、必须将由一个进程创建的 DMA FD 映射到其他进程、如 app_FD_exchange 演示中所示。

您能否参考该演示并相应地更新您的应用？

此致、
Gokul

您好：

我回顾了 您提到的 app_FD_exchange 演示、该演示使用 Unix 域套接字在各个进程之间传递 DMA 缓冲区文件描述符。 然而,根据我们当前的情况,经过讨论后,我们不太倾向于采用这种使用 Unix 域套接字在进程之间传递 DMA 缓冲区文件描述符的方法。 我的问题是:如何将一个进程创建的 DMA 文件描述符映射到另一个进程? 或者、在接收过程中是否有其他方法可以获取有效的 dmafd？

我们有一位同事在 TDA4 VM SDK9 平台上工作。 在发送端、他们使用 appMemGetDmaBufFd() 和直接获取物理地址和 dmafd tivxMemHost2SharedPtr()、并将它们传递到接收端 其他客户端也使用此 dmafd、没有报告任何问题。 然而,我们不知道客户是否在内部对该 dmafd 执行任何特殊处理。 因此、除了 app_FD_exchange  演示中描述的方法外、我想问是否还有其他方法来解决我们在 TDA4 VEN SDK11 上遇到的问题。

您好、

在发送端、他们直接使用 appMemGetDmaBufFd() 和获取物理地址和 dmafd tivxMemHost2SharedPtr()、

如果看到 appMemGetDmaBufFd () 的定义、

它从进程唯一的全局对象 g_app_mem_obj 检索 dmabuffd。 这个全局对象在调用 tivxmemalloc () 时更新,如果你尝试从其他进程获取 dma fd ,它可能没有关于其他进程分配了什么的信息。

因此、跨进程共享 DMA buf FD 的一种方法是使用 UNIX 套接字。

但是、我们不知道客户机是否在内部对此 dmafd 执行任何特殊处理。 [/报价]

您能向他们核实一下他们是如何做到的吗？

我们仅在 SDK 中测试了 UNIX 套接字方法。

此致、
Gokul

尊敬的 xn Qi。

您能否回答 Gokul 的问题？ 您是否使用了诸如 SDK 共享的 UNIX 套接字方法？

非常感谢！

Yong

您好：

我只是有点忙,忘记回复电子邮件. 很抱歉。 DMA-BUF 跨进程问题已解决。 我们通过 PIDFD 复制 DMA-BUF 来解决该问题。

此外、我们的日志中还有一个持久的打印输出：
139.635192 s: MEM: ERROR: DMA_BUF_IOCTL_SYNC failed for appMemCacheInv(0xffff39623000, 2457600) !!!

虽然它不会影响功能、但我们仍希望将其删除。 我们如何才能删除它？

非常感谢！

您好、

[引述 userid=“596461" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1601290/tda4aen-q1-mem-error-dma_buf_ioctl_sync-failed-for-appmemcacheinv/6193529

139.635192 s: MEM: ERROR: DMA_BUF_IOCTL_SYNC failed for appMemCacheInv(0xffff39623000, 2457600) !!!

[/报价]

只要在 A53 内核中调用 tivxbuffermap/unmap 操作、就会出现此操作。 它最终使用 dmabuf-FD 来执行缓存操作。 我建议使用 UNIX 套接字方法来发送 dma-fd、并且我们 尚未测试 pidfd 如何将 dmafd 映射到其他进程。

如果您仍想消除错误、您能否尝试从 tiovx/source/platform/board/common/tivx_mem.c 内的 A72 将宏更改为 A53

我们无法确保此更改后必须 从您这边验证的功能。  

为了避免所有这些更改、我建议您使用 UNIX 套接字方法来发送 DMA-FD。

此致、
Gokul

你（们）好

更改为 A53 确实消除了：MEM:错误：appMemCacheInv (0xffff39623,000,2457600) 的 DMA_BUF_IOCTL_SYNC 失败！！！ 打印、但出现图像闪烁。  主要表现是前一帧中的某个图像再次闪烁。

您好、

在这种情况 下、A53 需要缓存操作、您无法避免调用宏内的函数。

我仍然建议使用 UNIX 套接字方法发送 DMA-FD 以避免任何问题。 否则、您必须对与 PIDFD 一起使用的缓冲区执行缓存操作。

此致、
Gokul

尊敬的 XN：

如果您解决了此问题、请告知我们、建议在此类用例中使用 UNIX 套接字方法。

如果不需要 TI 的支持、我们将尝试在下周关闭此工单。

非常感谢！

Yong

尊敬的 XN：

关闭此 TT 已长时间等待更新、如果出现问题、请提交新 TT。

非常感谢！

Yong