Linux SPI调试方法

1 SPI调试整体思路

前面说了这么多，真正的问题是怎么用起来，出了问题怎么定位解决？

前面对整个框架都有了概念，简化模型如下：

出了问题从上面四个框架一一排查。

问题分为以下四大类：

• 设备节点没出现，/sys/bus/spi/devices/ 下面没设备；这时就要排查 DTS、SPI Controller 和 spi_device 等
• 设备出现，但是 probe 失败，检查 compatible 匹配、driver 注册和 probe 返回值等
• probe 成功，但是读写失败，检查 SPI 参数，使用 mode，CS 等
• 性能问题，检查 transfer 的耗时，CPU 占用，DMA 等

2 查看SPI设备注册状态

查看 SPI 设备：

ls /sys/bus/spi/devices/

比如：

spi0.0
spi1.1
spiX.Y

上面表示什么呢？如下：

前面一个数字 X 表示控制器编号，后面一个数字 Y 表示片选编号。结合起来就是 SPI 控制器 X 上的 CSY 设备。对应框架里面 struct device。

以泰山派为例子：

3 dmesg分析SPI初始化流程

关于 Linux 日志的事情我们会单开一个系列讲解，这里只需要知道通过 dmesg 能帮助我们进行 SPI 驱动开发。

比如我们在驱动里面注入下面的代码：

dev_info(&pdev->dev, "registered master spi0\n");

在 dmesg 里面就会找到：

spi-rockchip fe610000.spi: registered master spi0

4 sysfs查看SPI设备绑定

我们怎么查看 spiX.Y 具体绑定的是哪个设备呢？

比如：

cd /sys/bus/spi/devices/spi0.0
ls
driver
modalias
of_node

进入过后会看到类似上面的信息。

查看绑定：

readlink driver

会看到类似：

../../../bus/spi/drivers/icm42688

说明 device 设备 spiX.Y 绑定的 driver 是上面那个。

没有的话，就是匹配失败了。

以泰山派为例子：

5 spidev用户态测试

我们可以使用内核自带的 spidev 驱动，让用户态程序直接发送和接收 SPI 数据，用来验证接线、时钟、CS、SPI 模式等硬件是否正常。

相当于一个字符设备接口：

ls /dev/spidev*
/dev/spidev0.0

上面这种方式和 spi_driver 有什么区别呢？

spidev 只是一个设备，只知道发送哪些字节、接收多少字节、SPI 模式等，并不知道具体的传输协议，只负责原始的字节收发。而专用的 spi_driver = SPI 传输 + 芯片协议 + Linux 子系统接口。

整个流程对比如下：

6 ftrace追踪SPI传输

开启 trace 事件后，查看：

cat available_events | grep spi
spi:spi_transfer_start
spi:spi_transfer_stop

之后就能跟踪 SPI 传输。

7 总结

SPI 调试需要按照 Linux SPI Framework 层次进行分析。从设备树创建 spi_device，到 driver 绑定，再到 SPI 数据传输，每一层都有对应的调试方法。