## 导语


在嵌入式 Linux 驱动开发中，最常见的挫败感莫过于：**代码看起来全对，但硬件就是不工作。**

这篇文章记录了我调试 i.MX6ULL SPI DAC 驱动时遇到的一个极其隐蔽的问题——SPI 的 CS（片选）引脚莫名其妙地处于输入模式，导致 DAC 完全不工作。整个排查过程跨越了 SPI 核心层、SPI 控制器驱动、GPIO 子系统、pinctrl 子系统、Runtime PM 五个内核子系统，涉及内核源码阅读、硬件寄存器直接操作、调试打印注入、调用栈追踪等多种调试手段。

如果你也遇到过"GPIO 方向莫名其妙被改"的怪问题，这篇文章应该能给你一些启发。


----

## 1. 现象：CS 不受控，DAC 不工作


开发板是 100ask i.MX6ULL，内核 4.9.88。通过 spidev 访问 TLC5615 DAC，CS 引脚是 gpio-122（GPIO4_IO26，对应 CSI_DATA05 pad）。

问题表现很直观：

```
# 查看 GPIO 状态
cat /sys/kernel/debug/gpio | grep 122
gpio-122 (                    |spi_imx             ) in  hi
#                                                     ↑↑  方向是输入！

# 测 DAC — 没反应
./dac_test /dev/spidev0.0 500
Pre val = 0
```
明明代码里调了 `gpio_direction_output()`，为什么 GPIO 还是 `in`？

更诡异的是，`spi_imx_chipselect()` 里加了 dev_info 打印，发现**传输时这个函数根本没被调用**。但 SPI 核心代码里确实有 CS 控制的逻辑——这到底是怎么回事？


----

## 2. 第一层：先确认硬件是不是通的


不管软件多复杂，先确认硬件链路是好的。i.MX6UL 的 GPIO 寄存器是内存映射的，可以直接用 `devmem` 读写：

```
# GPIO4 基地址 0x020A8000
# GPIO4_GDIR (方向寄存器) = base + 0x04 = 0x20a8004

# 手动写 GDIR bit26 = 1（设为输出）
devmem 0x20a8004 32 0x04000000

# 确认
cat /sys/kernel/debug/gpio | grep 122
gpio-122 (                    |spi_imx             ) out hi
#                                                     ↑↑  变输出了！

# 测 DAC — 工作！
./dac_test /dev/spidev0.0 500
Pre val = 0
./dac_test /dev/spidev0.0 1000
Pre val = 500
```
**硬件链路是通的。** IOMUX 配置正确（ALT5 = GPIO 模式），GPIO 控制器到 pad 的物理连接没问题。问题100%在软件层——方向被人清掉了。


----

## 3. 第二层：SPI 传输时 CS 到底谁在管？


在深入根因之前，先搞清楚一个让很多人困惑的问题：为什么 `spi_imx_chipselect()` 传输时不打印？

追踪 SPI 核心层代码（`spi.c`）：

```
static void spi_set_cs(struct spi_device *spi, bool enable)
{
    if (spi->mode & SPI_CS_HIGH)
        enable = !enable;

    if (gpio_is_valid(spi->cs_gpio))                    // ← gpio-122 有效
        gpio_set_value(spi->cs_gpio, !enable);          //    直接操作 GPIO
    else if (spi->master->set_cs)                       // ← 没有 cs_gpio 才回调驱动
        spi->master->set_cs(spi, !enable);
}
```
真相大白：**有 `cs_gpio` 时，SPI 核心层直接调用 `gpio_set_value()` 操作 GPIO，根本不回调驱动的 `chipselect()`。** `chipselect()` 只在驱动加载时的 `spi_imx_setup()` 中被调用一次。

所以传输入 `chipselect` 没打印是**正常行为**，不是 bug。


----

## 4. 第三层：方向到底在哪里被清的？


### 4.1 排查方向一：request 顺序？


