[参考译文] AM62L：AM62L：SPI 通信问题

如果 FIFO 调度策略未分配给 SPI 测试程序、系统不会挂起；但在这种情况下、可以观察到测试程序的 CPU 使用情况非常高。 我启用了内核调试功能、以便在发生此问题时捕获相关的日志。

`taskset -c 1 perf record -g -C 0`捕获的内容在`perf_report_tree.md`中提供。

`trace_stat/function0`通过`function_profile_enabled `捕获的内容在` trace_stat_function0.md`中提供。

内核未报告任何相关的错误日志。

e2e.ti.com/.../captured.tar

编译的测试二进制文件：

e2e.ti.com/.../spi_5F00_mcu_5F00_arm64.elf

更新后的 spi-omape2-mcspi.c

e2e.ti.com/.../spi_2D00_omap2_2D00_mcspi.c

SPI DMA 配置：

尊敬的 Jianannan：

但是、修改后的 SPI 通信很可能完全冻结系统、使其完全无响应、因此无论哪个内核、只有下电上电才能重新启动系统。

您能详细说明一下吗？ 当您说系统冻结时、会发生什么情况？ 您看到内核崩溃或其他情况吗？

尊敬的 Divyansh：

客户表示系统在此情况下挂起、而不显示错误日志。 （您可以从客户捕获的日志的最后回复中看到）只有在集成上述修复并以很高的 重现可能性运行 SPI 应用程序后、才会发生这种情况。 但此修复解决了原始的较大 SPI 抖动问题、因此我们需要此修复、但只需其他东西即可将此修复功能正确集成到 SDK11.2 中

谢谢、

Kevin

尊敬的 Kevin：

是否可以在 AM62L EVM 上运行第一个 POST 中连接的 SPI_MCU_TEST 程序？ 如果是、是否应修补 AM62L 内核器件树以启用 SPI？ 测试程序是否需要将器件连接到 SPI 总线的另一侧？

尊敬的 Bin：

感谢您的支持。 应修补 AM62L 内核以重现此问题。 客户最初是  在其实际应用（客户板+连接外部器件的 SPI）下测试 SPI_MCU_TEST 程序、这将很容易重现。 为了帮助我们在 EVM 上重现问题、客户目前在其客户电路板设置中断开了 MISO 和 MOSI（未连接外部 SPI 器件）、多次运行（并非每次都无法重现该问题）后、他们仍然可能重现此问题、因此这建议我们也要在 EVM 设置上重现问题。

客户在重现问题的其中一次成功捕获了下面的一些错误日志：

