[参考译文] AM625-Q1：DMA 传输到 Linux 内核模块中的 GPMC 总线以及从该总线传输 DMA

尊敬的 Iker：

感谢您提供详细的报告。 这是非常有帮助的!

需要获取补丁的测试结果、因为补丁只会启用从 GPMC 的 DMA_DEV_TO_MEM 传输、因此对 GPMC 的写入不会正常工作。

我可以帮助实现到 GPMC 的 DMA_MEM_TO_DEV 传输。 您的项目的日程安排是什么？ 我目前没有太多的带宽,直到6月中旬。

尊敬的 Bin：

非常感谢您的快速高效响应。 我真的很感激。

在进行任何开发之前、我想确认您所提议的该补丁是否是使用 DMA 传输从存储器缓冲区读取和写入 GPMC 总线的唯一和/或最合适的解决方案。

我之所以提到这一点、是因为我必须保持内核未安装修补程序、以保证我的模块与将来的内核更新的兼容性。

尊敬的 Iker：

这取决于数据如何移入/移出连接到 GPMC 的器件。 内核 dmaegine API 基本上支持两种类型：

1. dma_dev_to_MEM 和 dma_MEM_to_Dev；

2. DMA_MEM_TO_MEM。

如果不修补内核 K3 UDMA 驱动程序、则不支持#1使用 GPMC 传输数据。 (您使用的补丁会启用 dma_dev_to_MEM。)

未打补丁的内核应该已经支持#2、使用 dmaengine_prep_DMA_memcpy ()。

尊敬的 Bin：

您能详细说明一下"这取决于数据移动方式"的情况吗？

关于"DMA_MEM_TO_MEM"的内容应该能与未打补丁的内核搭配使用、这听起来很有趣。 在附加测试中、有一个测试用例、我尝试使用dmaengine_prep_dma_memcpy() API 写入 GPMC 总线、但没有良好结果(请参阅"2_1_8_dmatest_result.log")。 我在 SK-AM62评估板上执行这个测试用例、这是否不起作用？ 我仍处于概念验证阶段、没有完整的硬件板可用(AM62连接到 FPGA)。

非常感谢您的帮助。

尊敬的 Iker：

Unknown 说：

您能详细说明"这取决于数据移动方式"的条件吗？

我提到了两种类型的传输、dev_to_mem 和 mem_to_dev 将基于"FIFO"的器件连接到 GPMC、而 mem_to_mem 将存储器映射器件连接到 GPMC。

Unknown 说：

我在 SK-AM62评估板上执行此测试用例是否不起作用？

我实际上不知道该测试是否有效、该测试尝试使用 mem_to_mem 写入 GPMC 地址0x51000000、但 SK-AM62板上的 GPMC 接口上没有连接任何内容、对吗？

BTY、OSPI 驱动程序(drivers/spi/spi-cadence -quadspi.c)用于 dmaengine_prep_dma_memcpy()访问 OSPI 存储器。 它应与 GPMC 上的存储器映射器件相同。

尊敬的 Bin：

我提到了两种类型的传输、dev_to_mem 和 mem_to_dev 将基于"FIFO"的器件连接到 GPMC、而 mem_to_mem 将存储器映射器件连接到 GPMC。

我肯定想使用"mem_to_mem"模式。

我实际上不知道该测试是否有效、该测试尝试使用 mem_to_mem 写入 GPMC 地址0x51000000、但 SK-AM62板上的 GPMC 接口上没有连接任何内容、对吗？

正确的是、SK-AM62板上的 GPMC 接口没有连接任何内容(请参阅下图)。 如果您可以确认dmaengine_prep_dma_memcpy()在没有任何东西连接到 GPMC 总线时、"mem_to_dev"传输的 API 失败、我将等待完整的硬件设置可用、以验证"写入"操作是否成功完成。

BTY、OSPI 驱动程序(drivers/spi/spi-cadence -quadspi.c)用于 dmaengine_prep_dma_memcpy()访问 OSPI 存储器。 它应与 GPMC 上的存储器映射器件相同。

这些信息非常有用。 我已经看到使用dmaengine_prep_dma_memcpy() API 执行读取、而写入是通过 OSPI 外设内部的一种 DMA 引擎"间接"完成的。 但是、您能否确认使用dmaengine_prep_dma_memcpy() API 可以可靠地读取和写入存储器映射 I/O？

非常感谢您抽出宝贵的时间并提供详细的见解。

尊敬的 Bin：

我将等待整个硬件板可用、然后使用 MEM_TO_MEM DMA 测试读取和写入。

如果我在测试时遇到任何问题、我会再次与您联系。

非常感谢您的帮助！