[参考译文] TDA4APE-Q1：DRV8889 的 SPI 通信问题

尊敬的 Mian：

以下提交很可能导致 CS 行切换： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/spi/spi-omap2-mcspi.c?h=ti-linux-6.1.y&id=52e9a5bb454518d3bc22797d918ae8346c8d6082

Linux 具有一些运行时 PM（电源管理）功能、可关闭处于空闲状态的设备并使其保持一定时间。 McSPI 是具有该 PM 功能的块之一、恢复功能在 CS 状态下具有该切换。

为了解决这个问题、如果 McSPI 提供的电源对于您的任何电源要求而言可以忽略不计、并且/或者如果您的系统中经常使用 McSPI 接口、则可以在此 CS 切换导致问题时关闭 McSPI 的 PM 功能。

此致、

Takuma

尊敬的 Takuma：

感谢您的友好回答。

您是否建议我恢复此提交并再次执行测试？ 问题是我使用的是 SDK11.1、此版本中的内核分支是 ti-linux-6.12.y 您提到的提交在该分支上找不到、并且代码并不完全相同。 您能否帮助确定此分行的相应承诺？

此致、

MIAN

尊敬的 Takuma：

让我纠正一下。 我在我的分支上发现了此提交、但由于重大代码更改和合并冲突、无法直接恢复。 您能帮助我生成恢复补丁吗？ 谢谢你。

此致、

MIAN

尊敬的 Mian：

您可以尝试在此处禁用 auto_runtime_pm：

您还可以在用户空间中启用/禁用 SPI 的电源管理功能。

此致、

Takuma

尊敬的 Takuma：

我已在进行更改后重新编译 SPI 驱动程序、如下所示、但问题仍然存在。 是否有其他可能的原因？

此致、

MIAN

尊敬的 Takuma：

我遇到了一个更严重的问题。 在我们的电路板上、四条 SPI 总线用于分别控制四个 DRV8889 芯片。 尽管存在前面提到的问题、但三条 SPI 总线可以正常地读取和写入 DRV8889 芯片的寄存器、其中一条总线无法如下所示。

我使用示波器捕获了波形（目前我没有逻辑分析仪）、发现波形看起来正常、如下图所示。 我的 示波器只有 2 个通道、因此我必须分别在 3 张图片上显示它们。 在所有 3 个图中、通道 1 是 CS、通道 2 依次是 CLK、MTSR 和 MRST。

通信似乎已完成、因为 MTSR 和 MRST 线路上都有正常波形。 但是、不清楚为什么软件未正确读取 MRST 信号。

 下图显示了相应的硬件原理图和内核器件树片段 。

是否存在任何错误配置？

此致、

MIAN

尊敬的 Mian：

我已在进行更改后重新编译 SPI 驱动程序、如下所示、但问题仍然存在。 是否有其他可能的原因？

虽然 SPI 线路上没有活动、但您能否运行“k3conf dump device | grep -i SPI“并共享日志。

尽管存在前面提到的问题、但三条 SPI 总线仍可以正常读取和写入 DRV8889 芯片的寄存器、而其中一条总线无法如下所示。

DTS 和原理图看起来相匹配、引脚多路复用看起来也是正确的。

您能否共享“dmesg"中“中的完整引导日志？

此致、

Takuma

尊敬的 Takuma：

SPI 空闲时的 k3conf 转储日志如下所示。

我使用的 SPI 器件是 main_spi0、main_spi3、main_spi5 和 main_spi6。

似乎主域中的所有 SPI 器件都处于关闭状态。 也许这是我问题的原因吗？

我对它做了一些进一步的测试。 似乎,如果我在执行 SPI 传输后立即调用 k3conf dump ,状态会在短时间内打开。 并且在组中发生变化、这意味着如果 I 在 MAIN_spi0 或 MAIN_spi3 上进行传输、所有 SPI0~3 都将处于导通状态、如果在 MAIN_spi5 或 MAIN_spi6 上进行传输、所有 SPI4~7 都将处于导通状态。

下面附上了完整的 dmesg 日志。

e2e.ti.com/.../3515.dmesg.txt

此致、

MIAN

尊敬的 Takuma：

我捕获了 SPI 无法通过 逻辑分析仪与 DRV8889 通信的信号。 信号似乎非常正确。 因此、我认为问题更有可能是由于驾驶员没有读取 MTSR 线路上的信号。

此致、

MIAN

尊敬的 Mian：

似乎主域中的所有 SPI 器件都处于关闭状态。 也许这是我问题的原因吗？

PM 功能仍处于打开状态。 作为替代方案、作为一个实验、应该可以从用户空间关闭它们。 是否可以在 sysfs 中的某个位置找到 spidev 设备并将“on"写入“写入。 命令如下所示： echo “on">“>/sys/devices/.../power/control

我捕获了 SPI 无法通过 逻辑分析仪与 DRV8889 通信的信号。 信号似乎非常正确。 因此、我认为问题更有可能是由于驱动程序没有读取 MTSR 线路上的信号。