[  140.151496] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  140.151517] rcu:     1-...!: (2 GPs behind) idle=2150/0/0x0 softirq=0/0 fqs=0 (false positive?)
[  140.151531] rcu:     (detected by 0, t=60002 jiffies, g=1325, q=1 ncpus=2)
[  140.151541] Sending NMI from CPU 0 to CPUs 1:
[  140.151553] NMI backtrace for cpu 1 skipped: idling at default_idle_call+0x24/0x34
[  140.152551] rcu: rcu_preempt kthread timer wakeup didn't happen for 59999 jiffies! g1325 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[  140.152559] rcu:     Possible timer handling issue on cpu=0 timer-softirq=40541
[  140.152563] rcu: rcu_preempt kthread starved for 60002 jiffies! g1325 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[  140.152570] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[  140.152573] rcu: RCU grace-period kthread stack dump:
[  140.152575] task:rcu_preempt     state:I stack:0     pid:17    tgid:17    ppid:2      flags:0x00000008
[  140.152588] Call trace:
[  140.152592]  __switch_to+0xc8/0x124
[  140.152602]  __schedule+0x230/0x6c0
[  140.152610]  schedule+0x30/0xf4
[  140.152617]  schedule_timeout+0x6c/0xd0
[  140.152624]  rcu_gp_fqs_loop+0x104/0x414
[  140.152633]  rcu_gp_kthread+0xdc/0x10c
[  140.152640]  kthread+0x10c/0x110
[  140.152650]  ret_from_fork+0x10/0x20
[  140.152658] rcu: Stack dump where RCU GP kthread last ran:
[  140.152663] CPU: 0 UID: 0 PID: 302 Comm: spi_mcu_arm64.e Not tainted 6.12.57-ge942a64b06fe #29
[  140.152671] Hardware name: TM731-Lite (DT)
[  140.152673] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  140.152680] pc : am62l_udma_tx_status+0x1b0/0x2e4
[  140.152691] lr : am62l_udma_tx_status+0x68/0x2e4
[  140.152698] sp : ffff000003c8f910
[  140.152701] x29: ffff000003c8f910 x28: 0000000000000000 x27: ffff8000812aa100
[  140.152710] x26: 0000000000000001 x25: 0000000000000020 x24: 00000000000003e8
[  140.152718] x23: ffff000001a625c0 x22: ffff000003440430 x21: 0000000000000383
[  140.152726] x20: ffff000003c8f9f0 x19: ffff000003440390 x18: 00000012a96885d3
[  140.152735] x17: 0000000000000000 x16: 000000000013fc98 x15: ffff00001ff995c0
[  140.152743] x14: 02f42a7cd9c8086c x13: 0000000000000000 x12: 0000000000000000
[  140.152751] x11: 00000000000000c0 x10: 00000000000008f0 x9 : ffff000003c8f7e0
[  140.152760] x8 : ffff000003f15ed0 x7 : 0000000000000000 x6 : 000000000000002c
[  140.152767] x5 : ffff000003440448 x4 : 0000000000000000 x3 : 0000000000000000
[  140.152775] x2 : 0000000000000000 x1 : 0000000000000002 x0 : 0000000018100000
[  140.152783] Call trace:
[  140.152785]  am62l_udma_tx_status+0x1b0/0x2e4
[  140.152792]  omap2_mcspi_rx_dma+0x178/0x448
[  140.152805]  omap2_mcspi_transfer_one+0x3a0/0xbf8
[  140.152814]  spi_transfer_one_message+0x384/0x6d8
[  140.152822]  __spi_pump_transfer_message+0x198/0x4f4
[  140.152830]  __spi_sync+0x24c/0x32c
[  140.152837]  spi_sync+0x2c/0x4c
[  140.152843]  spidev_message+0x240/0x2f8
[  140.152851]  spidev_ioctl+0x25c/0x3f0
[  140.152859]  __arm64_sys_ioctl+0xa4/0xe4
[  140.152869]  el0_svc_common.constprop.0+0x58/0x124
[  140.152878]  do_el0_svc+0x18/0x20
[  140.152884]  el0_svc+0x80/0xf0
[  140.152891]  el0t_64_sync_handler+0x118/0x124
[  140.152898]  el0t_64_sync+0x14c/0x150

客户怀疑它可能卡在 OMAP2_mcspi_rx_dma () 中的循环中：

/*
* Before disabling RX DMA we need to confirm whether DMA RX is complete.
* This polling completes on the first attempt itself in most cases.
*/
do {
dma_status = dmaengine_tx_status(mcspi_dma->dma_rx, dma_rx_cookie,
&mcspi_dma_rxstate);
} while (dma_status != DMA_COMPLETE);

谢谢、

Kevin

尊敬的 Kevin：

参考 AM62L-DMA：dmaengine：TI：k3-UDMA：1 秒轮询延迟、我修改了 EVSE-DEV-EVM 驱动程序 和 SPI：spi-OMAP2-mcspi：启用 DMA 时使用 EOW 中断完成 — ti-linux-kernel/ti-linux-kernel — 此库包含一个出色的 Linux 内核。 更改显示在附加的 diff 文件中。

请恢复您的 SPI 驱动程序更改、并应用下面连接的内核补丁以查看系统是否仍然挂起。

e2e.ti.com/.../0001_2D00_FROMLIST_2D00_spi_2D00_spi_2D00_omap2_2D00_mcspi_2D00_Use_2D00_EOW_2D00_interrupt.patch

尊敬的 Bin：

此修补程序也有问题。 内核日志：

[  173.118196] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  173.118221] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+47@401+128@640+512@7680=> 792 free of 8192 total pages
[  174.400698] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  174.400722] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+15@401+128@640+512@7680=> 760 free of 8192 total pages
[  175.680698] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  175.680723] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+15@401+128@640+512@7680=> 760 free of 8192 total pages
[  176.960698] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  176.960722] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+15@401+128@640+512@7680=> 760 free of 8192 total pages
[  178.240698] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  178.240724] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+15@401+128@640+512@7680=> 760 free of 8192 total pages
[  179.520700] cma: __cma_alloc: reserved: alloc failed, req-size: 1024 pages, ret: -12
[  179.520725] cma: number of available pages: 15@177+15@209+15@241+15@273+15@305+15@337+15@369+15@401+128@640+512@7680=> 760 free of 8192 total pages

