[参考译文] AM625：具有 DMA 且 bpw！= 8R 的 SPI：卡在&#39；ioctl&#39；无限期

似乎在不使用 DMA 时会发生问题？

当您使用小于4096的尺寸时会发生什么情况？

此致、Andreas

安德烈亚斯

当器件树的 SPI 节点中不存在 DMA 时、不会发生该问题。

如果您使用的大小小于4096、则该问题不会出现在单次传输中。

在我的应用中、始终会进行许多传输、因此在经过一些随机时间后、会出现该问题。 在我的应用中、所有传输都不是4096、因为这会使问题出现在第一次传输中。

使用 RT Linux 时、出现该问题的速度要快得多。 这让我觉得该问题与与 SPI/DMA/IRQ 相关的时序(竞态条件)有关。

但是、无论如何、您都可以重现上述问题。

好的、谢谢额外的背景、这里看起来有些地方不是很好。

您使用的确切内核版本(TAG 或相关的 SDK 版本)是什么？

除了常规的 DTS 或配置更改之外、您是否对内核进行了任何更改？

此致、Andreas

使用  VAR-SDK-AM62、 am62-Yocto-kirkstone-6.1.83_09.02.01.10-v1.0、基于 TI SOM 09_02_01_10。

我对此测试所做的唯一更改是将 DMA 添加到器件树中的 SPI。 否则、它是 VAR-AM62-AM62的一个非常基本的映像(var-thin-image) SOM。 没有任何其他变化,以提供尽可能干净的试验台。

我认为、如果您获取您的 EVK 并进行我所述的更改(将 DMA 添加到 SPI、并添加 spidev 设备(如果不存在)、并执行上述测试、您可以轻松复制问题。

是的,这是我的想法,我会给这一个镜头,可能明天星期五或星期一。 如果我能找到重新创建该分析的方法、分析将会容易得多。

此致、Andreas

安德烈亚斯

您是否按照步骤概述在 TI EVK 上复制了问题？

使用8位以外的传输大小、我似乎能够重新创建您看到的内容。 就像使用您报告的`-b 32`挂起一样。 而当`μ s-b 16`时、它也会遇到一些(不同的)问题。。。

root@am62xx-evm:~# ./spidev_test -D /dev/spidev1.0 -i zeros -b 16
spi mode: 0x0
bits per word: 16
max speed: 500000 Hz (500 kHz)
[  172.775441] spidev spi1.0: DMA RX last word empty

(...hangs...)

这可能是到目前为止尚未被发现的问题、因为大多数人使用8位传输。 我还可以看到 McSPI 外设驱动程序对 DMA 上下文中的16位和32位宽字的分离/管理具有相当多的特殊处理；我想知道逻辑中的某些内容是否100%正确。

为什么要使用32位宽的字、解决这个问题对您有多重要？ 如果要提升整体效率(通过尽可能减少字节间隙)、您还可以查看此处的 E2E 常见问题解答： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1356551/faq-am6x-optimizing-spi-transfer-inter-byte-gaps-using-the-dma-in-linux 、了解其他方法。

我可以提交一份内部错误报告以进行调查、但这些事情通常不会很快进行。

此致、Andreas

这对我来说非常重要。  但是、我认为它应该起作用、或者继续说它不受支持、因为它肯定不起作用。

Unknown 说：

这对我来说非常重要。  [报价]

请您解释原因(具体用例)。 更好地了解背后的原因可能有助于从优先的 POV 中解决这一问题。

此致、Andreas

吞吐量和更少的 CPU 使用率。 但是、我们现在把它拖下来。

8位传输也会出现同样的问题。 它是不那么容易重现如我的原始文章中所示的16/32位案例。 但在我的应用中、经过几个小时等等之后、ioctl 调用永远不会返回。

我将尝试创建单个文件 c 应用程序来重现此问题。 然后、我将在此处发布二进制文件和源代码、供您试用 TI EVK。

Unknown 说：

吞吐量和更低的 CPU 使用量。 但是、我们现在就把它拖下来。

如果使用 DMA、这应该无关紧要；我很好奇您是否收集了任何数据来备份此数据。

Unknown 说：

8位传输时也会出现同样的问题。 它是不那么容易重现如我的原始文章中所示的16/32位案例。 但在我的应用程序中,经过几个小时,等等, ioctl 调用永远不会返回。

好的、我认为这不是我们听说的。 我们需要进行调查。 有很多人使用 DMA 和8位传输、而不会出现明显的问题。

Unknown 说：

我将尝试创建一个单个文件 c 应用程序来复制此问题。 然后、我将在此处发布二进制文件和源代码供您尝试使用 TI EVK。[/QUOT]

谢谢、这对于分析/调试此内容而言至关重要。 此外,请注意内核日志在"崩溃"/挂起的时刻,如果有任何感兴趣的东西。

此致、Andreas

安德烈亚斯

我已经弄清楚如何通过一个非常简单的应用程序来重现该问题。

关键是需要花费很长时间才能实现、需要以太网负载才能显示。

由于我的测试应用只是一个执行 SPI 读取的循环、因此没有发现任何问题。 但是、当与我自己的应用程序进行比较时、我注意到在连接到 HTTP 服务器时会发生这种情况。

因此、为了重现此问题、您需要随测试应用一起运行一些以太网负载。 最简单的方法是使用 iperf3：

iperf3 -c IP_ADDRESS -b 100000000 -t 9999

其中 ip_address 是运行 iperf3作为服务器的计算机的 IP 地址。

所以、完整测试设置如下所示：
- SSH 会话与 htop 打开

-运行 iperf3的 SSH 会话

-串行终端打开,启动测试应用程序

然后观察测试应用在 htop 中达到100% CPU 负载。 此时、硬件处于不可恢复的状态、需要重新启动。

我已经附上了最小测试应用程序的源代码以及二进制文件。
可能需要也可能不需要针对此问题运行 RT Linux 才能显示(或更快显示)。

e2e.ti.com/.../spi_5F00_dma_5F00_test.zip

您好！

感谢您提供附加信息和调试工作。 这听起来很费力你正在做什么,所以感谢你投入的精力和耐心。 明天我将审核您的资料、看看我是否可以重新创建并报告

Unknown 说：

此时、硬件处于不可恢复的状态、需要重新启动。

系统绝不应该进入这种状态、我们需要分析并解决这一问题。

此致、Andreas

明确来说、不可恢复的原因是不能停止使用已卡住的 SPI 执行应用程序。

没有信号会停止该线程/应用。 你仍然可以"做其他事情"。

现在我按照您所说的方式进行了这个设置、它正在运行。 让我看看它运行了多长时间...

目前我正在使用常规(非 RT)内核。

此致、Andreas

因此、我的电机已经运行了一夜、没有出现任何问题、它仍然发展强劲。 下面我构建/部署一个 RT 内核来完成此设置、然后重试以查看其是否产生任何影响。

此致、Andreas

我现在使用我基于 SDK v10.0版本构建的 RT 内核来运行您的测试应用。 做 iperf3客户机/服务器,以及 htop ---所有这些都与前一个测试中一样。 让我隔夜重复并报告一下。

此致、Andreas