第3章 高频技术面试问题（设备树、中断、DMA）
设备树、中断和 DMA 是 BSP 测试面试中最常被深挖的三个技术模块。面试官通常通过这些问题评估候选人对底层硬件抽象、内核机制以及测试场景设计的理解深度。下面用一张回答框架图梳理核心答题逻辑，随后展开三个典型问答卡片和一个实战项目模板。
知识结构对比表
| 模块 | 核心概念 | 典型面试点 | 测试关注 |
|---|---|---|---|
| 设备树 | 节点、属性、compatible、reg、中断映射 | 匹配流程、of_系列API、dts语法 | 节点覆盖、属性值校验、资源冲突 |
| 中断 | IRQ number、触发方式、中断上下文、上半部/下半部 | request_irq、中断嵌套、软中断/tasklet | 中断延迟、丢失、共享中断、嵌套测试 |
| DMA | 描述符链、传输方向、一致性映射、dma_alloc_coherent | 环形缓冲区、SG列表、cache一致性 | 传输完整性、超时、错误处理、压力测试 |
📌 问答卡片1：设备树匹配流程
面试问题： 请简述Linux驱动中设备树节点的匹配过程，以及常用的API。
🎯 面试官考察点： 是否理解设备树与驱动绑定的核心机制；对 of_match_table、platform_driver_register 的掌握程度。
回答框架： ① 设备树在启动时被解析为 platform_device；② 驱动注册时检查 of_match_table 中的 compatible 字符串；③ 匹配成功后调用 probe；④ 常用 API：of_match_node、of_property_read_u32。
简短示例回答： “内核启动时根据设备树创建 platform_device，驱动通过 platform_driver_register 注册。匹配时遍历驱动中的 of_match_table 与设备节点的 compatible 属性比对。匹配成功则执行 probe，并可用 of_get_property 读取时钟、中断等资源。”
可能追问： 如果两个驱动使用相同的 compatible 会怎样？如何在 DTS 中配置中断？
📌 问答卡片2：中断上半部与下半部
面试问题： 为什么需要中断上半部和下半部？请列举下半部的实现机制。
🎯 面试官考察点： 是否理解中断上下文限制（不可休眠、不能长时间占用）；对不同下半部机制（tasklet、workqueue、threaded IRQ）的适用场景。
回答框架： ① 上半部处理紧急硬件操作（如清中断标志）→② 下半部处理耗时任务（如数据拷贝）；③ 比较 tasklet（软中断上下文，不可阻塞）、workqueue（进程上下文，可阻塞）、threaded IRQ（自动创建内核线程）。
简短示例回答： “中断上下文不能休眠，因此将耗时任务推迟到下半部执行。上半部只做最小必要操作如读取状态寄存器；下半部使用 workqueue 处理数据，因为它允许阻塞（如分配内存）。如果要求实时性，可使用 threaded IRQ 配合实时内核。”
可能追问： 上下半部之间如何同步？tasklet 与 softirq 的区别是什么？
📌 问答卡片3：DMA传输的一致性与调试
面试问题： 在DMA传输中，如何保证CPU与设备之间的数据一致性？你遇到过哪些DMA相关的问题？
🎯 面试官考察点： 对 cache 一致性、DMA 映射 API（一致性映射/流式映射）的理解；实际调试经验（如描述符错误、总线错误）。
回答框架： ① 一致性映射（dma_alloc_coherent）保证CPU和DMA看到相同内存；② 流式映射（dma_map_single）配合 dma_sync_single_for_cpu/device 手动维护一致性；③ 常见问题：描述符未更新、超时、cache 污染。
简短示例回答： “使用 dma_alloc_coherent 分配 DMA 缓冲区，硬件自动维护一致性。若使用流式映射，则在传输前调用 dma_map_single，传输完成后用 dma_sync_single_for_cpu 刷新 cache。曾经遇到描述符链末尾未置 valid 位导致 DMA 停止，通过读寄存器值定位。”
可能追问： DMA 描述符环的大小如何选择？遇到传输超时怎么排查？
📁 项目案例：智能摄像头传感器BSP测试
项目名称： V1.0 智能摄像头 Sensor 子系统的 BSP 集成测试
业务背景： 某 AIoT 厂商自研 4K 摄像头模组，需在 Linux 环境下完成 Sensor 驱动、ISP 模块的 BSP 测试，确保图像采集、传输、中断处理及 DMA 路径正确。
规模指标： 测试涉及 3 个 Sensor 型号、8 路 MIPI 通道、2 个 DMA 通道、平均帧率 30fps，持续运行 72 小时稳定性测试。
技术栈： Linux 5.10 + ARM64、设备树（dts）、V4L2 框架、中断（GPIO + SPI）、DMA Engine、CMA 内存。
核心难点：
- 设备树节点复用导致 I2C 地址冲突，驱动 probe 失败
- 中断上下文中使用 GFP_KERNEL 分配内存导致内核警告
- DMA 描述符未正确设置 next 指针造成链表断裂，传输 hang
面试高频追问：
- 如何快速定位是 DTS 问题还是驱动问题？
- 中断上下文申请内存用什么 flags？为什么？
- DMA 传输完成后如何通知 CPU？如果通知丢失怎么排查？
可迁移回答话术： “在该项目中，我们通过分层验证：先利用 sysfs 检查设备树节点创建；再通过 tracepoint 监控中断触发；最后注入错误描述符来验证 DMA 超时处理逻辑。这套从设备树→中断→DMA 的串行故障隔离思路，可以复用到任何基于 Linux 的 BSP 测试中。”