我同意。 这些信号看起来是正确的。

作为一个实验、您能否尝试删除“ti、pindir-d0-out-d1-in“属性？ 根据原理图 、当前 DTS 看起来很好、并且 pindir 属性应该正确。 然而,这将是一个快速的实验双重确认,只是在 d0/D1 行混合了某种方式。 D0/D1 交换是 McSPI 的常见问题。

此致、

Takuma

尊敬的 Takuma：

我尝试了 sysfs 接口打开设备、但返回的状态 k3conf 转储 命令仍处于关闭状态、同时 CSL 线的切换仍然存在。 结果附于下文。

我还尝试通过 k3conf 工具打开设备,例如 k3conf 启用设备 376 。 执行命令后、k3conf 转储返回的状态将切换为打开、但在如下图所示的情况下、SPI 根本无法通信、这对我来说是非常意外的。

删除 DTS 中的“ti、pindir-d0-out-d1-in“属性后、器件仍然无法工作。

此致、

MIAN

尊敬的 Mian：

您能否分享完整的 DTS 以供审核？

此致、

Takuma

尊敬的 Takuma：

请找到我的 DTS 附件。

e2e.ti.com/.../k3_2D00_j784s4_2D00_j742s2_2D00_evm_2D00_common.zip

此致、

MIAN

尊敬的 Mian：

我看了一下整个 DTS。 两个问题：

• 我看到 main_spi3 与 main_cpsw1 存在一些引脚冲突。 main_cpsw1 相关节点大部分已关闭、但 仍启用了 main_cpsw1_port1。 您能尝试也禁用这个节点吗？
•  当假设无法读取 SPI 总线时、spidev1.0 日志先前共享、此时该日志正在读取错误寄存器。 但是否有可能一条总线不工作、而是一条总线实际工作、不会产生错误？

此致、

Takuma

尊敬的 Takuma：

禁用 节点  main_cpsw1_port1 后、结果保持不变。

不太可能。 从  上面发布的日志分析器和示波器快照中、您可以看到、当 SPI-PIPE 读取 0x00 时、MRST 上的信号不是 0x00。 实际上、我已经读取了 spidev1.0 的所有寄存器、结果都是 0x00、这是无法实现的。

此致、

MIAN

尊敬的 Mian：

如果 所有寄存器均为 0x0、则说明这更多是读取问题。 您能否添加以下补丁并在将事务发送到 drv8889 时共享“dmesg"中“中的完整日志和日志？

e2e.ti.com/.../0001_2D00_Enable_2D00_more_2D00_verbose_2D00_boot_2D00_logs_2D00_and_2D00_print_2D00_in_2D00_CS_2D00_toggli.patch

此致、

Takuma

尊敬的 Takuma：

应用您提供的补丁后、我在每个 spi0.1 和 spi1.0 器件上执行了两次传输。 spi0.1 的读数正常、spi1.0 的读数异常。 有关命令执行状态和 dmesg 输出、请参阅以下屏幕截图和日志。

e2e.ti.com/.../7418.dmesg.txt

此致、

MIAN

尊敬的 Mian：

感谢您试用。 看起来 CS 仍然在切换。 让我看看是否可以详细了解驱动程序并分享一些禁用切换的补丁程序。 我有天可以做这件事吗？

此致、

Takuma

尊敬的 Mian：

您能尝试一下这个补丁吗？

e2e.ti.com/.../0001_2D00_Remove_2D00_PM_2D00_from_2D00_McSPI_2D00_driver.patch

可以确认切换的调试日志未打印出来。 但是、k3conf 仍会报告 McSPI 动态关闭和打开。

此致、

Takuma

尊敬的 Takuma：

应用该补丁后、切换 CS 的调试打印确实会消失、但下拉波仍然存在、请参阅  下面的示波器快照。

spi1.0 仍然不起作用。

此致、

MIAN

尊敬的 Mian：

让我们一步一步。

1.是否可以禁用 3 个 SPI 接口并只保留 spidev0.1？

2.然后编辑 dts、使 ti、spi-num-cs =<1>？  

3.然后转接并显示日志。 我认为、之前的屏幕截图显示了将 0x40 写入到地址 0x0。 0x0 是一个只读故障状态寄存器。 是否可以读取或写入 R/W 这一不同地址？

此致、

Takuma

尊敬的 Takuma：

 1.是否可以禁用 3 个 SPI 接口并只保留 spidev0.1？

我已经尝试过、但它不起作用；

 2.然后编辑 dts、使 ti、spi-num-cs =<1>？

该属性与 CS 线路选择有关、即 寄存器 属性。 如果将该属性的值设置为 1、则只能使用 CS0、这与我的硬件不匹配、否则 spidev 探测器将失败。  

 3. 然后转接并显示日志。 我认为、之前的屏幕截图显示了将 0x40 写入到地址 0x0。 0x0 是一个只读故障状态寄存器。 是否可以读取或写入 R/W 这一不同地址？

