如何扩展Beaglebone SPI1驱动以支持6个片选(CS)

• 前4个CS可用、最后2个CS通信超时的现象，核心原因是4.14.108-ti内核对应的spi-omap2-mcspi驱动存在硬编码的CS数量上限：AM335x的MCSPI控制器硬件原生仅支持4个独立片选通道，驱动默认直接采用硬件寄存器读出的通道数作为最大支持的CS数量，不会解析cs-gpios数组中超过硬件通道数的条目。
• 当前配置的cs-gpios列表中，索引0、1的两个<0>对应原生硬件CS0、CS1，索引2、3的两个GPIO模拟CS刚好填满驱动支持的4个CS上限，因此索引4、5对应的两个GPIO（gpio1_16、gpio1_17）的配置完全没有被驱动加载，传输时找不到对应的片选控制逻辑，最终触发dmesg上报的SPI超时错误。

方案1：修改spi-omap2-mcspi驱动适配更多GPIO CS #

如果需要保留全局cs-gpios的配置方式，需要对驱动做3处关键修改：

1. 调整CS数量的判断逻辑
   原驱动在probe流程中，会读取MCSPI控制器的通道数寄存器值（AM335x对应值为4），直接将该值作为支持的最大CS数。需要修改逻辑：在设备树解析完cs-gpios所有条目后，将实际解析到的CS总数量替换为驱动的最大支持上限，不要以硬件寄存器读出的4作为判断边界。
2. 修正动态内存分配的大小
   原驱动会按照硬件通道数（4）为每个通道的运行状态结构体分配数组空间，需要将数组分配长度调整为实际解析到的CS总数量，避免数组访问越界。
3. 适配GPIO片选的控制路径
   原驱动的片选控制逻辑会按照CS索引匹配硬件片选寄存器操作，需要增加判断逻辑：当CS索引小于硬件原生通道数时，走原有的硬件片选控制流程；当CS索引大于等于原生通道数时，跳过硬件寄存器操作，直接调用SPI核心层提供的通用GPIO片选拉高/拉低接口完成片选控制。这类GPIO模拟的片选不需要分配独立的硬件DMA通道，所有CS对应的SPI时钟、MOSI、MISO引脚可以复用公共总线引脚，仅需要独立控制对应GPIO即可。

方案2：使用原生GPIO片选能力实现（无代码修改，稳定性更高） #

不需要改动任何驱动代码，仅通过设备树配置即可实现6个CS的支持，更适合长期维护：

• 取消原全局cs-gpios数组中多余的GPIO条目，仅保留原生硬件CS对应的配置即可。
• 为每一个挂载在SPI1总线上的mcp4921设备单独建立子节点，通过节点的spi-cs-gpios属性指定自身的独立片选引脚，绕开MCSPI驱动的全局CS数量限制。
• 参考设备树配置示例：

&spi1 {
    status = "okay";
    /* 仅保留原生硬件CS的占位配置 */
    cs-gpios = <0>, <0>;

    /* GPIO3_19作为片选的mcp4921 */
    dac@0 {
        compatible = "mcp4922,mcp4921";
        reg = <0>;
        spi-max-frequency = <10000000>;
        spi-cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
    };
    /* GPIO1_18作为片选的mcp4921 */
    dac@1 {
        compatible = "mcp4922,mcp4921";
        reg = <1>;
        spi-max-frequency = <10000000>;
        spi-cs-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
    };
    /* 剩余GPIO1_16、GPIO1_17以及2个原生CS对应的设备，按照相同格式依次添加子节点即可 */
};

• 该方案完全复用4.14内核SPI核心层原生的GPIO片选控制逻辑，不存在驱动硬编码上限的问题，不需要维护定制化的内核代码，稳定性远高于修改驱动的方案。

• 片选电平匹配：mcp4921原生片选为低电平有效，需确认实际接线的电平配置和设备树中GPIO_ACTIVE_HIGH/GPIO_ACTIVE_LOW的定义匹配，否则会出现通信失败。
• SPI时钟上限：mcp4921最高支持10MHz的SPI总线时钟，配置时不要超过该频率，避免出现通信误码。
• 4.14.108-ti内核的SPI核心已经完整支持单节点独立配置spi-cs-gpios的能力，不需要额外打补丁即可正常使用。

内容的提问来源于stack exchange，提问作者Avadhana Technologies