一开始怀疑是 probe 中 `spi_bitbang_start()` 和 `devm_gpio_request()` 的执行顺序问题。看 probe 代码：

```
spi_imx_probe() {
    // 先调 spi_bitbang_start → 内部触发 spi_imx_setup
    ret = spi_bitbang_start(&spi_imx->bitbang);
        // → spi_add_device() → spi_setup() → spi_imx_setup()
        //   → gpio_direction_output(122,1)  设方向

    // 后调 devm_gpio_request
    for (i = 0; i < master->num_chipselect; i++) {
        devm_gpio_request(master->cs_gpios[i], ...);
        // gpio_direction_output 被注释掉了
    }
}
```
加调试打印看看 `gpio_direction_output` 到底返回了什么：

```
if (gpio_is_valid(spi->cs_gpio)){
    dev_info(&spi->dev, "calling direction_output\n");

    ret = gpio_direction_output(spi->cs_gpio, ...);
    if (ret)
        dev_err(&spi->dev, "direction_output failed: %d\n", ret);
    else
        dev_info(&spi->dev, "direction_output OK\n");
}
```
dmesg 输出：

```
spi spi0.0: calling direction_output
spi spi0.0: direction_output OK        ← 返回了 0（成功）
```
方向设置成功了？那为什么最终 GDIR 还是 0？

### 4.2 直接读硬件寄存器


在 `spi_imx_setup()` 和 probe 末尾各读一次 GDIR：

```
{
    void __iomem *gpio4 = ioremap(0x020A8000, 0x10);
    if (gpio4) {
        u32 gdir = readl(gpio4 + 4);
        dev_info(&spi->dev, "GDIR=0x%08x bit26=%d\n", gdir, (gdir >> 26) & 1);
        iounmap(gpio4);
    }
}
```
输出：

```
GDIR after direction_output=0x04000000 (bit26=1)    ← ✅ 方向设成功了！
GDIR after gpio_request=0x00000000 (bit26=0)         ← ❌ request 后被清了！
```
**元凶就是 `devm_gpio_request()`。** 它在内部把 GDIR 从 1 改回了 0。

### 4.3 溯源：pinctrl 干的？


第一个怀疑对象是 pinctrl。`devm_gpio_request()` → `gpio_request()` → `gpiod_request()` → 最终调用 `gpiochip_generic_request()` → `pinctrl_request_gpio()`。

仔细读了 `pinmux.c` 中的 `pin_request()`：

```
static int pin_request(...)
{
    ...
    if (gpio_range && ops->gpio_request_enable)
        status = ops->gpio_request_enable(pctldev, gpio_range, pin);
    // 只回调 pinctrl 驱动的 gpio_request_enable
    // 但这个回调在 i.MX pinctrl 中没有实现
    ...
}
```
查看 `pinctrl-imx.c` 的 `pinmux_ops`：

```
static const struct pinmux_ops imx_pmx_ops = {
    .get_functions_count = imx_pmx_get_funcs_count,
    .get_function_name = imx_pmx_get_func_name,
    .get_function_groups = imx_pmx_get_groups,
    .set_mux = imx_pmx_set,
    .gpio_set_direction = imx_pmx_gpio_set_direction,
    // ↑ gpio_request_enable 没实现
};
```
**pinctrl 层没有清 GDIR。排除。**

### 4.4 真凶：Runtime PM 的 save/restore


线索指向了 `mxc_gpio_request()` 中的 `pm_runtime_get_sync()`：

```
static int mxc_gpio_request(struct gpio_chip *chip, unsigned offset)
{
    struct mxc_gpio_port *port = gpiochip_get_data(chip);
    int ret;

    if (port->gpio_ranges)
        ret = gpiochip_generic_request(chip, offset);

    ret = pm_runtime_get_sync(chip->parent);    // ← ⚠️
    return ret < 0 ? ret : 0;
}
```
`pm_runtime_get_sync()` 如果设备之前 suspend 过，会触发 runtime resume → `mxc_gpio_restore_regs()`：