实际上、通过“x00\x40、我尝试在地址 0x00 处读取数据。 0x40 实际上是地址 0x00、并添加了读取标志。 0x00 字节只是占位符、因此无关紧要。 您可以参阅 DRV8889 的文档、如下所示。

实际上、现在更关键的问题是 spidev1.0 无法读取或写入。 CS 信号的异常下拉可能会导致器件报告失败、但不会影响寄存器读取和写入操作。 也许我们可以首先关注 spidev1.0 (MAIN_spi3) 问题？

此致、

MIAN

尊敬的 Mian：

也许我们可以首先关注 spidev1.0 (MAIN_spi3) 问题？

没问题。 但是、与使用器件树的其他 SPI 实例相比、并没有什么特别之处。 唯一需要注意的是使用相同引脚的 CPSW2G 模块、但这些引脚会在器件树中注释掉。

但为了重新检查、您能否使用 devmem2 读取以下存储器地址的内容： 0x0011C0C0 和 0x0011C0BC

此致、

Takuma

尊敬的 Mian：

在上一次响应点击“Send"时“时、我记得 SoC 有一个奇怪的问题、这可能是 MAIN_spi3 无法正常工作的原因。 某些 SPI 模块内部连接用于调试/测试、MAIN_spi3 就是这样的一个实例：

您可以查看 0x40F04060 寄存器吗？ 如果它是 0x0、则请向此寄存器写入 0x1。

此致、

Takuma

尊敬的 Takuma：

将寄存器  0x40F04060 的值设置 为 0x1 后、我的 spid1.0（即 MAIN_spi3）可以读取和写入。

我想知道这个寄存器的值是否可以通过器件树进行配置。 否则,我必须使用 devmem2 命令来实现它。

此致、

MIAN

尊敬的 Mian：

请尝试以下补丁：

e2e.ti.com/.../0001_2D00_k3_2D00_j784s4_2D00_Add_2D00_node_2D00_to_2D00_disable_2D00_loopback_2D00_connection.patch

此致、

Takuma

尊敬的 Takuma：

该补丁解决了 main_spi3 问题。 非常感谢。 现在我们可以恢复到 CS 下拉问题。

此致、

MIAN

尊敬的 Mian：

对于 CS 下拉问题、我已经仔细检查了所有代码和寄存器写入、除了 PM 自动挂起功能之外没有其他软件可以切换 CS。 我已经确认、在启用 PM 的情况下、如果我非常快速（在一秒内）发送事务、则不会发生切换、但如果我稍后发送事务、则会发生切换。  

0001-Remove-PM-From-mcspi-driver.patch

^如果上次构建失败、您可以重试此补丁吗？

此致、

Takuma  

尊敬的 Takuma：

我已重试此补丁并确认其自 调试日志调试以来生效：切换 CS 已消失。 但是、使用如下所示的逻辑分析仪采集数据时、下拉电阻仍然存在。

是否有任何硬件因素导致了这种现象？ 您可以尝试在评估板上重现此问题吗？ 谢谢。

此致、

MIAN

尊敬的 Mian：

我也可以在 TI EVM 板上看到这种现象。

这行代码似乎导致了 CS： https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/spi/spi.c?h=ti-linux-6.12.y#n1122 的切换。 这来自上游 Linux、因此无法确定该代码行的重要性。  但是、我连接了示波器、可以看到如果我在链接的源代码中注释掉第 1122 行、CS 切换不再发生。

此致、

Takuma

尊敬的 Takuma：

因此、我想没有适当的方法来处理 CS 下拉问题？

此致、

MIAN

尊敬的 Mian：

没有正确的方法。 这看起来是 McSPI 的默认行为。  

虽然,实验中,如果修复 DRV8889 上的错误是必不可少的,你可以尝试注释掉我之前代码中提到的代码行。

此致、

Takuma

尊敬的 Takuma：

实际上、当我注释掉 drivers/spi/spi.c 的第 1122 行并重新编译和替换内核映像时、仍会在 CS 线路上出现下拉、DRV8889 仍报告错误。

我们的测试条件之间是否有任何差异？

此致、

MIAN

尊敬的 Mian：

我不这么认为、除了硬件。 没有 SPI 器件连接到 SPI 接口。 我使用示波器进行了检查、确认在传输前也看到了 CS 线路的切换、对于我这边、当我注释掉该行时、切换消失。  

我建议您检查 Linux SPI 框架中 CS 设置的所有实例和 McSPI 驱动程序、并确定系统的切换来自何处。 我方面做的是在所有 CS 写入+延时时间之前放置一个 printk 语句、以便我可以看到哪些对 CS 的写入导致了示波器上的切换。

此致、

Takuma

尊敬的 Takuma：

我想知道您的电路板的 CS 线路上是否存在上拉电阻器？

此致、

MIAN