同时、 存储器使用量不断增加、即使测试程序退出后、也不会将其释放。

尊敬的 Jianannan：

您能附上内核启动日志吗？ 日志应包含保留的 CMA 池的信息。

e2e.ti.com/.../boot.txt

[173.118196] cma:__cma_alloc : reserved: Alloc failed、req-size：1024 pages、ret：–12

何时打印此消息？ SPI 测试应用或其他应用时、该怎么办？

启动测试程序后、此日志将短暂显示。随后、每次启动测试程序时、它都会一直打印此日志、直到重新启动。

尊敬的 Jianannan：
我一直在尝试在我最终使用您的应用程序在默认的 11.02 SDK 上重现该问题。

即使有或没有上面给出的补丁、如果我只对 EVM 覆盖应用以下 diff：

diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
index 03a623418469..308052c1272b 100644
--- a/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts
@@ -391,6 +391,15 @@ AM62LX_IOPAD(0x0188, PIN_INPUT, 0) /* (A9) MCASP0_AXR1 */
 		>;
 	};
 
+	main_spi1_pins_default: main-spi1-pins-default {
+		pinctrl-single,pins = <
+			AM62LX_IOPAD(0x008c, PIN_INPUT, 4) /* (H22) SPI1_CLK */
+			AM62LX_IOPAD(0x0080, PIN_INPUT, 4) /* (K22) SPI1_D0 */
+			AM62LX_IOPAD(0x0084, PIN_INPUT, 4) /* (J23) SPI1_D1 */
+			AM62LX_IOPAD(0x0088, PIN_INPUT, 4) /* (K23) SPI1_CS0 */
+		>;
+	};
+
 	pmic_irq_pins_default: pmic-irq-default-pins {
 		pinctrl-single,pins = <
 			AM62LX_IOPAD(0x01e8, PIN_INPUT, 0) /* (C8) EXTINTn */
@@ -987,3 +996,35 @@ &mcasp0 {
 &wkup_uart0_interconnect {
 	status = "okay";
 };
+
+&main_spi1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&main_spi1_pins_default>;
+	bootph-all;
+	ti,pindir-d0-out-d1-in;
+
+	dmas = <&main_bcdma 0 0 0xc300 0>, <&main_bcdma 0 0 0x4300 0>;
+	dma-names = "tx0", "rx0";
+	
+	spidev@0 {
+		spi-max-frequency = <24000000>;
+		reg = <0>;
+		compatible = "rohm,dh2228fv";
+		spi-cs-setup-delay-ns = <5000>;
+		spi-cs-hold-delay-ns = <5000>;
+		spi-cs-inactive-delay-ns = <5000>;
+	};
+}; 
+
+
+&main_i2c1 {
+	gpio@23 {
+		fet_sel {
+			gpio-hog;
+			gpios = <1 GPIO_ACTIVE_HIGH>;
+			output-high;
+			line-name = "VOUT0_FET_SEL0";
+		};
+	};
+};
\ No newline at end of file

没有其他更改（未应用 DMA 驱动程序补丁）、然后在目标上编译并运行您的示例、示例仍然挂起。

您之前提到、如果没有此修补程序、您会看到较高的 CPU 负载、但用户空间不会挂起、它只会在使用第二个修补程序后挂起、这是正确的吗？

尝试复制设置时是否缺少内容？

当我没有应用补丁时、我观察到在未启用 DMA 的情况下、CPU 使用率非常高；启用 DMA 明显改善了这种情况、尽管系统表现出大量抖动。 在这两种情况下、系统都保持正常工作且不会挂起。

应用补丁后、可以重现挂起问题。 为了便于观察、我已将测试程序的调度策略从 FIFO 调整到其他、这使我能够在出现问题时观察到异常高的 CPU 使用率。

您是指在不应用任何补丁的情况下、能够在 EVM 电路板上重现问题吗？ 我注意到某些内核调试配置可能会影响问题的表现—例如、当`示踪剂等调试功能启用（但仍挂起）时、早期的`___ cma_alloc 日志不会出现。

尊敬的 Jianannan：
这是之前发布的 DMA 线程编号问题。 现在可以使用、即使应用了补丁（我看到 CPU 使用率较低）。

为了重现您的问题、您提到您每次都不会看到它、何时会看到它？ 在多次重新引导并重新运行应用程序或在同一引导本身中重新运行同一应用程序时？ 通常、您从启动开始需要多长时间才能看到挂起/内核崩溃？

尊敬的 Divyansh：

之前是 DMA 线程编号问题。 现在可以使用、即使应用了补丁（我看到 CPU 使用率较低）。

您能否说明一下 DMA 线程编号问题涉及的具体内容？ 我对这一点并不十分清楚、因为这一点似乎以前没有提出过。 我没有为内核的 DMA 中断线程配置任何内容。

关于问题的复制、过程很简单：应用第一个 修补程序后、只需直接运行测试程序。 在大多数情况下、问题会立即重现、但偶尔程序会正常运行而没有任何故障。 在这种情况下、您可以退出并重新运行程序以触发问题、或者重新引导系统。 对于第二个修补程序、您需要在打印 CMA 日志之前让它运行更长时间（大约 1 到 2 分钟）。

尊敬的 Jianannan：
我在设置中使用的是 SPI1 而不是 spi0、这保证更改 DMA 线程 ID 如果使用 spi0、则不需要更改任何代码。

我在应用了第二个修补程序的情况下使用了相同的引导（不重新引导）、3 小时内没有崩溃日志。 我运行了您的代码示例的完整长度超过 7-8 次、仍然没有发现问题。 应用程序运行时、两个内核的 CPU 功耗约为 5-6%。
我在执行的每一个 7-8 次试验中都看到了以下内容：

root@am62lxx-evm:~/spi_mcu# ./spi_mcu_arm64.elf
[INFO] Start
[INFO] spi_mcu_init()
[WARN] too long trace_jitter.csv! exit...
[INFO] spi_mcu_deinit()
[INFO] Exit
root@am62lxx-evm:~/spi_mcu#

在上述情况中、应用运行时、还可以看到 SPI0_CLK 和 SPI0_D0 输出。

尊敬的 Divyansh、Jianan：

您的讨论存在一些误解。 Divyansh 的测试是在 Bin 的新补丁,而不是原来的补丁。

而对于 Jianan 的反馈、对于原始补丁、经过多次尝试后、我们可以轻松地看到挂起问题、无需等待。 仅对于 Bin 的新补丁、他们在 1~2 分钟后才会看到一些错误日志。 所以它们是不同的。

我建议也许 Divyansh 你可以首先尝试原始补丁,看看你是否有同样的问题,首先.

谢谢、

Kevin

我简要地将原始打补丁的 spi-OMAP2-mcspi.c 文件与新补丁进行了比较、并发现只有 2 个差异：

1.原始补丁将 dma_Min_bytes 更改为 12、但新补丁保持宏不变、即 160。

2. Kevin 指出的 do-while 循环以及可能导致挂起（忙循环）的位置将从新修补程序中删除。

do {
        dma_status = dmaengine_tx_status(mcspi_dma->dma_rx, dma_rx_cookie,
        &mcspi_dma_rxstate);
} while (dma_status != DMA_COMPLETE);

尊敬的 Bin：

我已经与客户讨论过、下面提供了一些说明：

1：客户在前一天发现原始补丁中的这个“Do-while loop“（do-while 循环）是可疑的、因此他们已经删除了它、挂起问题按预期消失、但引入了新的“cma_alloc“错误日志相关的内核 内存泄漏问题。

2：对于昨天共享的新补丁、它们只遵循删除“Do-while 循环“但将 dma_MIN_bytes 从 160 恢复到 12 的更改。 原因是客户认为 160 太大、他们的 CPU 负载已经很高、希望尽可能使用 DMA、因此他们将 DMA_MIN_Bytes 保持为 12 以供您的新补丁测试、因此结果与上面提到的第 1 点相同。

3：基于 dma_MIN_bytes 为 12 的新补丁、客户发现、一旦启用跟踪器调试选项、“cma_alloc“错误日志就会消失、但会导致其应用程序测试程序无法正常退出（无法使用 crtl+c 退出）。

客户知道 Divyansh 刚刚使用 EVM 进行了测试+您的 dma_MIN_bytes 160 新补丁没有出现任何问题、他们希望我们也可以测试原始补丁、如果我们还看到挂起问题、这将证明 您使用 dma_MIN_bytes 160 的新补丁实际上解决了问题（EVM 本身无法重现）。 同时、客户将 在明天使用 dma_MIN_bytes 160（而不是 12）测试您的新补丁、以查看结果。

谢谢、

Kevin