1. 项目概述从硬件片选到软件片选的驱动实践最近在调试一块基于I.MX6ULL的工控板板上挂载了多个SPI设备包括一个Flash和一个温湿度传感器。硬件工程师在设计时为了节省GPIO将Flash的片选CS直接接到了SPI控制器的硬件片选引脚上而传感器则使用了一个普通的GPIO进行控制。在编写Linux内核驱动时这个看似简单的差异却让我在spi-imx主机控制器驱动里折腾了大半天。最终问题核心落在了如何正确理解和配置SPI主机控制器驱动中的“软件片选”与“硬件片选”模式。这不仅仅是I.MX6ULL平台的特有问题而是所有嵌入式Linux开发者在进行多SPI设备驱动时都可能踩到的坑。今天我就把这个过程掰开揉碎了讲清楚特别是spi-imx.c这个驱动里关于片选处理的那些“潜规则”。简单来说硬件片选是指SPI控制器内部有专用的片选逻辑电路和物理引脚在发起传输时控制器会自动控制对应CS引脚的电平。而软件片选则是驱动程序通过操控一个普通的GPIO引脚在传输前后手动拉低和拉高来模拟片选信号。在Linux的SPI子系统框架下这两种模式的选择和配置很大程度上取决于设备树Device Tree的描述以及驱动程序的实现细节。对于I.MX6ULL其spi-imx驱动对这两种模式的支持已经相当完善但如果不理解其内在逻辑配置起来就很容易出错导致设备无法通信或者片选信号时序混乱。2. SPI片选机制深度解析硬件与软件的抉择要搞定驱动首先得从原理上明白为什么要有这两种片选方式以及它们各自的优劣。2.1 硬件片选控制器的“原生技能”硬件片选是SPI控制器的标准功能。以I.MX6ULL的eCSPI模块为例其控制器内部集成了片选状态机。当驱动通过spi_message提交一个传输请求时控制器硬件会在数据时钟SCLK产生之前自动将指定的片选线例如SS0、SS1拉低有效并在整个传输帧结束后自动将其拉高无效。这个过程是硬件自动完成的精确且高效不占用CPU资源。它的优点非常明显时序精准片选信号由硬件产生与数据时钟的同步性极佳能满足高速SPI设备如Flash的严苛时序要求。节省CPU完全由硬件自动处理CPU只需配置好传输参数即可。支持多从机控制器通常提供2-4个硬件片选引脚可以直接连接多个设备。但缺点也同样突出引脚固定硬件片选引脚是控制器专用的数量有限I.MX6ULL的每个SPI控制器通常有2-4个且无法映射到任意GPIO上。灵活性差一旦硬件设计定型哪个设备用哪个CS引脚就固定了软件难以动态调整。2.2 软件片选驱动程序的“灵活补丁”当硬件片选引脚不够用或者硬件设计使用了非专用的GPIO作为片选时就需要软件片选出马。此时驱动程序需要在设备树中将片选GPIO定义为cs-gpios属性。在驱动代码中在spi_transfer开始前通过GPIO子系统手动将对应的GPIO拉低。在传输结束后再手动将其拉高。软件片选的优点在于极致的灵活性突破引脚限制理论上可以使用任何可用的GPIO作为片选数量几乎不受限。便于硬件设计硬件工程师布线时更自由无需拘泥于控制器的固定CS引脚。但其代价也不小时序精度依赖软件片选信号拉低/拉高的时机由软件控制其精度受内核调度、中断延迟等因素影响不适合对时序要求极高的设备。增加CPU开销每次传输都需要额外的GPIO操作指令。实现更复杂需要驱动程序正确处理片选GPIO的申请、配置和时序控制。2.3 Linux SPI子系统框架下的抽象Linux内核的SPI子系统drivers/spi/spi.c为我们统一了接口。它定义了一个spi_device结构体来代表一个SPI从设备其中包含一个chip_select成员。这个成员的值在硬件片选模式下代表控制器硬件CS的索引号如0, 1, 2...在软件片选模式下它通常没有硬件意义但驱动程序会用它来索引cs-gpios数组中对应的GPIO描述符。关键点在于主控制器驱动如spi-imx需要根据设备树提供的信息自行判断并处理这两种模式。这个判断逻辑正是我们调试的核心。3. I.MX6ULL SPI驱动片选处理源码探秘我们以Linux内核以5.x版本为例中的drivers/spi/spi-imx.c驱动为例深入看看它是如何实现这一机制的。3.1 设备树一切配置的源头设备树的描述决定了驱动行为的起点。一个典型的包含混合片选模式的SPI节点示例如下ecspi1 { cs-gpios gpio4 9 GPIO_ACTIVE_LOW, gpio4 10 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 pinctrl_ecspi1 pinctrl_ecspi1_cs; // pinctrl_ecspi1_cs 可能只包含硬件CS引脚 status okay; flash: spi-flash0 { compatible jedec,spi-nor; spi-max-frequency 40000000; reg 0; // 使用硬件CS0 }; sensor: temperature-sensor1 { compatible vendor,temp-sensor; spi-max-frequency 1000000; reg 1; // 理论上对应硬件CS1但这里我们想用软件片选 cs-gpios gpio4 10 GPIO_ACTIVE_LOW; // 关键子节点覆写指定使用GPIO4_10作为软件片选 }; };注意sensor节点里的cs-gpios属性。它在子节点中**覆写override**了SPI控制器节点中定义的cs-gpios数组。同时它的reg 1这个“1”在硬件片选语境下是CS1索引但在软件片选模式下其含义由驱动解释。3.2 驱动中的关键逻辑spi_imx-chipselect函数在spi-imx.c中片选控制的核心是一个函数指针spi_imx-chipselect。驱动在初始化时会根据配置为其赋予不同的函数。情况一使用硬件片选当设备使用硬件片选即设备树中未为该设备指定cs-gpios或指定的GPIO无效驱动会调用spi_imx_chipselect函数。这个函数直接操作控制器的寄存器控制硬件CS引脚的电平。static void spi_imx_chipselect(struct spi_device *spi, int is_active) { struct spi_imx_data *spi_imx spi_master_get_devdata(spi-master); int cs spi-chip_select; // 获取设备注册时的片选号 u32 ctrl_reg; ctrl_reg readl(spi_imx-base MX51_ECSPI_CTRL); if (is_active) { // 激活设备片选拉低 ctrl_reg | 1 (cs MX51_ECSPI_CTRL_CS_SHIFT); } else { // 取消激活片选拉高 ctrl_reg ~(1 (cs MX51_ECSPI_CTRL_CS_SHIFT)); } writel(ctrl_reg, spi_imx-base MX51_ECSPI_CTRL); }情况二使用软件片选当驱动通过of_get_gpio等函数成功从设备树中获取到该设备有效的cs-gpios时spi_imx-chipselect会被赋值为spi_imx_gpio_chipselect函数。static void spi_imx_gpio_chipselect(struct spi_device *spi, int is_active) { struct spi_imx_data *spi_imx spi_master_get_devdata(spi-master); int gpio spi_imx-chipselect[spi-chip_select]; // 通过chip_select索引获取GPIO号 gpio_set_value(gpio, is_active ? spi-mode SPI_CS_HIGH ? 1 : 0 : spi-mode SPI_CS_HIGH ? 0 : 1); }这个函数直接操作GPIO值。注意这里的spi-chip_select值来自设备树的reg属性被用作索引去spi_imx-chipselect[]数组中查找对应的GPIO号。这意味着在软件片选模式下reg属性的值主要是一个用于查找GPIO的“句柄”而不再直接对应控制器的硬件CS索引。3.3 初始化流程模式判断的十字路口驱动在spi_imx_setup()函数中为每个spi_device进行设置。其中关于片选的关键逻辑简化如下获取GPIO尝试从设备树节点中获取cs-gpios属性。判断模式如果成功获取到有效的GPIO描述符则将该GPIO配置为输出并存入spi_imx-chipselect[]数组同时将spi_imx-chipselect函数指针指向spi_imx_gpio_chipselect。如果获取失败返回负数则判定为使用硬件片选。此时会检查spi-chip_select是否超出了控制器硬件支持的最大CS数如果超出则报错。然后spi_imx-chipselect函数指针指向spi_imx_chipselect。关键避坑点这里有一个极易混淆的地方。假设控制器有2个硬件CSCS0 CS1。设备A使用硬件CS0reg 0。设备B想使用软件片选连接在GPIO4_10上。如果你在设备B的节点里写reg 2心想硬件CS只有0和12肯定就是软件片选了驱动在初始化B时会先尝试获取cs-gpios。如果获取成功没问题reg2会被当作软件片选数组的索引。但是如果获取失败比如GPIO号写错了或者pinctrl冲突驱动会回退到硬件片选模式然后检查reg2是否大于等于最大硬件CS数本例中是2因为2 2驱动可能会报错chipselect 2 out of range。所以即使打算用软件片选reg的值也最好在硬件CS数量范围内分配以避免回退时的错误。更稳妥的做法是确保cs-gpios属性正确无误。4. 实战配置与调试记录理解了原理我们回到最初的项目。我的设备树配置最终版本如下ecspi1 { cs-gpios gpio4 9 GPIO_ACTIVE_LOW; // 只定义了一个给硬件CS1备用不这里有个坑 pinctrl-names default; pinctrl-0 pinctrl_ecspi1; // 这个pinctrl只包含SCLK, MOSI, MISO不包含任何CS引脚 status okay; flash0 { compatible winbond,w25q128, jedec,spi-nor; spi-max-frequency 40000000; reg 0; // 没有cs-gpios使用硬件CS0。硬件CS0的引脚由pinctrl子系统单独控制例如pinctrl_ecspi1_cs0 }; sensor1 { compatible ti,tmp112; spi-max-frequency 1000000; reg 1; // 注意这里是1 cs-gpios gpio4 10 GPIO_ACTIVE_LOW; }; };同时在Pinctrl节点中我需要确保硬件CS0引脚例如ECSPI1_SS0被正确配置为SPI功能。用于软件片选的GPIO4_10被配置为GPIO输出功能并且初始状态为高电平无效。pinctrl_ecspi1: ecspi1grp { fsl,pins MX6ULL_PAD_UART4_TX_DATA__ECSPI1_SCLK 0x100b1 MX6ULL_PAD_UART4_RX_DATA__ECSPI1_MOSI 0x100b1 MX6ULL_PAD_UART3_TX_DATA__ECSPI1_MISO 0x100b1 ; }; pinctrl_ecspi1_cs0: ecspi1cs0grp { fsl,pins MX6ULL_PAD_UART3_RX_DATA__ECSPI1_SS0 0x100b1 // 硬件CS0 ; }; pinctrl_sensor_cs: sensorcsgrp { fsl,pins MX6ULL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x000b0 // 另一个GPIO示例初始状态为高 ; };重要心得控制器节点下的cs-gpios属性是一个“默认”列表。如果子设备节点没有自己的cs-gpios驱动会尝试使用这个列表中对应reg索引的GPIO。如果子设备节点明确指定了自己的cs-gpios则会覆盖默认值。但是一个常见的陷阱是如果你在控制器节点定义了cs-gpios即使子设备想用硬件片选驱动也可能优先尝试使用这个GPIO列表。最清晰的做法是计划使用软件片选的设备在其节点内显式定义cs-gpios计划使用硬件片选的设备其节点内不要定义cs-gpios并确保对应的硬件CS引脚被正确的pinctrl组配置。控制器节点的cs-gpios可以留空或不定义以避免干扰。5. 调试技巧与常见问题排查在实际驱动加载和设备通信测试中你可能会遇到以下问题5.1 问题一设备无响应片选信号无变化排查思路检查引脚复用使用cat /sys/kernel/debug/pinctrl/pinctrl-handles或devmem命令直接查看IOMUXC寄存器确认SCLK、MOSI、MISO以及CS引脚是否被正确复用到SPI功能或GPIO功能。这是最常见的问题根源。检查片选电平极性确认GPIO_ACTIVE_LOW或GPIO_ACTIVE_HIGH设置是否正确。用示波器或逻辑分析仪测量片选引脚观察在传输发生时电平是否跳变。如果应该是低电平有效却一直为高那设备自然不会响应。检查驱动加载dmesg | grep spi查看驱动加载日志是否有关于片选GPIO申请失败、索引超出范围等错误信息。使用逻辑分析仪这是最强大的工具。连接SCLK、MOSI、MISO和CS线发起一次SPI读取操作例如cat /sys/class/spi_master/spi1/spi1.1/device/xxx。观察CS信号是否在数据帧前后有效数据线上是否有波形。如果CS没动作说明片选控制逻辑未生效如果CS有动作但数据线没波形可能是传输本身没发起或者速率、模式不对。5.2 问题二多个设备互相干扰片选时序混乱排查思路确认片选独立性确保每个设备都有独立的片选线无论是硬件还是软件GPIO并且它们在物理上和配置上都不会同时有效。检查驱动中的chipselect函数在spi-imx.c的spi_imx_chipselect或spi_imx_gpio_chipselect函数中添加printk打印每个设备的片选操作日志确认在传输每个设备时正确的片选函数被调用。检查spi_message队列Linux SPI子系统支持将多个spi_transfer组织成一个spi_message并且可以设置spi_message-cs_change标志。如果cs_change为1表示在这次传输和下一次传输之间需要改变片选状态。确保你的多设备传输消息正确设置了这个标志。对于完全独立的两个设备传输更安全的做法是提交两个独立的spi_message。5.3 问题三软件片选设备通信不稳定偶发失败排查思路测量时序用逻辑分析仪重点测量软件片选GPIO的下降沿到第一个SCLK上升沿的延迟t_CS-SCK以及最后一个SCLK到CS上升沿的延迟t_SCK-CS。与设备数据手册要求对比。软件片选延迟较大可能在高速通信时不符合要求。内核配置与调度检查内核是否配置了CONFIG_PREEMPT可抢占式内核高系统负载下软件操作GPIO的延迟可能波动。对于低速传感器这可能没问题但对高速Flash就是灾难。考虑使用硬件片选或者降低SPI通信频率。GPIO驱动能力如果片选线上挂载的负载较重例如多个设备并联GPIO输出电流可能不足导致边沿变缓。在驱动代码中可以尝试在GPIO申请后调用gpio_set_direction()和gpio_set_value()之前通过Pinctrl子系统将该GPIO的驱动强度drive-strength配置为更高值。5.4 调试信息获取在内核配置中打开CONFIG_DEBUG_FS和SPI相关的调试选项可以挂载debugfs后查看更多信息cat /sys/kernel/debug/spi/spi1/device1.1/registers # 查看控制器寄存器部分驱动支持 cat /sys/kernel/debug/gpio # 查看GPIO使用情况确认你的片选GPIO状态是否正确6. 进阶思考片选与DMA、线程化传输的协同在更复杂的应用场景比如需要高带宽或低CPU占用的SPI传输中我们可能会启用DMA或使用spi_async进行线程化传输。这时片选的控制需要格外小心。DMA传输当使用DMA时数据传输由DMA控制器完成CPU干预更少。但片选信号的控制无论是硬件还是软件模式通常仍由SPI控制器核心逻辑或驱动中的完成回调函数来管理。需要确保DMA传输的启动和完成回调与片选信号的同步无误。在spi-imx驱动中DMA传输的设置和片选控制是集成好的一般无需额外处理。线程化传输spi_async当你通过spi_async提交一个消息时传输被放入队列在后台内核线程中执行。这意味着发起传输的代码不会等待传输完成。你必须确保在传输完成回调函数中才释放相关的资源如DMA缓冲区并且要理解片选信号会在那个后台线程的上下文中被置高。如果多个异步消息发给同一个设备SPI子系统会保证它们串行化片选信号也会正确切换。但如果同时发给不同设备驱动和控制器必须支持快速的片选切换。一个深坑提示如果你在中断上下文例如一个硬件中断服务程序中调用spi_sync而你的SPI驱动使用了线程化传输很多驱动默认如此那么spi_sync可能会睡眠等待这在中断上下文中是不允许的会导致内核错误。在这种情况下要么使用spi_async然后在中断下半部处理完成回调要么确保你的驱动配置为不使用线程化传输但这会影响性能。片选操作本身也可能涉及GPIO操作软件片选而GPIO操作在某些情况下也可能睡眠。因此在中断上下文中进行SPI通信需要非常谨慎的设计。通过这次对I.MX6ULL SPI驱动片选机制的彻底梳理我们可以看到Linux内核的驱动框架已经为我们处理了大部分复杂性。关键在于清晰地通过设备树表达硬件设计意图并理解驱动内部如何根据这些意图来分派不同的片选控制策略。混合使用硬件和软件片选时清晰的设备树配置和对pinctrl的准确把握是成功的关键。下次当你面对一个SPI设备无法通信时不妨先用逻辑分析仪看看片选信号有没有“动起来”这往往能最快地定位问题方向。
1. 项目概述从硬件片选到软件片选的驱动实践最近在调试一块基于I.MX6ULL的工控板板上挂载了多个SPI设备包括一个Flash和一个温湿度传感器。硬件工程师在设计时为了节省GPIO将Flash的片选CS直接接到了SPI控制器的硬件片选引脚上而传感器则使用了一个普通的GPIO进行控制。在编写Linux内核驱动时这个看似简单的差异却让我在spi-imx主机控制器驱动里折腾了大半天。最终问题核心落在了如何正确理解和配置SPI主机控制器驱动中的“软件片选”与“硬件片选”模式。这不仅仅是I.MX6ULL平台的特有问题而是所有嵌入式Linux开发者在进行多SPI设备驱动时都可能踩到的坑。今天我就把这个过程掰开揉碎了讲清楚特别是spi-imx.c这个驱动里关于片选处理的那些“潜规则”。简单来说硬件片选是指SPI控制器内部有专用的片选逻辑电路和物理引脚在发起传输时控制器会自动控制对应CS引脚的电平。而软件片选则是驱动程序通过操控一个普通的GPIO引脚在传输前后手动拉低和拉高来模拟片选信号。在Linux的SPI子系统框架下这两种模式的选择和配置很大程度上取决于设备树Device Tree的描述以及驱动程序的实现细节。对于I.MX6ULL其spi-imx驱动对这两种模式的支持已经相当完善但如果不理解其内在逻辑配置起来就很容易出错导致设备无法通信或者片选信号时序混乱。2. SPI片选机制深度解析硬件与软件的抉择要搞定驱动首先得从原理上明白为什么要有这两种片选方式以及它们各自的优劣。2.1 硬件片选控制器的“原生技能”硬件片选是SPI控制器的标准功能。以I.MX6ULL的eCSPI模块为例其控制器内部集成了片选状态机。当驱动通过spi_message提交一个传输请求时控制器硬件会在数据时钟SCLK产生之前自动将指定的片选线例如SS0、SS1拉低有效并在整个传输帧结束后自动将其拉高无效。这个过程是硬件自动完成的精确且高效不占用CPU资源。它的优点非常明显时序精准片选信号由硬件产生与数据时钟的同步性极佳能满足高速SPI设备如Flash的严苛时序要求。节省CPU完全由硬件自动处理CPU只需配置好传输参数即可。支持多从机控制器通常提供2-4个硬件片选引脚可以直接连接多个设备。但缺点也同样突出引脚固定硬件片选引脚是控制器专用的数量有限I.MX6ULL的每个SPI控制器通常有2-4个且无法映射到任意GPIO上。灵活性差一旦硬件设计定型哪个设备用哪个CS引脚就固定了软件难以动态调整。2.2 软件片选驱动程序的“灵活补丁”当硬件片选引脚不够用或者硬件设计使用了非专用的GPIO作为片选时就需要软件片选出马。此时驱动程序需要在设备树中将片选GPIO定义为cs-gpios属性。在驱动代码中在spi_transfer开始前通过GPIO子系统手动将对应的GPIO拉低。在传输结束后再手动将其拉高。软件片选的优点在于极致的灵活性突破引脚限制理论上可以使用任何可用的GPIO作为片选数量几乎不受限。便于硬件设计硬件工程师布线时更自由无需拘泥于控制器的固定CS引脚。但其代价也不小时序精度依赖软件片选信号拉低/拉高的时机由软件控制其精度受内核调度、中断延迟等因素影响不适合对时序要求极高的设备。增加CPU开销每次传输都需要额外的GPIO操作指令。实现更复杂需要驱动程序正确处理片选GPIO的申请、配置和时序控制。2.3 Linux SPI子系统框架下的抽象Linux内核的SPI子系统drivers/spi/spi.c为我们统一了接口。它定义了一个spi_device结构体来代表一个SPI从设备其中包含一个chip_select成员。这个成员的值在硬件片选模式下代表控制器硬件CS的索引号如0, 1, 2...在软件片选模式下它通常没有硬件意义但驱动程序会用它来索引cs-gpios数组中对应的GPIO描述符。关键点在于主控制器驱动如spi-imx需要根据设备树提供的信息自行判断并处理这两种模式。这个判断逻辑正是我们调试的核心。3. I.MX6ULL SPI驱动片选处理源码探秘我们以Linux内核以5.x版本为例中的drivers/spi/spi-imx.c驱动为例深入看看它是如何实现这一机制的。3.1 设备树一切配置的源头设备树的描述决定了驱动行为的起点。一个典型的包含混合片选模式的SPI节点示例如下ecspi1 { cs-gpios gpio4 9 GPIO_ACTIVE_LOW, gpio4 10 GPIO_ACTIVE_LOW; pinctrl-names default; pinctrl-0 pinctrl_ecspi1 pinctrl_ecspi1_cs; // pinctrl_ecspi1_cs 可能只包含硬件CS引脚 status okay; flash: spi-flash0 { compatible jedec,spi-nor; spi-max-frequency 40000000; reg 0; // 使用硬件CS0 }; sensor: temperature-sensor1 { compatible vendor,temp-sensor; spi-max-frequency 1000000; reg 1; // 理论上对应硬件CS1但这里我们想用软件片选 cs-gpios gpio4 10 GPIO_ACTIVE_LOW; // 关键子节点覆写指定使用GPIO4_10作为软件片选 }; };注意sensor节点里的cs-gpios属性。它在子节点中**覆写override**了SPI控制器节点中定义的cs-gpios数组。同时它的reg 1这个“1”在硬件片选语境下是CS1索引但在软件片选模式下其含义由驱动解释。3.2 驱动中的关键逻辑spi_imx-chipselect函数在spi-imx.c中片选控制的核心是一个函数指针spi_imx-chipselect。驱动在初始化时会根据配置为其赋予不同的函数。情况一使用硬件片选当设备使用硬件片选即设备树中未为该设备指定cs-gpios或指定的GPIO无效驱动会调用spi_imx_chipselect函数。这个函数直接操作控制器的寄存器控制硬件CS引脚的电平。static void spi_imx_chipselect(struct spi_device *spi, int is_active) { struct spi_imx_data *spi_imx spi_master_get_devdata(spi-master); int cs spi-chip_select; // 获取设备注册时的片选号 u32 ctrl_reg; ctrl_reg readl(spi_imx-base MX51_ECSPI_CTRL); if (is_active) { // 激活设备片选拉低 ctrl_reg | 1 (cs MX51_ECSPI_CTRL_CS_SHIFT); } else { // 取消激活片选拉高 ctrl_reg ~(1 (cs MX51_ECSPI_CTRL_CS_SHIFT)); } writel(ctrl_reg, spi_imx-base MX51_ECSPI_CTRL); }情况二使用软件片选当驱动通过of_get_gpio等函数成功从设备树中获取到该设备有效的cs-gpios时spi_imx-chipselect会被赋值为spi_imx_gpio_chipselect函数。static void spi_imx_gpio_chipselect(struct spi_device *spi, int is_active) { struct spi_imx_data *spi_imx spi_master_get_devdata(spi-master); int gpio spi_imx-chipselect[spi-chip_select]; // 通过chip_select索引获取GPIO号 gpio_set_value(gpio, is_active ? spi-mode SPI_CS_HIGH ? 1 : 0 : spi-mode SPI_CS_HIGH ? 0 : 1); }这个函数直接操作GPIO值。注意这里的spi-chip_select值来自设备树的reg属性被用作索引去spi_imx-chipselect[]数组中查找对应的GPIO号。这意味着在软件片选模式下reg属性的值主要是一个用于查找GPIO的“句柄”而不再直接对应控制器的硬件CS索引。3.3 初始化流程模式判断的十字路口驱动在spi_imx_setup()函数中为每个spi_device进行设置。其中关于片选的关键逻辑简化如下获取GPIO尝试从设备树节点中获取cs-gpios属性。判断模式如果成功获取到有效的GPIO描述符则将该GPIO配置为输出并存入spi_imx-chipselect[]数组同时将spi_imx-chipselect函数指针指向spi_imx_gpio_chipselect。如果获取失败返回负数则判定为使用硬件片选。此时会检查spi-chip_select是否超出了控制器硬件支持的最大CS数如果超出则报错。然后spi_imx-chipselect函数指针指向spi_imx_chipselect。关键避坑点这里有一个极易混淆的地方。假设控制器有2个硬件CSCS0 CS1。设备A使用硬件CS0reg 0。设备B想使用软件片选连接在GPIO4_10上。如果你在设备B的节点里写reg 2心想硬件CS只有0和12肯定就是软件片选了驱动在初始化B时会先尝试获取cs-gpios。如果获取成功没问题reg2会被当作软件片选数组的索引。但是如果获取失败比如GPIO号写错了或者pinctrl冲突驱动会回退到硬件片选模式然后检查reg2是否大于等于最大硬件CS数本例中是2因为2 2驱动可能会报错chipselect 2 out of range。所以即使打算用软件片选reg的值也最好在硬件CS数量范围内分配以避免回退时的错误。更稳妥的做法是确保cs-gpios属性正确无误。4. 实战配置与调试记录理解了原理我们回到最初的项目。我的设备树配置最终版本如下ecspi1 { cs-gpios gpio4 9 GPIO_ACTIVE_LOW; // 只定义了一个给硬件CS1备用不这里有个坑 pinctrl-names default; pinctrl-0 pinctrl_ecspi1; // 这个pinctrl只包含SCLK, MOSI, MISO不包含任何CS引脚 status okay; flash0 { compatible winbond,w25q128, jedec,spi-nor; spi-max-frequency 40000000; reg 0; // 没有cs-gpios使用硬件CS0。硬件CS0的引脚由pinctrl子系统单独控制例如pinctrl_ecspi1_cs0 }; sensor1 { compatible ti,tmp112; spi-max-frequency 1000000; reg 1; // 注意这里是1 cs-gpios gpio4 10 GPIO_ACTIVE_LOW; }; };同时在Pinctrl节点中我需要确保硬件CS0引脚例如ECSPI1_SS0被正确配置为SPI功能。用于软件片选的GPIO4_10被配置为GPIO输出功能并且初始状态为高电平无效。pinctrl_ecspi1: ecspi1grp { fsl,pins MX6ULL_PAD_UART4_TX_DATA__ECSPI1_SCLK 0x100b1 MX6ULL_PAD_UART4_RX_DATA__ECSPI1_MOSI 0x100b1 MX6ULL_PAD_UART3_TX_DATA__ECSPI1_MISO 0x100b1 ; }; pinctrl_ecspi1_cs0: ecspi1cs0grp { fsl,pins MX6ULL_PAD_UART3_RX_DATA__ECSPI1_SS0 0x100b1 // 硬件CS0 ; }; pinctrl_sensor_cs: sensorcsgrp { fsl,pins MX6ULL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x000b0 // 另一个GPIO示例初始状态为高 ; };重要心得控制器节点下的cs-gpios属性是一个“默认”列表。如果子设备节点没有自己的cs-gpios驱动会尝试使用这个列表中对应reg索引的GPIO。如果子设备节点明确指定了自己的cs-gpios则会覆盖默认值。但是一个常见的陷阱是如果你在控制器节点定义了cs-gpios即使子设备想用硬件片选驱动也可能优先尝试使用这个GPIO列表。最清晰的做法是计划使用软件片选的设备在其节点内显式定义cs-gpios计划使用硬件片选的设备其节点内不要定义cs-gpios并确保对应的硬件CS引脚被正确的pinctrl组配置。控制器节点的cs-gpios可以留空或不定义以避免干扰。5. 调试技巧与常见问题排查在实际驱动加载和设备通信测试中你可能会遇到以下问题5.1 问题一设备无响应片选信号无变化排查思路检查引脚复用使用cat /sys/kernel/debug/pinctrl/pinctrl-handles或devmem命令直接查看IOMUXC寄存器确认SCLK、MOSI、MISO以及CS引脚是否被正确复用到SPI功能或GPIO功能。这是最常见的问题根源。检查片选电平极性确认GPIO_ACTIVE_LOW或GPIO_ACTIVE_HIGH设置是否正确。用示波器或逻辑分析仪测量片选引脚观察在传输发生时电平是否跳变。如果应该是低电平有效却一直为高那设备自然不会响应。检查驱动加载dmesg | grep spi查看驱动加载日志是否有关于片选GPIO申请失败、索引超出范围等错误信息。使用逻辑分析仪这是最强大的工具。连接SCLK、MOSI、MISO和CS线发起一次SPI读取操作例如cat /sys/class/spi_master/spi1/spi1.1/device/xxx。观察CS信号是否在数据帧前后有效数据线上是否有波形。如果CS没动作说明片选控制逻辑未生效如果CS有动作但数据线没波形可能是传输本身没发起或者速率、模式不对。5.2 问题二多个设备互相干扰片选时序混乱排查思路确认片选独立性确保每个设备都有独立的片选线无论是硬件还是软件GPIO并且它们在物理上和配置上都不会同时有效。检查驱动中的chipselect函数在spi-imx.c的spi_imx_chipselect或spi_imx_gpio_chipselect函数中添加printk打印每个设备的片选操作日志确认在传输每个设备时正确的片选函数被调用。检查spi_message队列Linux SPI子系统支持将多个spi_transfer组织成一个spi_message并且可以设置spi_message-cs_change标志。如果cs_change为1表示在这次传输和下一次传输之间需要改变片选状态。确保你的多设备传输消息正确设置了这个标志。对于完全独立的两个设备传输更安全的做法是提交两个独立的spi_message。5.3 问题三软件片选设备通信不稳定偶发失败排查思路测量时序用逻辑分析仪重点测量软件片选GPIO的下降沿到第一个SCLK上升沿的延迟t_CS-SCK以及最后一个SCLK到CS上升沿的延迟t_SCK-CS。与设备数据手册要求对比。软件片选延迟较大可能在高速通信时不符合要求。内核配置与调度检查内核是否配置了CONFIG_PREEMPT可抢占式内核高系统负载下软件操作GPIO的延迟可能波动。对于低速传感器这可能没问题但对高速Flash就是灾难。考虑使用硬件片选或者降低SPI通信频率。GPIO驱动能力如果片选线上挂载的负载较重例如多个设备并联GPIO输出电流可能不足导致边沿变缓。在驱动代码中可以尝试在GPIO申请后调用gpio_set_direction()和gpio_set_value()之前通过Pinctrl子系统将该GPIO的驱动强度drive-strength配置为更高值。5.4 调试信息获取在内核配置中打开CONFIG_DEBUG_FS和SPI相关的调试选项可以挂载debugfs后查看更多信息cat /sys/kernel/debug/spi/spi1/device1.1/registers # 查看控制器寄存器部分驱动支持 cat /sys/kernel/debug/gpio # 查看GPIO使用情况确认你的片选GPIO状态是否正确6. 进阶思考片选与DMA、线程化传输的协同在更复杂的应用场景比如需要高带宽或低CPU占用的SPI传输中我们可能会启用DMA或使用spi_async进行线程化传输。这时片选的控制需要格外小心。DMA传输当使用DMA时数据传输由DMA控制器完成CPU干预更少。但片选信号的控制无论是硬件还是软件模式通常仍由SPI控制器核心逻辑或驱动中的完成回调函数来管理。需要确保DMA传输的启动和完成回调与片选信号的同步无误。在spi-imx驱动中DMA传输的设置和片选控制是集成好的一般无需额外处理。线程化传输spi_async当你通过spi_async提交一个消息时传输被放入队列在后台内核线程中执行。这意味着发起传输的代码不会等待传输完成。你必须确保在传输完成回调函数中才释放相关的资源如DMA缓冲区并且要理解片选信号会在那个后台线程的上下文中被置高。如果多个异步消息发给同一个设备SPI子系统会保证它们串行化片选信号也会正确切换。但如果同时发给不同设备驱动和控制器必须支持快速的片选切换。一个深坑提示如果你在中断上下文例如一个硬件中断服务程序中调用spi_sync而你的SPI驱动使用了线程化传输很多驱动默认如此那么spi_sync可能会睡眠等待这在中断上下文中是不允许的会导致内核错误。在这种情况下要么使用spi_async然后在中断下半部处理完成回调要么确保你的驱动配置为不使用线程化传输但这会影响性能。片选操作本身也可能涉及GPIO操作软件片选而GPIO操作在某些情况下也可能睡眠。因此在中断上下文中进行SPI通信需要非常谨慎的设计。通过这次对I.MX6ULL SPI驱动片选机制的彻底梳理我们可以看到Linux内核的驱动框架已经为我们处理了大部分复杂性。关键在于清晰地通过设备树表达硬件设计意图并理解驱动内部如何根据这些意图来分派不同的片选控制策略。混合使用硬件和软件片选时清晰的设备树配置和对pinctrl的准确把握是成功的关键。下次当你面对一个SPI设备无法通信时不妨先用逻辑分析仪看看片选信号有没有“动起来”这往往能最快地定位问题方向。
)