```
static void mxc_gpio_restore_regs(struct mxc_gpio_port *port)
{
    ...
    writel(port->saved_reg[3], port->base + GPIO_GDIR);  // 恢复旧 GDIR
    writel(port->saved_reg[5], port->base + GPIO_DR);
    ...
}
```
而 `saved_reg[3]` 在更早的 runtime suspend 时被保存过：

```
static void mxc_gpio_save_regs(struct mxc_gpio_port *port)
{
    ...
    port->saved_reg[3] = readl(port->base + GPIO_GDIR);  // 保存当时的值
    ...
}
```
### 4.5 加打印验证


在 `mxc_gpio_request()` 和 `mxc_gpio_restore_regs()` 中加调试打印：

```
// mxc_gpio_request 中
dev_info(chip->parent, "V2 req before: GDIR=0x%08x off=%d\n",
         readl(port->base + GPIO_GDIR), offset);

ret = pm_runtime_get_sync(chip->parent);

dev_info(chip->parent, "V2 req after:  GDIR=0x%08x off=%d\n",
         readl(port->base + GPIO_GDIR), offset);

// mxc_gpio_restore_regs 中
dev_info(port->gc.parent, "V2 restore_regs: writing GDIR=0x%08x\n",
         port->saved_reg[3]);
```
输出：

```
[2.434] GDIR after direction_output=0x04000000 (bit26=1)  ← ✅ 方向设成功
[2.442] V2 req before: GDIR=0x04000000 off=26             ← ✅ request 进来时方向还在
[2.448] V2 restore_regs: writing GDIR=0x00000000          ← ❌ 恢复旧值！
[2.469] V2 req after:  GDIR=0x00000000 off=26             ← ❌ request 完被清了
```
**铁证如山！**


----

## 5. 完整时序还原


```
[1.17] GPIO4 probe → pm_runtime_put (usage=0)
[1.??] runtime PM 检测到空闲
       → mxc_gpio_runtime_suspend()
         → mxc_gpio_save_regs()
           → saved_reg[3] = GDIR = 0x00000000  ← 此时方向还没人设

[2.42] spi_imx_setup → gpio_direction_output(122,1)
       → GDIR = 0x04000000  ← ✅ 设成功了

[2.44] devm_gpio_request(122)
       → mxc_gpio_request()
         → pm_runtime_get_sync()
           → mxc_gpio_runtime_resume()
             → mxc_gpio_restore_regs()
               → writel(saved_reg[3]=0x00000000, GPIO_GDIR)  ← ❌ 覆盖了刚设的方向！
```
**这就是完整的根因链。**


----

## 6. 修复


修复极其简单——在 probe 末尾的 `devm_gpio_request()` 后面补一行 `gpio_direction_output()`：

```
for (i = 0; i < master->num_chipselect; i++) {
    if (!gpio_is_valid(master->cs_gpios[i]))
        continue;

    ret = devm_gpio_request(&pdev->dev, master->cs_gpios[i],
                DRIVER_NAME);
    if (ret) {
        dev_err(&pdev->dev, "Can't get CS GPIO %i\n", ...);
        goto out_clk_put;
    }

    /* 修复：Runtime PM resume 会恢复旧的 GDIR 值，重新设方向 */
    gpio_direction_output(master->cs_gpios[i], 1);
}
```
这个 bug 的修复虽然只有一行代码，但找到这一行，我走了五层内核子系统。


----

## 7. 总结与思考


### 7.1 调试方法论


这是整个调试过程中最宝贵的收获——**分层调试法**：

