简介面向MTK6735平台的ST7789 RGB液晶屏SPI驱动示例为嵌入式开发者解决了通过SPI接口初始化、控制并刷新LCD显示控制器的关键问题。整个压缩包仅5KB内含1个C源文件却覆盖从底层总线配置到上层显示控制的完整链路代码紧凑便于直接阅读和移植到类似项目。实现中重点涉及SPI时钟频率、数据模式与极性的匹配命令/数据双模式发送ST7789分辨率、像素格式及显示方向设置帧缓冲区的分配与管理背光和电源时序控制以及清屏、绘制、滚动等显示更新操作此外还包含SPI传输异常检测与恢复机制。对于需要快速掌握MTK6735平台LCD驱动开发、或者参考SPI接口驱动彩色屏的工程师这份示例能减少资料查阅量适合对照数据手册逐段分析学习。目前已有787人学习浏览可用作实际项目起步阶段的样板代码。1. 这个 MTK6735 包里同时出现 LCD RGB 和 SPI先认清楚各自管哪一段打开 MTK6735.zip 之后看到MT6735 LCD rgb、MTK6735 SPI、mtk6735_s这些目录名第一反应是找 lcm 驱动源码。但更常见的实际情况是一块 5 寸 480x854 的 RGB 并口屏在工控、车载导航、数据采集终端上会同时用到 MTK6735 的两条路径。MTK6735 这一代 SoC 只把 MIPI DSI 作为真正的主显示输出LCD RGB 接口通常是桥接芯片之后的并口或者板级转接出来的 40pin FPC而 SPI 那一路多数时候承担的是同块屏的上电初始化、寄存器配置甚至有少数项目直接用 SPI 做副屏。搞清楚这个包里的文件到底在描述哪条链路比打开代码立刻找lcm_drv结构体更重要否则很容易在 DSI 和 SPI 两个方向上都瞎调半天。这篇按 MTK6735 的实际 BSP 习惯把 RGB 和 SPI 的接线、dts、驱动写法、验证手段拆开讲。2. MTK6735 的显示链路RGB 并口与 SPI 分别管什么2.1 别把 LCD RGB 当成 MTK6735 的主显示通道MTK6735 的显示输出主链路是 DSISoC 内部的 DISP 模块最终会把像素数据打给 MIPI DPHY再送到 DSI 面板。这个链路对 720p 以内的屏幕非常成熟驱动里通常表现为一个lcm设备compatible 字符串对应具体面板型号lcm-params里填lane_num、h_back_porch、v_front_porch这些时序参数。RGB 并口在 MTK 平台上是另一套逻辑。它不走 DSI 协议而是像老式 MCU 屏那样用 PCLK、HSYNC、VSYNC、DE 加 16/18/24 根数据线把像素一个点一个点地送进面板的 Source Driver。很多项目里的做法是MTK6735 输出 DSI板上再接一颗 DSI-to-RGB bridge 芯片桥出来一组 40pin 的 LCD RGB FPC 接口。也有一部分 LCM 模组本身就只有 RGB 接口没有自带 DSI 控制器那就必须在板上完成转换。所以看到一个叫MT6735 LCD rgb的目录不要默认它可以直接接到 SoC 的某个 RGB 控制器上。MT6735 原生并没有开放出去的并行 RGB 主显示控制器真正驱动这组 40pin 信号的是那颗 bridge 芯片的驱动。BSP 里的工作通常分成两块bridge 芯片的初始化以及 bridge 输出侧 RGB 时序的配置。40pin 接口里除了数据线还要重点看 PCLK 极性、DE 模式、VCOM 输出、LEDA 背光这些在模组规格书里都有明确要求。2.2 RGB 并口屏常常自带一条 SPI 命令通道这是这个标题最容易被忽略的点。一块 RGB 接口的 TFT 模组面板内部的 TCON 和 Gamma 寄存器不会平白无故处于正确状态。要让并口亮度、对比度、扫描方向符合预期要先往面板控制芯片里写入一段初始化序列然后再把像素数据从并口打进去。这段初始化序列的物理通道最常见的就是四线 SPISCLK、MOSI、CS、DC。也就是说同一个 zip 包里有LCD rgb又有SPI lcd不代表一定有两块屏。很可能是同一块模组的两条通路SPI 只负责慢速配置RGB 并口负责高速像素搬运。这种设计在 ST7789V、ILI9341 这类自带 GRAM 的屏上非常常见RGB 接口模式下数据照常从并口进入SPI 还可以继续用来读回面板 ID、改显示方向、做睡眠唤醒。写驱动的时候要把这条界限分清楚。panel_prepare阶段发的是 SPI 命令panel_enable之后并口才开始持续送像素。很多新人在 drive 里直接把 SPI 初始化序列放在probe就完事结果背光一亮屏幕全是雪花就是忽略了 RGB 并口侧 PCLK 和 DE 还没有建立。enum panel_bus_type { BUS_DSI, BUS_RGB, BUS_SPI }; static int panel_prepare(struct panel_device *panel) { switch (panel-bus) { case BUS_RGB: /* RGB 并口屏先通过 SPI 命令通道做显示配置 */ spi_write_cmd(panel-spi_dev, 0x11); /* Sleep Out */ msleep(120); spi_write_cmd(panel-spi_dev, 0x29); /* Display On */ break; case BUS_SPI: /* 纯 SPI 屏命令和数据都走同一根 MOSI */ spi_write_then_read(panel-spi_dev, panel-init_seq, panel-init_len, NULL, 0); break; default: return -EINVAL; } return 0; }SPI 时序里最要紧的不是速度而是 DC 电平切换。命令阶段 DC 拉低数据阶段 DC 拉高这个电平变化要在 SCLK 有效沿之前稳定下来。RGB 并口屏的初始化序列一般在几十个字节以内SPI 跑 10MHz 甚至 1MHz 都够用真正限制帧率的是后面的并口 PCLK不是这段 SPI。2.3 纯 SPI 屏在 MTK6735 上通常做副屏或状态屏除了给 RGB 并口屏做初始化通道SPI 在 MTK6735 上还有另一种用法直接挂一块小尺寸 SPI LCD 当副屏。常见尺寸是 1.3 寸 240x240、2.0 寸 320x240 这类分辨率驱动 IC 多为 ST7789V、GC9307、ILI9341 等。分辨率小刷新率要求不高带宽压力小非常适合用 SPI 主控持续刷新。但不要试图让这种纯 SPI 屏当 MTK6735 的唯一主显示。SPI 即使跑到 48MHz一个字节 8bit一帧 240x240x16bit 的数据量就是 115200 字节理想状态下 48MHz 传输一帧也要接近 20ms加上命令间隙、片选切换、刷新率很难做到 60fps。做状态显示、低刷新率菜单、调试信息输出是可以的做主屏交互会明显感觉拖影和撕裂。同样要注意SPI 协议和 I2C、UART 的最大区别是没有总线仲裁所有传输都由主机用 CS 拉低来声明占用。I2C 有地址和 ACKUART 有起止位而 SPI 从机只要 CS 拉低就会一直响应 SCLK。所以驱动里片选处理错了影响的不只是这一块屏挂在同一 SPI 总线上的其他设备也会被误触发。这也是 MTK BSP 里对 SPI 屏最敏感的地方。2.4 MIPI DSI、LCD RGB、SPI 三者的选型边界接口类型典型信号线数据带宽典型分辨率MTK6735 上的接入方式移植重点MIPI DSI1~4 对差分时钟/数据高1Gbps 级480x854 到 1080PSoC 原生 LCD 控制器直出DSI 时序、lane 数、LP/HS 切换LCD RGB16/18/24bit 数据线加 PCLK/HSYNC/VSYNC/DE中30MHz~80MHz PCLK480x272 到 720x1280通过 DSI-to-RGB bridge 转接像素时钟、极性、DE 模式、上电顺序SPI LCDSCLK/MOSI/CS可选 DC低几 Mbps 到几十 Mbps240x320 以下挂 SPI 主控或 GPIO 模拟时序模式、片选、刷新带宽选型结论很直接MTK6735 这个平台凡是消费类主屏优先走 DSI凡是 40pin 工控屏先确认 bridge 方案凡是只做状态指示的小屏才把精力花在 SPI 上。反之如果标题里同时出现 rgb 和 spi第一优先怀疑是同一块屏的混合接口而不是两套独立设备。3. 从 zip 素材到可编译 LCD 驱动解包、认目录、改 dts3.1 先解包确认拿到的是内核补丁还是完整工程拿到 MTK6735.zip 后我习惯先建一个干净目录再解压避免压缩包内的相对路径把自己当前工程冲掉。老平台 BSP 的 zip 一般不会只有一个顶层目录而是kernel-3.18/、vendor/mediatek/、device/混在一起甚至还有custom/、alps/这类 MTK 老工程习惯。mkdir -p mt6735_lcd cd mt6735_lcd unzip ../MTK6735.zip -d . # 看顶层有哪些目录确认内核版本和 BSP 结构 find . -maxdepth 2 -type d | sort | head -40 # 直接找 lcm 驱动源码估计 LCM 目录位于 kernel 或 mediatek 目录下 find . -path *kernel* -iname *lcm* -print 2/dev/null | head -40 # 找 dts 或 dtsi 文件确认设备树路径 find . -name *.dts -o -name *.dtsi | head -30解压后第一件事不是读代码而是先看有没有README或patch文件以及git log之类的版本信息。zip 包名里的mtk6735_s这个后缀通常只是方案商或者板厂的批次标记不代表具体功能。如果发现多个 lcm 驱动同时存在比如lcm_st7789v.c、lcm_ili9341.c需要用strings或者直接打开文件头注释来确认哪一个是针对当前项目改过的。no frames received这类现象如果在验证阶段出现大概率不是 dts 没写对而是 bridge 芯片根本没有输出时序或者 SPI 初始化序列没把面板拉出睡眠。所以解包后的第一步依赖关系是SPI 能初始化 → 并口有 PCLK → 面板才可能出画。3.2 把 lcm 驱动放回 MTK 的 LCM 框架MTK6735 那个年代的内核LCD 驱动不是标准 Linux DRM/KMS 架构而是 MTK 私有的lcm_drv框架。驱动文件通常放在kernel-3.18/drivers/misc/mediatek/lcm/之类路径通过一个lcm_drv结构体向mtkfb注册结构体里填写get_params、init、suspend、resume等回调函数。如果 zip 里的驱动直接是.c文件需要确认它有没有被对应的Makefile编进去。老 BSP 的 LCM 框架有两种编译方式一是直接塞进Makefile的obj-y二是通过lcm_id或者cust_lcm列表注册。建议先在已有工程里找一个结构类似的 lcm 驱动做模板然后用diff对比能少踩很多坑。static struct lcm_drv mt6735_spi_lcm_drv { .name mt6735_spi_lcd, .get_params mt6735_spi_get_params, .init mt6735_spi_init, .suspend mt6735_spi_suspend, .resume mt6735_spi_resume, .get_pixel_format mt6735_spi_get_pixel_format, };这个结构体里最关键的字段是name。name必须与 dts 里 panel 节点的 compatible 字符串能对应上或者被平台代码里的lcm_name表显式引用。很多移植失败的案例驱动文件编译进去了函数也没问题但 dts 里 compatible 和驱动name对不上导致驱动根本没有 probe。老 MTK 平台的lcm_drv不一定走标准of_match_table所以字符串匹配非常容易被忽略。3.3 在 dts 里声明 SPI LCD 或 RGB bridge 的设备节点MTK6735 的内核设备树SPI 节点通常长这样。明确一点如果你用的是软件片选一定要把片选脚配置成 GPIO 功能并且通过cs-gpios声明给 SPI 控制器的spicore 来管理。spi1 { pinctrl-names default; pinctrl-0 spi1_pins; cs-gpios pio 26 0; /* 软件片选由内核 spi core 统一拉放 */ status okay; spi_lcd: spi-lcd0 { compatible mt6735,spi-lcd; reg 0; /* 对应 cs-gpios 索引多设备时别写重 */ spi-max-frequency 12000000; /* spi-cpha; */ /* 老内核用 spi-mode 0 也行二选一 */ reset-gpio pio 24 0; dc-gpio pio 25 0; /* 数据/命令切换引脚 */ }; };这里spi-max-frequency不要一上来就拉满。很多 SPI 屏的规格书标称 30MHz但面板 FPC 走线长或者电平转换芯片质量一般实际跑到 12MHz 以上就出错。调试阶段先设 1MHz能出图再加频率这种方式定位问题最快。spi-mode在老内核里是数字属性0 到 3 直接对应 CPOL/CPHA 组合新内核改成spi-cpol、spi-cpha两个布尔属性。同一份 zip 里如果同时出现两种写法说明打包的人自己都合并过不同内核版本移植时要以当前工程的 bindings 文档为准。RGB 接口屏如果走 DSI-to-RGB bridgedts 里通常不是直接写spi1而是给 bridge 芯片建一个 I2C 或者 SPI 节点再把 bridge 的输出参数写到lcm节点里。bridge 和 panel 是两级设备不要混在一个节点里描述。3.4 驱动里 SPI 发送的最小完整路径MTK 平台 SPI 屏驱动最常转发的一个函数是spi_write。要写对不只是调用spi_write还要把spi_device的mode、bits_per_word、max_speed_hz设置好。否则spi_setup会返回错误或者时序完全不对。static int lcd_spi_write(struct spi_device *spi, const u8 *buf, size_t len) { struct spi_transfer xfer { .tx_buf buf, .len len, .speed_hz 12 * 1000 * 1000, }; struct spi_message msg; spi_message_init(msg); spi_message_add_tail(xfer, msg); return spi_sync(spi, msg); }spi_sync会阻塞当前进程直到传输完成适合在probe、resume里发送初始化序列。这里speed_hz只对这一次传输生效不会覆盖spi_device全局配置。如果接收方向也需要数据例如读面板 ID就要给xfer.rx_buf分配同等长度的缓冲区SPI 是全双工协议主机发出一个字节的同时一定会收进一个字节。MTK6735 的老内核 SPI 控制器发送缓冲区最好确保是 DMA 能访问的内存。kmalloc出来的地址一般没问题但如果用了栈上的局部数组某些 DMA 配置下会报 cache coherency 错误。初始化序列这种短数据量直接放在驱动里用static const数组最省事也方便后续对比寄存器改动。4. SPI 屏最容易翻车的四个点时序、片选、DMA、上电顺序4.1 先核对 SPI 时序模式再谈改初始化序列SPI 屏调试中mode配错是排第一的隐蔽问题。mode 0 和 mode 3 的 CPOL、CPHA 组合不同但很多屏的数据手册会写“supports mode 0 and mode 3”这就给移植留了坑同一块屏在 mode 0 下能显示但颜色错乱、第一个像素偏移换到 mode 3 后反而正常。原因不在屏而在桥接芯片或者面板内部逻辑对采样沿的要求。SPI ModeCPOLCPHA数据采样常见用途Mode 000上升沿采样最常用大多数 SPI LCD 默认Mode 101下降沿采样少见于 LCD用于部分传感器Mode 210下降沿采样不常见Mode 311上升沿采样与 mode 0 等效采样沿常见判断方法很简单用一个逻辑分析仪抓 SCLK 和 MOSI看 MOSI 数据在 SCLK 上升沿还是下降沿稳定。不要只看驱动里写的 mode 数字要以抓到的波形为准。MTK 老平台还有一个问题就是 pinctrl 里的 SPI CLK 引脚 drive strength 设置太低导致 SCLK 边沿变缓高速时数据采样错位。这种问题改 mode 永远解决不了要去调pinctrl的drive-strength。4.2 软件片选不是自己拉 GPIO是交给 spi core 管理linux spi 软件拉片选这个操作常见误解是在驱动里自己gpiod_set_value(cs, 0)拉低然后spi_write最后再gpiod_set_value(cs, 1)。这种做法在单设备、低速率下也许能跑但在 DMA 模式下极容易翻车。因为spi_sync内部的spi_transfer_one_message会在传输前做片选管理、在传输完成后延迟释放如果外面已经手动拉低core 再操作同一个 GPIO会造成片选电平竞争甚至 CS 在传输中间被拉高从机直接丢帧。正确做法是在 dts 里把cs-gpios配置好驱动里不要手动操作片选。多设备共用一条 SPI 总线时reg属性要写不同的索引内核 spi core 会按照cs-gpios数组自动选择哪个 GPIO 被拉低。如果确实需要特别长的片选保持时间比如某些面板要求 CS 低电平期间连续写入很多字节且中间不能有毛刺那是 SPI 控制器和时钟的问题不是靠手动拉 CS 能解决的。更好的路径是检查spi_transfer的cs_change字段在spi_message里把多个 transfer 合并成一次片选周期。4.3 不要迷信两个 DMA先看是写多还是读写都有spi 需要两个 dma 吗这个问题在 MTK6735 上要分场景。SPI 是双工协议物理上同时存在输入和输出方向所以 DMA 控制器为 TX 和 RX 各分配一个通道是很常见的。但纯写屏的应用比如往 ST7789V 的 GRAM 灌颜色数据接收方向的数据完全没用这种场景只需要拿到 TX 通道RX 通道甚至可以不 DMA或者 DMA 到一块丢弃缓冲区。# 查看 SPI 控制器使用的 DMA 通道dmesg 里通常会有 dmesg | grep -i spi | grep -i dmaMTK 老内核的 SPI DMA 配置分散在 dts 的dmas属性和平台驱动里。如果发现录数据时画面撕裂、出现随机条纹优先检查 DMA 的 burst size 和 address alignment而不是怀疑屏的初始化序列。RGB 并口屏的像素写操作一般从memcpy到fb再走并口DMA 问题主要出现在大量连续 SPI 写 GRAM 的场景。对调试阶段最友好的办法是先禁用 SPI DMA强制用 PIO 模式把屏点亮验证时序和初始化正确后再重新打开 DMA 优化速度。MTK 平台上禁用 DMA 通常只需在 dts 中移除dmas属性或者在平台驱动里把use_dma标志置 0。这种方式能用最短路劲把“时序问题”和“DMA 问题”分开。4.4 上电顺序错误SPI 命令写了也白写RGB 并口屏和纯 SPI 屏都严格要求上电顺序。常见顺序是VCI 电源先上然后 IO 口电源 VDDI等电源稳定后拉高 RESET释放复位后再延时至少 10ms然后才能发第一条 SPI 命令。如果把背光先打开屏幕上电瞬间会先出现一块白屏然后 SPI 写入初始化序列后才能恢复正常。# 用 GPIO 控制的简化上电流程具体引脚号和次序以屏规格书为准 echo 1 /sys/class/gpio/gpio20/value # VCI enable sleep 0.02 echo 0 /sys/class/gpio/gpio24/value # RESET low sleep 0.01 echo 1 /sys/class/gpio/gpio24/value # RESET high sleep 0.12 # 等待内部 DCDC 稳定 echo 1 /sys/class/gpio/gpio21/value # 背光 enable上电顺序项目里最常犯的错误是把 RESET 和背光绑定在一起。RESET 拉低时间太短面板内部寄存器没复位干净后续 SPI 写入的命令会被部分忽略。典型表现是初始化序列执行完后屏能亮但颜色不对、行列方向错乱而且反复重试都不恢复必须断电重来。屏的 PCLK 也要注意。RGB 并口模式下PCLK 极性、DE 模式、HSYNC/VSYNC 是否取反都要和面板规格书对齐。PCLK 极性反了图像不会消失而是整体偏色、闪烁、或出现水平方向的错位。这类问题在 dts 的lcm参数里改不要到 SPI 驱动里找。5. 验证 MTK6735 SPI/RGB 屏彩条、读 ID 和方向表5.1 用 mmap 直接刷帧确认并口数据通路SPI 初始化成功不等于整个显示链路正常。RGB 屏点亮后最快验证方式是直接向/dev/fb0填充颜色数据。不要用dd写 framebuffer很多 MTK 老内核的 fb 设备只支持 mmap 映射用write系统调用会返回 EINVAL。用一段简单 C 代码 mmap 后 memset 最可靠。#include stdio.h #include fcntl.h #include sys/mman.h #include unistd.h #include string.h int main(void) { int fd open(/dev/fb0, O_RDWR); unsigned char *fb; int screensize 480 * 800 * 3; /* RGB888按实际 framebuffer 格式调整 */ fb mmap(NULL, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (fb MAP_FAILED) { perror(mmap); return 1; } memset(fb, 0xff, screensize); /* 全白验证数据线空闲电平 */ sleep(2); memset(fb, 0x00, screensize); /* 全黑验证像素时钟有效 */ munmap(fb, screensize); close(fd); return 0; }全白之后看到满屏白色并且不闪烁说明并口数据线、PCLK、DE 基本正常。再看全黑是否纯黑如果黑色中带竖条纹往往是 RGB 数据线有虚焊或者 bridge 输出位数没对上。刷不同颜色的顺序建议是全白、全黑、纯红、纯绿、纯蓝。纯色不对优先检查数据位映射因为 RGB 接口 18bit 和 24bit 模式下低两位的接法经常不一致。5.2 用 SPI 读回面板 ID验证命令通道SPI 命令通道能不能读是判断驱动是否真正掌控面板的最好方法。多数 SPI 屏支持0x04读回面板 ID或使用厂商自定义读命令。用户态 spidev 工具在 DC 引脚不容易控制的情况下我一般直接在驱动初始化函数里加一段临时读逻辑u8 cmd 0x04; u8 rx[4] {0}; /* DC 拉低发送命令再拉高读取数据 */ gpiod_set_value(dc_gpio, 0); lcd_spi_write_read(spi, cmd, 1, rx, 4); gpiod_set_value(dc_gpio, 1); pr_info(lcd id: %02x %02x %02x %02x\n, rx[0], rx[1], rx[2], rx[3]);读到的 ID 如果全是 0x00 或者 0xff优先怀疑 CS 时序和 DC 切换不要怀疑屏坏。很多 SPI 屏读 ID 需要先把面板从 sleep 状态唤醒或者在读命令之前先发特定的 unlock 命令这就回头检查第一段初始化序列是否完整。5.3 行列方向和偏移写在方向寄存器里最后一块常见问题是图像方向不对。RGB 屏和 SPI 屏大都通过0x36面板方向寄存器控制行列扫描。以常见驱动 IC 为例0x36的 bit7 是 MYbit6 是 MX两者组合对应四种扫描方向。方向不对时不要改驱动里的坐标变换直接改这个寄存器值。bit7 (MY)bit6 (MX)效果00正常方向01水平镜像10垂直镜像11180 度翻转图像方向正常但位置偏移则要配0x2A列地址和0x2B行地址的起始结束坐标。RGB 并口屏的帧数据始终从左上角开始偏移问题多半出在 bridge 输出时序的 HBP、VBP 参数上而不是0x2A、0x2B。先用方向寄存器把图像摆正再微调 HBP/VBP 让画面居中这个顺序不要反过来。本文还有配套的精品资源点击获取
简介面向MTK6735平台的ST7789 RGB液晶屏SPI驱动示例为嵌入式开发者解决了通过SPI接口初始化、控制并刷新LCD显示控制器的关键问题。整个压缩包仅5KB内含1个C源文件却覆盖从底层总线配置到上层显示控制的完整链路代码紧凑便于直接阅读和移植到类似项目。实现中重点涉及SPI时钟频率、数据模式与极性的匹配命令/数据双模式发送ST7789分辨率、像素格式及显示方向设置帧缓冲区的分配与管理背光和电源时序控制以及清屏、绘制、滚动等显示更新操作此外还包含SPI传输异常检测与恢复机制。对于需要快速掌握MTK6735平台LCD驱动开发、或者参考SPI接口驱动彩色屏的工程师这份示例能减少资料查阅量适合对照数据手册逐段分析学习。目前已有787人学习浏览可用作实际项目起步阶段的样板代码。1. 这个 MTK6735 包里同时出现 LCD RGB 和 SPI先认清楚各自管哪一段打开 MTK6735.zip 之后看到MT6735 LCD rgb、MTK6735 SPI、mtk6735_s这些目录名第一反应是找 lcm 驱动源码。但更常见的实际情况是一块 5 寸 480x854 的 RGB 并口屏在工控、车载导航、数据采集终端上会同时用到 MTK6735 的两条路径。MTK6735 这一代 SoC 只把 MIPI DSI 作为真正的主显示输出LCD RGB 接口通常是桥接芯片之后的并口或者板级转接出来的 40pin FPC而 SPI 那一路多数时候承担的是同块屏的上电初始化、寄存器配置甚至有少数项目直接用 SPI 做副屏。搞清楚这个包里的文件到底在描述哪条链路比打开代码立刻找lcm_drv结构体更重要否则很容易在 DSI 和 SPI 两个方向上都瞎调半天。这篇按 MTK6735 的实际 BSP 习惯把 RGB 和 SPI 的接线、dts、驱动写法、验证手段拆开讲。2. MTK6735 的显示链路RGB 并口与 SPI 分别管什么2.1 别把 LCD RGB 当成 MTK6735 的主显示通道MTK6735 的显示输出主链路是 DSISoC 内部的 DISP 模块最终会把像素数据打给 MIPI DPHY再送到 DSI 面板。这个链路对 720p 以内的屏幕非常成熟驱动里通常表现为一个lcm设备compatible 字符串对应具体面板型号lcm-params里填lane_num、h_back_porch、v_front_porch这些时序参数。RGB 并口在 MTK 平台上是另一套逻辑。它不走 DSI 协议而是像老式 MCU 屏那样用 PCLK、HSYNC、VSYNC、DE 加 16/18/24 根数据线把像素一个点一个点地送进面板的 Source Driver。很多项目里的做法是MTK6735 输出 DSI板上再接一颗 DSI-to-RGB bridge 芯片桥出来一组 40pin 的 LCD RGB FPC 接口。也有一部分 LCM 模组本身就只有 RGB 接口没有自带 DSI 控制器那就必须在板上完成转换。所以看到一个叫MT6735 LCD rgb的目录不要默认它可以直接接到 SoC 的某个 RGB 控制器上。MT6735 原生并没有开放出去的并行 RGB 主显示控制器真正驱动这组 40pin 信号的是那颗 bridge 芯片的驱动。BSP 里的工作通常分成两块bridge 芯片的初始化以及 bridge 输出侧 RGB 时序的配置。40pin 接口里除了数据线还要重点看 PCLK 极性、DE 模式、VCOM 输出、LEDA 背光这些在模组规格书里都有明确要求。2.2 RGB 并口屏常常自带一条 SPI 命令通道这是这个标题最容易被忽略的点。一块 RGB 接口的 TFT 模组面板内部的 TCON 和 Gamma 寄存器不会平白无故处于正确状态。要让并口亮度、对比度、扫描方向符合预期要先往面板控制芯片里写入一段初始化序列然后再把像素数据从并口打进去。这段初始化序列的物理通道最常见的就是四线 SPISCLK、MOSI、CS、DC。也就是说同一个 zip 包里有LCD rgb又有SPI lcd不代表一定有两块屏。很可能是同一块模组的两条通路SPI 只负责慢速配置RGB 并口负责高速像素搬运。这种设计在 ST7789V、ILI9341 这类自带 GRAM 的屏上非常常见RGB 接口模式下数据照常从并口进入SPI 还可以继续用来读回面板 ID、改显示方向、做睡眠唤醒。写驱动的时候要把这条界限分清楚。panel_prepare阶段发的是 SPI 命令panel_enable之后并口才开始持续送像素。很多新人在 drive 里直接把 SPI 初始化序列放在probe就完事结果背光一亮屏幕全是雪花就是忽略了 RGB 并口侧 PCLK 和 DE 还没有建立。enum panel_bus_type { BUS_DSI, BUS_RGB, BUS_SPI }; static int panel_prepare(struct panel_device *panel) { switch (panel-bus) { case BUS_RGB: /* RGB 并口屏先通过 SPI 命令通道做显示配置 */ spi_write_cmd(panel-spi_dev, 0x11); /* Sleep Out */ msleep(120); spi_write_cmd(panel-spi_dev, 0x29); /* Display On */ break; case BUS_SPI: /* 纯 SPI 屏命令和数据都走同一根 MOSI */ spi_write_then_read(panel-spi_dev, panel-init_seq, panel-init_len, NULL, 0); break; default: return -EINVAL; } return 0; }SPI 时序里最要紧的不是速度而是 DC 电平切换。命令阶段 DC 拉低数据阶段 DC 拉高这个电平变化要在 SCLK 有效沿之前稳定下来。RGB 并口屏的初始化序列一般在几十个字节以内SPI 跑 10MHz 甚至 1MHz 都够用真正限制帧率的是后面的并口 PCLK不是这段 SPI。2.3 纯 SPI 屏在 MTK6735 上通常做副屏或状态屏除了给 RGB 并口屏做初始化通道SPI 在 MTK6735 上还有另一种用法直接挂一块小尺寸 SPI LCD 当副屏。常见尺寸是 1.3 寸 240x240、2.0 寸 320x240 这类分辨率驱动 IC 多为 ST7789V、GC9307、ILI9341 等。分辨率小刷新率要求不高带宽压力小非常适合用 SPI 主控持续刷新。但不要试图让这种纯 SPI 屏当 MTK6735 的唯一主显示。SPI 即使跑到 48MHz一个字节 8bit一帧 240x240x16bit 的数据量就是 115200 字节理想状态下 48MHz 传输一帧也要接近 20ms加上命令间隙、片选切换、刷新率很难做到 60fps。做状态显示、低刷新率菜单、调试信息输出是可以的做主屏交互会明显感觉拖影和撕裂。同样要注意SPI 协议和 I2C、UART 的最大区别是没有总线仲裁所有传输都由主机用 CS 拉低来声明占用。I2C 有地址和 ACKUART 有起止位而 SPI 从机只要 CS 拉低就会一直响应 SCLK。所以驱动里片选处理错了影响的不只是这一块屏挂在同一 SPI 总线上的其他设备也会被误触发。这也是 MTK BSP 里对 SPI 屏最敏感的地方。2.4 MIPI DSI、LCD RGB、SPI 三者的选型边界接口类型典型信号线数据带宽典型分辨率MTK6735 上的接入方式移植重点MIPI DSI1~4 对差分时钟/数据高1Gbps 级480x854 到 1080PSoC 原生 LCD 控制器直出DSI 时序、lane 数、LP/HS 切换LCD RGB16/18/24bit 数据线加 PCLK/HSYNC/VSYNC/DE中30MHz~80MHz PCLK480x272 到 720x1280通过 DSI-to-RGB bridge 转接像素时钟、极性、DE 模式、上电顺序SPI LCDSCLK/MOSI/CS可选 DC低几 Mbps 到几十 Mbps240x320 以下挂 SPI 主控或 GPIO 模拟时序模式、片选、刷新带宽选型结论很直接MTK6735 这个平台凡是消费类主屏优先走 DSI凡是 40pin 工控屏先确认 bridge 方案凡是只做状态指示的小屏才把精力花在 SPI 上。反之如果标题里同时出现 rgb 和 spi第一优先怀疑是同一块屏的混合接口而不是两套独立设备。3. 从 zip 素材到可编译 LCD 驱动解包、认目录、改 dts3.1 先解包确认拿到的是内核补丁还是完整工程拿到 MTK6735.zip 后我习惯先建一个干净目录再解压避免压缩包内的相对路径把自己当前工程冲掉。老平台 BSP 的 zip 一般不会只有一个顶层目录而是kernel-3.18/、vendor/mediatek/、device/混在一起甚至还有custom/、alps/这类 MTK 老工程习惯。mkdir -p mt6735_lcd cd mt6735_lcd unzip ../MTK6735.zip -d . # 看顶层有哪些目录确认内核版本和 BSP 结构 find . -maxdepth 2 -type d | sort | head -40 # 直接找 lcm 驱动源码估计 LCM 目录位于 kernel 或 mediatek 目录下 find . -path *kernel* -iname *lcm* -print 2/dev/null | head -40 # 找 dts 或 dtsi 文件确认设备树路径 find . -name *.dts -o -name *.dtsi | head -30解压后第一件事不是读代码而是先看有没有README或patch文件以及git log之类的版本信息。zip 包名里的mtk6735_s这个后缀通常只是方案商或者板厂的批次标记不代表具体功能。如果发现多个 lcm 驱动同时存在比如lcm_st7789v.c、lcm_ili9341.c需要用strings或者直接打开文件头注释来确认哪一个是针对当前项目改过的。no frames received这类现象如果在验证阶段出现大概率不是 dts 没写对而是 bridge 芯片根本没有输出时序或者 SPI 初始化序列没把面板拉出睡眠。所以解包后的第一步依赖关系是SPI 能初始化 → 并口有 PCLK → 面板才可能出画。3.2 把 lcm 驱动放回 MTK 的 LCM 框架MTK6735 那个年代的内核LCD 驱动不是标准 Linux DRM/KMS 架构而是 MTK 私有的lcm_drv框架。驱动文件通常放在kernel-3.18/drivers/misc/mediatek/lcm/之类路径通过一个lcm_drv结构体向mtkfb注册结构体里填写get_params、init、suspend、resume等回调函数。如果 zip 里的驱动直接是.c文件需要确认它有没有被对应的Makefile编进去。老 BSP 的 LCM 框架有两种编译方式一是直接塞进Makefile的obj-y二是通过lcm_id或者cust_lcm列表注册。建议先在已有工程里找一个结构类似的 lcm 驱动做模板然后用diff对比能少踩很多坑。static struct lcm_drv mt6735_spi_lcm_drv { .name mt6735_spi_lcd, .get_params mt6735_spi_get_params, .init mt6735_spi_init, .suspend mt6735_spi_suspend, .resume mt6735_spi_resume, .get_pixel_format mt6735_spi_get_pixel_format, };这个结构体里最关键的字段是name。name必须与 dts 里 panel 节点的 compatible 字符串能对应上或者被平台代码里的lcm_name表显式引用。很多移植失败的案例驱动文件编译进去了函数也没问题但 dts 里 compatible 和驱动name对不上导致驱动根本没有 probe。老 MTK 平台的lcm_drv不一定走标准of_match_table所以字符串匹配非常容易被忽略。3.3 在 dts 里声明 SPI LCD 或 RGB bridge 的设备节点MTK6735 的内核设备树SPI 节点通常长这样。明确一点如果你用的是软件片选一定要把片选脚配置成 GPIO 功能并且通过cs-gpios声明给 SPI 控制器的spicore 来管理。spi1 { pinctrl-names default; pinctrl-0 spi1_pins; cs-gpios pio 26 0; /* 软件片选由内核 spi core 统一拉放 */ status okay; spi_lcd: spi-lcd0 { compatible mt6735,spi-lcd; reg 0; /* 对应 cs-gpios 索引多设备时别写重 */ spi-max-frequency 12000000; /* spi-cpha; */ /* 老内核用 spi-mode 0 也行二选一 */ reset-gpio pio 24 0; dc-gpio pio 25 0; /* 数据/命令切换引脚 */ }; };这里spi-max-frequency不要一上来就拉满。很多 SPI 屏的规格书标称 30MHz但面板 FPC 走线长或者电平转换芯片质量一般实际跑到 12MHz 以上就出错。调试阶段先设 1MHz能出图再加频率这种方式定位问题最快。spi-mode在老内核里是数字属性0 到 3 直接对应 CPOL/CPHA 组合新内核改成spi-cpol、spi-cpha两个布尔属性。同一份 zip 里如果同时出现两种写法说明打包的人自己都合并过不同内核版本移植时要以当前工程的 bindings 文档为准。RGB 接口屏如果走 DSI-to-RGB bridgedts 里通常不是直接写spi1而是给 bridge 芯片建一个 I2C 或者 SPI 节点再把 bridge 的输出参数写到lcm节点里。bridge 和 panel 是两级设备不要混在一个节点里描述。3.4 驱动里 SPI 发送的最小完整路径MTK 平台 SPI 屏驱动最常转发的一个函数是spi_write。要写对不只是调用spi_write还要把spi_device的mode、bits_per_word、max_speed_hz设置好。否则spi_setup会返回错误或者时序完全不对。static int lcd_spi_write(struct spi_device *spi, const u8 *buf, size_t len) { struct spi_transfer xfer { .tx_buf buf, .len len, .speed_hz 12 * 1000 * 1000, }; struct spi_message msg; spi_message_init(msg); spi_message_add_tail(xfer, msg); return spi_sync(spi, msg); }spi_sync会阻塞当前进程直到传输完成适合在probe、resume里发送初始化序列。这里speed_hz只对这一次传输生效不会覆盖spi_device全局配置。如果接收方向也需要数据例如读面板 ID就要给xfer.rx_buf分配同等长度的缓冲区SPI 是全双工协议主机发出一个字节的同时一定会收进一个字节。MTK6735 的老内核 SPI 控制器发送缓冲区最好确保是 DMA 能访问的内存。kmalloc出来的地址一般没问题但如果用了栈上的局部数组某些 DMA 配置下会报 cache coherency 错误。初始化序列这种短数据量直接放在驱动里用static const数组最省事也方便后续对比寄存器改动。4. SPI 屏最容易翻车的四个点时序、片选、DMA、上电顺序4.1 先核对 SPI 时序模式再谈改初始化序列SPI 屏调试中mode配错是排第一的隐蔽问题。mode 0 和 mode 3 的 CPOL、CPHA 组合不同但很多屏的数据手册会写“supports mode 0 and mode 3”这就给移植留了坑同一块屏在 mode 0 下能显示但颜色错乱、第一个像素偏移换到 mode 3 后反而正常。原因不在屏而在桥接芯片或者面板内部逻辑对采样沿的要求。SPI ModeCPOLCPHA数据采样常见用途Mode 000上升沿采样最常用大多数 SPI LCD 默认Mode 101下降沿采样少见于 LCD用于部分传感器Mode 210下降沿采样不常见Mode 311上升沿采样与 mode 0 等效采样沿常见判断方法很简单用一个逻辑分析仪抓 SCLK 和 MOSI看 MOSI 数据在 SCLK 上升沿还是下降沿稳定。不要只看驱动里写的 mode 数字要以抓到的波形为准。MTK 老平台还有一个问题就是 pinctrl 里的 SPI CLK 引脚 drive strength 设置太低导致 SCLK 边沿变缓高速时数据采样错位。这种问题改 mode 永远解决不了要去调pinctrl的drive-strength。4.2 软件片选不是自己拉 GPIO是交给 spi core 管理linux spi 软件拉片选这个操作常见误解是在驱动里自己gpiod_set_value(cs, 0)拉低然后spi_write最后再gpiod_set_value(cs, 1)。这种做法在单设备、低速率下也许能跑但在 DMA 模式下极容易翻车。因为spi_sync内部的spi_transfer_one_message会在传输前做片选管理、在传输完成后延迟释放如果外面已经手动拉低core 再操作同一个 GPIO会造成片选电平竞争甚至 CS 在传输中间被拉高从机直接丢帧。正确做法是在 dts 里把cs-gpios配置好驱动里不要手动操作片选。多设备共用一条 SPI 总线时reg属性要写不同的索引内核 spi core 会按照cs-gpios数组自动选择哪个 GPIO 被拉低。如果确实需要特别长的片选保持时间比如某些面板要求 CS 低电平期间连续写入很多字节且中间不能有毛刺那是 SPI 控制器和时钟的问题不是靠手动拉 CS 能解决的。更好的路径是检查spi_transfer的cs_change字段在spi_message里把多个 transfer 合并成一次片选周期。4.3 不要迷信两个 DMA先看是写多还是读写都有spi 需要两个 dma 吗这个问题在 MTK6735 上要分场景。SPI 是双工协议物理上同时存在输入和输出方向所以 DMA 控制器为 TX 和 RX 各分配一个通道是很常见的。但纯写屏的应用比如往 ST7789V 的 GRAM 灌颜色数据接收方向的数据完全没用这种场景只需要拿到 TX 通道RX 通道甚至可以不 DMA或者 DMA 到一块丢弃缓冲区。# 查看 SPI 控制器使用的 DMA 通道dmesg 里通常会有 dmesg | grep -i spi | grep -i dmaMTK 老内核的 SPI DMA 配置分散在 dts 的dmas属性和平台驱动里。如果发现录数据时画面撕裂、出现随机条纹优先检查 DMA 的 burst size 和 address alignment而不是怀疑屏的初始化序列。RGB 并口屏的像素写操作一般从memcpy到fb再走并口DMA 问题主要出现在大量连续 SPI 写 GRAM 的场景。对调试阶段最友好的办法是先禁用 SPI DMA强制用 PIO 模式把屏点亮验证时序和初始化正确后再重新打开 DMA 优化速度。MTK 平台上禁用 DMA 通常只需在 dts 中移除dmas属性或者在平台驱动里把use_dma标志置 0。这种方式能用最短路劲把“时序问题”和“DMA 问题”分开。4.4 上电顺序错误SPI 命令写了也白写RGB 并口屏和纯 SPI 屏都严格要求上电顺序。常见顺序是VCI 电源先上然后 IO 口电源 VDDI等电源稳定后拉高 RESET释放复位后再延时至少 10ms然后才能发第一条 SPI 命令。如果把背光先打开屏幕上电瞬间会先出现一块白屏然后 SPI 写入初始化序列后才能恢复正常。# 用 GPIO 控制的简化上电流程具体引脚号和次序以屏规格书为准 echo 1 /sys/class/gpio/gpio20/value # VCI enable sleep 0.02 echo 0 /sys/class/gpio/gpio24/value # RESET low sleep 0.01 echo 1 /sys/class/gpio/gpio24/value # RESET high sleep 0.12 # 等待内部 DCDC 稳定 echo 1 /sys/class/gpio/gpio21/value # 背光 enable上电顺序项目里最常犯的错误是把 RESET 和背光绑定在一起。RESET 拉低时间太短面板内部寄存器没复位干净后续 SPI 写入的命令会被部分忽略。典型表现是初始化序列执行完后屏能亮但颜色不对、行列方向错乱而且反复重试都不恢复必须断电重来。屏的 PCLK 也要注意。RGB 并口模式下PCLK 极性、DE 模式、HSYNC/VSYNC 是否取反都要和面板规格书对齐。PCLK 极性反了图像不会消失而是整体偏色、闪烁、或出现水平方向的错位。这类问题在 dts 的lcm参数里改不要到 SPI 驱动里找。5. 验证 MTK6735 SPI/RGB 屏彩条、读 ID 和方向表5.1 用 mmap 直接刷帧确认并口数据通路SPI 初始化成功不等于整个显示链路正常。RGB 屏点亮后最快验证方式是直接向/dev/fb0填充颜色数据。不要用dd写 framebuffer很多 MTK 老内核的 fb 设备只支持 mmap 映射用write系统调用会返回 EINVAL。用一段简单 C 代码 mmap 后 memset 最可靠。#include stdio.h #include fcntl.h #include sys/mman.h #include unistd.h #include string.h int main(void) { int fd open(/dev/fb0, O_RDWR); unsigned char *fb; int screensize 480 * 800 * 3; /* RGB888按实际 framebuffer 格式调整 */ fb mmap(NULL, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (fb MAP_FAILED) { perror(mmap); return 1; } memset(fb, 0xff, screensize); /* 全白验证数据线空闲电平 */ sleep(2); memset(fb, 0x00, screensize); /* 全黑验证像素时钟有效 */ munmap(fb, screensize); close(fd); return 0; }全白之后看到满屏白色并且不闪烁说明并口数据线、PCLK、DE 基本正常。再看全黑是否纯黑如果黑色中带竖条纹往往是 RGB 数据线有虚焊或者 bridge 输出位数没对上。刷不同颜色的顺序建议是全白、全黑、纯红、纯绿、纯蓝。纯色不对优先检查数据位映射因为 RGB 接口 18bit 和 24bit 模式下低两位的接法经常不一致。5.2 用 SPI 读回面板 ID验证命令通道SPI 命令通道能不能读是判断驱动是否真正掌控面板的最好方法。多数 SPI 屏支持0x04读回面板 ID或使用厂商自定义读命令。用户态 spidev 工具在 DC 引脚不容易控制的情况下我一般直接在驱动初始化函数里加一段临时读逻辑u8 cmd 0x04; u8 rx[4] {0}; /* DC 拉低发送命令再拉高读取数据 */ gpiod_set_value(dc_gpio, 0); lcd_spi_write_read(spi, cmd, 1, rx, 4); gpiod_set_value(dc_gpio, 1); pr_info(lcd id: %02x %02x %02x %02x\n, rx[0], rx[1], rx[2], rx[3]);读到的 ID 如果全是 0x00 或者 0xff优先怀疑 CS 时序和 DC 切换不要怀疑屏坏。很多 SPI 屏读 ID 需要先把面板从 sleep 状态唤醒或者在读命令之前先发特定的 unlock 命令这就回头检查第一段初始化序列是否完整。5.3 行列方向和偏移写在方向寄存器里最后一块常见问题是图像方向不对。RGB 屏和 SPI 屏大都通过0x36面板方向寄存器控制行列扫描。以常见驱动 IC 为例0x36的 bit7 是 MYbit6 是 MX两者组合对应四种扫描方向。方向不对时不要改驱动里的坐标变换直接改这个寄存器值。bit7 (MY)bit6 (MX)效果00正常方向01水平镜像10垂直镜像11180 度翻转图像方向正常但位置偏移则要配0x2A列地址和0x2B行地址的起始结束坐标。RGB 并口屏的帧数据始终从左上角开始偏移问题多半出在 bridge 输出时序的 HBP、VBP 参数上而不是0x2A、0x2B。先用方向寄存器把图像摆正再微调 HBP/VBP 让画面居中这个顺序不要反过来。本文还有配套的精品资源点击获取
