拉了一个RK3576的项目,客户屏幕是LVDS接口,我的第一反应就是加一颗MIPI DSI2转LVDS的桥接芯片。选型时定了GM8775C,数据手册看着挺简单:输入侧接RK3576的DSI2输出,输出侧直接喂给LVDS屏,外加一颗I2C寄存器配置完事。真开始调试,才发现整条链路从DSI时序到LVDS映射再到上电顺序全是坑。这篇文章就把我调试GM8775C这一路的完整思路和踩坑记录写出来,重点不是贴一份能直接编译的代码,而是告诉你每一步为什么要这么做、出问题该往哪个方向查。后面接同类型bridge芯片的朋友,能少走几周弯路。1. 这个案子到底在做一件什么事1.1 RK3576、DSI2、GM8775C,三者是什么关系先把这三颗东西的角色理清楚。RK3576是主控SoC,它负责跑系统、生成画面,显示控制器从内存里读帧,然后通过内部Display Controller输出到MIPI DSI2主机控制器。RK3576支持多路显示输出,HDMI、DP、MIPI DSI/DSI2、eDP都有,具体哪些同时输出跟具体封装和引脚复用有关。MIPI DSI2是MIPI联盟的显示串行接口标准第二版。相比传统的DSI,它可以在D-PHY 2.x或C-PHY上运行,带宽上限更高,还加入了DSC显示流压缩等新特性。但在GM8775C这类桥接芯片的场景里,我们基本用不到DSI2的新增功能,只需让RK3576以传统DSI协议、D-PHY物理层的方式把视频流发出去。所以说,别一听DSI2就觉得跟DSI不兼容,物理层和协议层向下兼容,实际调试中我甚至建议先按老DSI的思路把链路跑通,再回头看要不要开高级特性。GM8775C是一颗MIPI DSI/LVDS桥接芯片,输入侧接收MIPI DSI信号,输出侧转成单通道或双通道LVDS。跟我们常用的需求一致:很多工业屏、医疗屏、车载屏原生就是LVDS接口,主控没有LVDS或者不想主板走线绕一大圈,干脆用DSI输出,在屏端附近放一颗桥接芯片,把信号转成LVDS。GM8775C的配置方式几乎都是I2C写寄存器,少数引脚用于复位、中断或者说状态输出。三者连起来的结构就是:RK3576的Display Controller → MIPI DSI2 TX → GM8775C → LVDS Panel。画面数据在RK3576里是内存中的RGB像素,经过DSI串行化,到达GM8775C后并行化,再按LVDS协议重新打包发到屏端。中间任何一个环节的时序参数、格式定义、物理连接有问题,屏上都会直接反映出来。1.2 完整链路与信号流向调试前,一定要非常清楚整条链路里有哪些信号,否则出了问题你会完全不知道从哪查起。从RK3576到GM8775C,通常有这么几组信号:MIPI DSI高速信号:D0/D1/D2/D3四组数据对,一组时钟对。I2C控制总线:SCL/SDA,用于给GM8775C写寄存器,一般是100K或者400K。复位信号:RST,低有效或高有效要看手册,控制芯片的启动时序。电源:核心供电、IO供电、LVDS端供电,多路。可选的GPIO:比如芯片状态脚、使能脚。从GM8775C到LVDS屏,信号是:LVDS差分对:4组或者5组数据,外加一组时钟。8位色深单通道LVDS是4组数据1组时钟,6位色深是3组数据1组时钟,双通道就直接翻倍。背光控制:BL_EN、PWM,这部分一般不经过桥接芯片,直接由主控或背光驱动IC控制。屏供电:AVDD、VGL、VGH等,跟桥接芯片无关,但要保证时序。我把调试过程拆成四段来排查:第一段是RK3576的DSI输出,第二段是GM8775C自身的I2C配置,第三段是GM8775C到屏的LVDS输出,第四段是背光与电源时序。每一段都有独立的现象特征,后面我会按这个思路展开。2. 上板点亮前,先把这几笔账算清楚很多人拿到板子第一件事就是刷个固件、接上屏、看能不能亮,运气好点亮了,但配置全是拍脑袋填的,稳定性和适配性一塌糊涂。我的习惯是上电之前先算清楚三笔账:像素时钟、DSI lane速率、LVDS通道与格式。2.1 像素时钟、DSI速率与LVDS带宽的估算屏的时序不是说有效分辨率1920x1080、刷新率60Hz就够了,真正决定带宽的是带消隐的完整行场时序。举例,一块1080P 60Hz的LVDS屏,典型时序大概是:行有效1920行消隐总长大约280个像素时钟(前肩、后肩、同步信号加起来)列有效1080列消隐大约45行这种情况下像素时钟通常在148.5MHz左右,而不是直接用1920108060。你的屏要是用更极端的简化消隐,像素时钟会是138MHz甚至更低。屏参这一块必须以面板规格书给的HFP、HBP、HSYNC、VFP、VBP、VSYNC为准,一定注意最小值和典型值。算一下DSI链路需要多少带宽:像素时钟148.5MHz,24bit RGB,那么一个像素时钟周期要传24bit数据,总数据率148.5MHz * 24 3.564Gbps。这是理想值,还没算MIPI协议包头、包尾、EOT等开销。如果你的RK3576和GM8775C之间配4条lane,每条lane的实际码率就是3.564Gbps除以4,大约891Mbps。考虑协议开销和裕量,我建议按1Gbps甚至更高配lane rate,别卡着理论值算。再来看GM8775C到LVDS侧的带宽。LVDS是并行转串行,单通道8bit输出的情况下,一个像素时钟周期通过4条数据线传28bit(其中24bit颜色数据加同步和DE控制位),因此单通道LVDS的像素时钟可以到135MHz左右。1080P60用双通道LVDS比较稳妥,每个通道负担一半像素,GM8775C的LVDS时钟大约75MHz,余量很足。这一笔账算下来,你就知道瓶颈在哪:输入侧DSI的总带宽决定了能不能跑1080P60,输出侧LVDS的通道数决定了要不要把GM8775C配成双通道模式。如果屏只有单通道LVDS接口,却硬上1080P,那就是找死,像素时钟太高,LVDS信号质量无法保证。2.2 LVDS的VESA/JEIDA格式和通道数,一刻也不能搞错LVDS不仅仅是一堆差分线,数据怎么映射是有讲究的。老工程师常说的VESA格式和JEIDA格式,本质上就是LVDS数据线上的bit和RGB颜色分量之间的对应关系不同。同样是8bit的LVDS,4组数据线在一个周期内要传28bit,其中24bit是RGB、3bit是控制位、1bit是DE。VESA和JEIDA对RGB哪个bit放在哪个数据线的哪个位置有完全不同的定义。如果你配错了格式,最常见的现象是屏能亮,但颜色完全不对,或者是像负片一样的反色,还有的屏会出现彩色雪花颗粒。怎么判断你的屏是VESA还是JEIDA?查面板规格书里的LVDS Mapping图,图里会明确画出来。如果规格书没写,直接问屏幕原厂,这是最靠谱的做法。GM8775C的初始化里一般都有对应寄存器选VESA还是JEIDA,不要只看示例代码里的默认值,一定要和屏对上。通道数同理。有些屏是双通道LVDS,你只开了单通道,画面会裂成左右两半或者出现规则的竖条纹;反过来把单通道屏配成双通道,可能直接黑屏或者花屏。GM8775C通常有寄存器配置Single/Dual通道,寄存器配置写错等于输出完全不对。2.3 电源、复位、背光的时序账桥接芯片最常见的点不亮,其实是上电时序不对,不是配置不对。我一般按照这样的顺序做:先给屏和桥接芯片的供电,AVDD、VCC这些先稳定。保持复位脚有效一段时间,让芯片完成内部复位。释放复位,拉高RST,开始延时。延时后通过I2C写初始化寄存器。等芯片输出稳定后,再开背光。这个顺序别搞反,尤其是背光。很多人调试时为了方便,背光直接接个12V常亮,结果屏一通电就是白光,桥接芯片还没开始工作,模拟前端没有信号,屏幕就一直处于异常状态。这样不仅看不出问题,还可能把屏烧出残影。GM8775C这类桥接芯片的复位时间一般要求最少10ms到20ms,RST释放之后还要给芯片一段稳定时间再访问I2C,否则寄存器写了也白写。我以前遇到过写寄存器一直失败,I2C回读超时,最后发现是RST拉高后只等了1ms就急着初始化。别省这几毫秒。3. GM8775C的I2C初始化,别急着写驱动我最初拿到GM8775C的时候,第一反应是去内核里写一个mipi_dsi2到LVDS的bridge驱动,结果代码写了一半发现,连寄存器都写不进去,驱动写再多也没用。后来我改变了策略:先用命令行工具把手动配置流程跑通,再回头写驱动。3.1 先把芯片用I2C工具裸调通,再谈Linux驱动在RK3576的Linux系统起来之后,先用i2cdetect扫一下总线:i2cdetect -l i2cdetect -y 1-l列出所有I2C总线,-y 1扫描总线1。先确认GM8775C挂在哪条总线上,扫出来的地址对应哪个设备。如果扫描不到器件,大概率是地址不对、上拉电阻没焊、或者芯片供电/复位没就绪。这里特别强调一嘴I2C地址的7位和8位写法。很多芯片手册写的是8位地址,比如0x88,但i2c-tools和Linux内核里用的是7位地址0x44。实际写驱动时,I2C_BOARD_INFO里填的地址要和i2c_detect扫出来的一致。这个换算问题我见过不止一个同事翻车,严格来说不是芯片问题,是数据手册阅读习惯问题。扫描到器件之后,用i2ctransfer直接读写寄存器:# 写寄存器0x03,值0x55 i2ctransfer -y 1 w2 0x44 0x03 0x55 # 回读寄存器0x03 i2ctransfer -y 1 w1 0x44 0x03 r1如果是8bit寄存器地址的芯片,上面的命令就能满足;如果芯片寄存器地址是16bit,则写地址时要多传一个字节。不同型号不一样,以手册里的I2C访问图为准。裸调通过之后,再把它改成内核驱动里的i2c_transfer或者regmap_write,逻辑就清晰很多。这样调试时出了问题,你不用怀疑是驱动框架的问题,可以先确认是芯片本身的配置问题。3.2 初始化顺序的通用模板与原理GM8775C这类芯片的初始化寄存器一般可以分成这么几个功能块:软件复位PLL和时钟配置MIPI DSI接收端配置LVDS输出端配置输出使能我写初始化序列时的通用逻辑是:static int gm8775c_init(struct i2c_client *client) { /* 1. 软复位 */ i2c_smbus_write_byte_data(client, 0x01, 0x01); msleep(20); /* 2. 读ID,确认芯片活着且版本正确 */ val i2c_smbus_read_byte_data(client, 0x00); dev_info(client-dev, GM8775C ID 0x%02x\n, val); /* 3. 配置PLL和时钟,根据MIPI lane rate */ i2c_smbus_write_byte_data(client, 0x02, pll_div 0xff); /* 4. 配置MIPI DSI侧:lane数、continuous clock */ i2c_smbus_write_byte_data(client, 0x10, MIPI_DSI_4_LANE | MIPI_PHY_CLOCK_CONTINUOUS); /* 5. 配置LVDS侧:VESA/JEIDA、单/双通道 */ i2c_smbus_write_byte_data(client, 0x20, LVDS_JEIDA | LVDS_DUAL_CHANNEL); /* 6. 使能输出 */ i2c_smbus_write_byte_data(client, 0x30, 0x01); msleep(100); return 0; }上面的代码只是表达顺序,寄存器地址和位定义不要直接照抄,每颗芯片都不一样,必须以官方数据手册为准。我强调的是这个顺序逻辑:PLL和接收端配置要先于输出端使能,输出端使能要放在最后。顺序反了的话,芯片内部状态机可能直接锁死,后面的寄存器怎么改都没反应。另外,初始化完成不代表立刻就有画面。芯片需要一个内部稳定和PLL锁定时间,通常在几十毫秒到一百毫秒不等。如果发现初始化之后屏幕依然是黑的,不妨在使能输出之后加一个100ms的延时再看。3.3 寄存器写不进去或写进去不生效调试过程中我总结了几类典型的寄存器问题:第一类,I2C传输没有ACK。用i2cdetect能扫到,但写寄存器时返回Remote I/O error,重点查RST引脚是不是被别的外设拉低了,或者I2C上拉电阻没接、电压域不匹配。第二类,写入成功,回读也是刚才的值,但屏没有反应。这种情况通常是芯片处于Power Down或Sleep模式,接收端还在关闭状态,命令被丢弃了。需要先往芯片的Power Management寄存器写唤醒命令,再继续初始化。第三类,寄存器整体偏移。我之前遇到一个很隐蔽的问题,芯片寄存器手册从0x00开始排,但我按手册写入后屏怎么都不对,后来发现是I2C子地址自动递增功能关闭了,我连续写寄存器时,芯片只认第一个地址,后面的全都写到同一个位置。解决方法是单字节逐地址写,不要依赖自动递增。第四类,写寄存器后马上回读发现值变了。这不一定是你写错了,可能是芯片内部状态机改了寄存器状态,也可能是该寄存器是只读的。硬件调试里,写不进去不一定是I2C问题,寄存器属性也要查清楚。4. RK3576的DSI2配置与dts匹配GM8775C这边配置好了,只代表桥接芯片做好了接收数据的准备。RK3576的DSI2控制器还要按双方约定好的格式把数据发出来,这部分主要通过设备树里的显示节点配置。4.1 从屏参到panel-timing的转换在RK3576的dts里,你会定义一个panel节点或者bridge节点。如果直接把GM8775C当成一个标准的DRM bridge挂到MIPI DSI2控制器上,那么panel/screen的具体时序参数要放到panel-timing里面。一个典型配置长这样:mipi_dsi2 { status okay; panel0 { compatible example,lvds-panel; reg 0; enable-gpios gpio2 RK_PC1 GPIO_ACTIVE_HIGH; reset-gpios gpio2 RK_PC2 GPIO_ACTIVE_HIGH; pinctrl-names default; pinctrl-0 lcd_panel_reset; backlight backlight; port { panel_in_dsi: endpoint { remote-endpoint mipi_dsi2_out_panel; }; }; panel-timing { clock-frequency 148500000; hactive 1920; vactive 1080; hback-porch 148; hfront-porch 88; hsync-len 44; vback-porch 36; vfront-porch 4; vsync-len 5; de-active 1; pixelclk-active 0; syncclk-active 0; }; }; };clock-frequency单位是Hz,这里写148500000,就是148.5MHz。hsync-len、hback-porch、hfront-porch、vsync-len、vback-porch、vfront-porch的数值必须来自你屏的规格书,不要拿网上某款差不多分辨率的屏参直接抄。不同面板对这三个参数的要求不一样,设错之后最典型的表现是画面偏移、边缘有黑边、或者水平方向有撕裂。de-active、pixelclk-active、syncclk-active这几个极性标志位也要和LVDS面板要求一致。LVDS面板一般可以接受DE模式或SYNC模式,但极性反了会出现画面上下颠倒、水平条纹或者干脆不亮。4.2 lane、clock、video mode的耦合在RK3576的DSI2节点里,通常会配置:mipi_dsi2 { assigned-clocks cru PHY_MIPIDSI2; assigned-clock-rates 1000000000; // 1Gbps per lane };这个assigned-clock-rates设的是D-PHY lane rate,不是像素时钟。这里要特别小心:lane rate跟你要传的分辨率、刷新率、lane数三者必须匹配。前面算过,1080P60在4 lane下至少要891Mbps的码率,加上协议开销,我习惯直接配1000Mbps。如果配得偏低,链路在HS传输时码率不够,GM8775C内部FIFO就会欠载,表现为周期性闪屏、水平撕裂或者画面随机花屏。video mode也值得注意。MIPI DSI有三种基本video mode:Non-Burst mode with Sync Pulses、Non-Burst mode with Sync Events、Burst mode with Sync Events。GM8775C这类老牌桥接芯片,有些只对某种模式支持得比较好。你需要在GM8775C手册里找到它期望的DSI接收模式,然后对应RK3576的dts或驱动去设置。这里最容易踩的坑是:寄存器里选对了lane数,但视频模式没配对,屏能亮,可长时间跑会偶发抖动、黑一帧。出现这种现象,先比对两边的手册确认模式是否一致。还有一个坑是continuous clock。DSI的时钟lane可以一直保持HS时钟连续输出,或者在没有数据传输时切回LP状态。有些芯片对continuous clock和非continuous clock的处理不一样,配置错了会导致信号间歇性异常。RK侧驱动一般可以设置是否强制continuous clock,针对GM8775C我建议按它手册明确要求来,不要想当然。4.3 GPIOS和backlight在dts里的坑dts里的GPIO配置看起来简单,实际上很容易跟其他模块打架。reset-gpios和enable-gpios在dts里的active level要注意。GM8775C的复位脚可能是低有效,你在dts里写成GPIO_ACTIVE_HIGH就会变成复位脚一直处于无效状态,芯片不工作,但又很难看出来,因为供电和I2C都正常。另一个常见问题是背光使能和PWM冲突。调试阶段,我建议先把背光拉到常亮模式,用固定电平驱动,不要上PWM调光。如果你一上来就开PWM调光,而PWM频率和屏的刷新率不匹配,画面上会出现斜向滚动条纹,这时候你会误以为是LVDS时序问题,查半天查不到根因。背光亮的顺序也要通过dts或驱动保证在显示内容稳定之后再打开。如果背光在DSI还没有输出画面时打开,你会看到瞬间的白屏或者闪屏,严重时液晶屏上会留下残留影像。5. 黑屏、花屏、闪屏排查链路做显示调试,绝大部分时间都在跟三种现象搏斗:黑屏、花屏、闪屏。每一种背后的原因差别很大,我按我的排查优先级写一下。5.1 黑屏:背光、链路、数据三选一黑屏第一步不是拿示波器去量波形,而是确认背光是不是亮了。背光亮但没画面,和背光不亮完全两码事。拿手电筒对着屏幕斜着照,如果能看到淡淡的画面,说明LCD已经出图,只是背光没工作,问题在BL_EN、PWM或背光驱动IC上。如果是什么都看不见,再往下查。第二步,确认GM8775C有没有LVDS时钟输出。用示波器量LVDS差分时钟对,如果时钟波形正常但数据线无输出,说明桥接芯片PLL已经锁定,但没有收到有效的DSI数据。这时重点查RK3576的DSI输出是否使能、显示的plane有没有打开。第三步,RK3576侧查DRM状态,确认显示链路真的起来了:cat /sys/kernel/debug/dri/0/state看plane有没有active,crtc有没有enable,connector状态是否connected。如果内核里显示链路压根没有启动,屏自然黑着。这个命令比反复改dts高效得多。还有一种黑屏是雪花噪点,不是纯黑。出现雪花通常是LVDS信号有误码,或者GM8775C输出的LVDS信号格式不对。先查VESA/JEIDA,再查双通道/单通道。5.2 花屏:格式、极性、位序逐个排除花屏的样式能说明很多问题。全屏彩色噪点,像电视没信号一样:优先怀疑LVDS数据映射格式错误,VESA/JEIDA选反是最常见原因。画面整体偏色或者颜色像是被拉开了:检查颜色深度,LVDS屏是6bit还是8bit,GM8775C输出对应的色深配置是否匹配。左右两半画面错位或重影:双通道LVDS的奇偶通道映射反了。垂直方向有多条细竖线:很可能是LVDS数据线的物理顺序接反了,查原理图或排线定义。花屏问题的排查顺序,我建议是:先软件后硬件。软件上挨个试VESA/JEIDA、单双通道、色深;如果怎么配都不对,再测LVDS差分线对有没有短路、断路、A/B两路信号是否接反。如果你手头有逻辑分析仪,建议直接抓LVDS数据线,按照屏规格书对照数据映射。没有分析仪也没关系,用排除法同样能解决问题,只是过程痛苦一点。5.3 闪屏:时钟和FIFO带来的欠载闪屏和花屏不一样,它是动态的、周期性的。常见原因有这么几类。第一类是DSI带宽不足。前面算过1080P60至少需要约3.56Gbps,如果lane rate配得太低,GM8775C的内部FIFO就会周期性欠载,画面表现为几秒一次的水平撕裂或者轻微闪烁。解决方法是调高lane rate,或者降低刷新率/分辨率先做验证。第二类是PCLK的参考时钟不稳定。RK3576的MIPI PHY时钟如果抖动过大,DSI高速链路的误码率会上升。这种情况在刚上电时偶尔正常,跑几十分钟之后开始花屏,降频后好转。怀疑时钟问题时,检查晶振负载电容、PHY电源纹波,以及SoC侧clk_summary里实际的clock频率是否跟dts设置一致。第三类是背光PWM和刷新率耦合。背光PWM频率接近屏刷新率时,会产生明显的滚动条纹,看起来像隔几秒闪一下。这个不是显示链路问题,但非常容易误判。建议先把背光PWM关掉,用纯直流高电平点亮,如果闪屏消失,就是背光频率问题。5.4 远程与现场工具怎么配合嵌入式显示调试,很多时候屏幕没起来,唯一能看状态的只有串口。我习惯开机时把内核最全的日志打出来:dmesg -w drm.debug0x3f不要吝啬日志级别,显示驱动的问题往往藏在某个probe失败、时钟rounding、或者PHY初始化警告里面。如果板子能通过网络和ADB访问,更方便的是用adb挂进来:adb shell dmesg adb shell cat /sys/kernel/debug/dri/0/state adb shell cat /sys/kernel/debug/clk/clk_summary | grep dsi串口调试助手、网络调试助手这类工具我都用过,核心思路是快速拿到内核状态。别等到屏完全点不亮才去开log,应该在点亮过程中全程开着,很多线索一闪而过,事后看日志才能发现。6. 桥接链路之外的三个姐妹坑调试GM8775C的过程中,我发现很多问题并不是桥接芯片本身引发的,而是整个系统里其他模块跟显示链路纠缠在一起。这几个坑单独拿出来说,能省大家很多排查时间。6.1 Android 14插HDMI后媒体声音消失这个问题的表象是:安卓14的设备,显示输出到HDMI之后,媒体声音突然没了。很多人在GM8775C的板子上遇到这问题,第一反应以为是HDMI声音没走通,回去查HDMI音频驱动,结果把桥接芯片晾在一边。实际上,GM8775C是纯视频桥,HDMI音频跟它一点关系都没有。真正的问题是Android音频策略在HDMI插入时,自动把媒体音频路由到了HDMI输出节点,但HDMI的音频节点没有正确使能,于是声音就等于被吞了。排查思路是:adb shell logcat -d | grep -i audio adb shell dumpsys audio | grep -E Devices|Routes重点看事件发生后音频路由切换到了哪个设备。正常情况下应该能看到一个ACTION_HDMI_AUDIO_PLUG或类似的插拔事件,然后路由切到HDMI。如果设备列表里根本没有HDMI音频节点,那就是HDMI音频驱动或ALSA配置没起来;如果节点存在但声音还是无声,再查混音器和音量策略。这个问题提醒我们:系统集成阶段,显示和音频是独立链路,别因为现象纠缠在一起就把它们混为一谈。6.2 同一总线上其他外设的干扰GM8775C挂在I2C总线上,有时候这颗芯片不工作,不是它自己的问题,而是同一总线上某个设备把总线拉死了。排查I2C问题时,建议用i2cdetect扫完整条总线,看看扫描结果里是不是多了些不存在的地址——那可能是某个设备异常下拉导致的总线冲突。还有一个更隐蔽的坑是电源耦合。我调过一块板子,GM8775C初始化一次成功,但屏幕每隔十秒闪一下,后来发现是摄像头的AVDD和LVDS供电共用了一路LDO,摄像头开启时把该路电压拉低了几十毫伏,LVDS信号眼图直接劣化。这种问题只看时序、寄存器是查不出来的,得靠示波器量电压波形。此外,同一套系统里YT8521这类PHY芯片如果复位、中断线和显示相关GPIO复用冲突,也可能造成背光或复位脚被拉偏。排查手段很简单,cat /sys/kernel/debug/gpio看每个GPIO的占用状态,是不是有驱动把GM8775C的复位脚抢走了。6.3 画质细节:颜色偏、彩条、低亮度闪烁桥接芯片点亮了、画面正常了,不代表调试结束。画质问题才是评判项目能不能量产的关键。如果屏在低亮度下出现明显闪烁,先查背光PWM调光频率。很多LVDS工业屏在低占空比下,如果PWM频率只有200Hz,人眼会明显感觉到闪烁。把PWM频率提到1kHz以上甚至更高,问题会立刻缓解。这跟GM8775C没关系,但很容易被归罪到桥接芯片画质不好上。如果颜色整体偏色,用示波器或者逻辑分析仪抓LVDS数据线,对照屏规格书看G通道是不是和B通道交换了。我遇到过原理图上标着D0、D1、D2、D3,实际板上走线却有两组交叉,软件怎么配都偏色,最后改板解决。这种硬件问题,软件调试再久也没用。出现规则彩条,很可能是6bit屏被当成8bit输出,或者反过来。GM8775C输出色深要和屏端统一,寄存器配错后,低两位颜色数据就被丢弃或错位,显示效果就是横向渐变色带。7. 我觉得最有价值的几条经验调试GM8775C这段时间,我最大的体会是:显示链路调试没有捷径,但一定有方法。这里把我认为最有价值的几条经验写出来。第一,永远从链路分段入手。别一上来就怀疑芯片坏了或者内核驱动有bug。先把链路分成DSI输入、I2C配置、LVDS输出、背光电源四段,每一段都有独立的验证方法。一段一段确认正常之后,再连起来跑整机,问题范围会小很多。第二,裸调先行,驱动后补。操作系统起来之后,先用i2c-tools确认I2C通路,再用命令逐条写寄存器,确认画面能正常出来,再动内核驱动。这样能把芯片配置问题和驱动框架问题彻底隔离开。第三,所有参数都要有出处。屏参、lane rate、VESA/JEIDA、通道数、极性,每一个配置都要能追溯到面板规格书或者GM8775C数据手册。最怕的就是凭感觉抄一份网上配置,上下电时序、信号极性都不一样,点不亮时无从下手。第四,工具链要备齐。示波器是必需品,尤其是双通道以上的差分探头;逻辑分析仪对于抓I2C和LVDS高低电平非常有帮助;内核的drm debugfs节点和clk_summary能帮你快速判断时序和时钟状态。没有这些工具,纯靠猜,效率很低。第五,别忽略系统层面的联动。桥接芯片调试只是整个方案里的一环,HDMI音频路由、I2C总线复用、电源负载耦合,这些系统级的问题都会伪装成显示问题。遇到诡异现象,先跳出来看整板,再钻进细节。最后分享一个偷懒技巧:调试初期,先把刷新率降到30Hz、分辨率降到720P,把链路通不通的问题先解决。链路没问题之后,再逐步恢复1080P60,每一步都有明确变量,出问题能精准定位。这比一直用满配置反复试要快很多。