```
L5 应用层     dac_test
L4 SPI 核心层  spi.c (spi_set_cs)
L3 控制器驱动  spi-imx.c (spi_imx_setup)
L2 GPIO 子系统 gpiolib (gpio_direction_output)
L1 硬件寄存器  GDIR / DR / devmem
```
从 L1 开始向上验证，每层只回答一个"是/否"问题，不跳层、不猜测。**手动写 GDIR 后 DAC 工作了 → 硬件链路没问题，问题在软件层。** 就这一句话，排除了所有硬件相关的可能性。

### 7.2 调试工具清单


|工具/方法|用途|
|:-:|:-:|
|`devmem`|直接读写硬件寄存器，绕过所有软件层|
|`/sys/kernel/debug/gpio`|GPIO 子系统的软件视角|
|`/sys/kernel/debug/pinctrl/.../pinmux-pins`|IOMUX/pinctrl 配置状态|
|`dmesg` + 版本打印|确认代码是否真的更新了|
|`strings /boot/zImage \| grep MARK`|确认字符串是否编译进镜像|
|`ioremap` + `readl`|在内核代码中读硬件寄存器|
|`dump_stack()`|打印调用栈，确认调用路径|
|`/proc/kallsyms`|查看函数符号地址，确认代码路径|

### 7.3 经验教训


1. **永远检查 `gpio_direction_output()` 的返回值。** 它可能因为各种原因失败，返回值却被忽略。

2. **`devm_gpio_request()` 内部有副作用。** Runtime PM 的 save/restore 机制会缓存和恢复 GPIO 寄存器状态，如果方向是在 request 之前设的，会被 restore 覆盖。

3. **`spi_imx_chipselect()` 传输时不调是正常行为。** 有 `cs_gpio` 时 SPI 核心层绕过驱动回调，直接操作 GPIO。

4. **不要跳过返回值检查。** 这次 bug 能隐藏这么久，核心原因就是 `gpio_direction_output()` 的返回值在所有路径上都被忽略了。

5. **版本打印是最便宜的确认手段。** `dev_info` + 唯一标记字符串 → `strings /boot/zImage | grep`，确认代码更新了没有，比猜要高效得多。


----

## 后记


这个 bug 从现象看到根因，经历了整整几天的代码追踪。问题是 SPI 驱动里的，根因却在 GPIO 驱动的 Runtime PM 里——这就是内核开发的常态：**问题的表象和根因往往不在同一个子系统里。**

但正因为如此，每次跨越多个子系统的调试，都是对内核架构理解的一次深化。搞懂了一个问题，就搞懂了 SPI、GPIO、pinctrl、Runtime PM 四个子系统之间的协作关系。这笔账怎么算都值。

在嵌入式 Linux 驱动开发中，最常见的挫败感莫过于：代码看起来全对，但硬件就是不工作。

i.MX6ULL SPI CS 方向异常调试纪实：一次跨越五层内核子系统的追凶之旅

硬件

操作系统

探索i.MX6ULL SPI DAC驱动调试：CS引脚被RuntimePM机制意外重置为输入模式，导致DAC不工作。通过逐层排查SPI核心、GPIO、pinctrl及RuntimePM子系统，发现gpio_request触发runtime resume恢复旧GDIR值覆盖方向设置。修复方案为在request后重设输出方向，深入揭示多子系统交互隐患。

内存映射

Linux

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

探索i.MX6ULL SPI DAC驱动调试：CS引脚被RuntimePM机制意外重置为输入模式，导致DAC不工作。通过逐层排查SPI核心、GPIO、pinctrl及RuntimePM子系统，发现gpio_request触发runtime resume恢复旧GDIR值覆盖方向设置。修复方案为在request后重设输出方...

i.MX6ULL SPI CS 方向异常调试纪实：一次跨越五层内核子系统的追凶之旅-腾讯云开发者社区-腾讯云

i.MX6ULL SPI CS 方向异常调试纪实：一次跨越五层内核子系统的追凶之旅

i.MX6ULL SPI CS 方向异常调试纪实：一次跨越五层内核子系统的追凶之旅

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