Backlight 与 LCD Class 框架

1. Backlight对象

backlight_device包含：

• class device；
• backlight_ops；
• properties；
• update lock；
• notifier；
• parent和driver data。

Properties包括brightness、max_brightness、power、fb_blank、state和type。

2. 注册

1
2
3
4
5
6

backlight_device_register/devm_backlight_device_register
 -> validate ops/properties
 -> allocate class device
 -> create sysfs
 -> add to list
 -> update initial status

Managed注册简化内存释放，但remove前仍应关闭输出。

3. Ops

• update_status()：应用brightness/power/blank；
• get_brightness()：读取硬件实际值；
• check_fb()：决定某framebuffer事件是否关联；
• controls_device等辅助。

4. 有效亮度

Core综合：

• requested brightness；
• power；
• fb blank；
• suspended state；
• thermal/driver限制。

若blank/power要求关闭，有效brightness应为0，即使sysfs brightness仍保留用户请求。

5. Sysfs

典型属性：

• brightness；
• actual_brightness；
• max_brightness；
• bl_power；
• type；
• scale。

写brightness调用backlight_update_status()，driver必须校验范围。

6. Notifier

Backlight状态变化可发notifier，panel/graphics clients也可调用强制更新。Callback不能在update lock下形成循环依赖。

7. LCD Class

lcd_device是较旧的面板电源/contrast抽象，ops包括set/get power、contrast、mode。现代面板通常使用DRM panel framework，LCD class主要服务legacy驱动。

本版本LCD Core有两个历史边界：

• contrast sysfs写路径不统一校验max_contrast，driver仍需自行防越界；
• fb notifier除blank外，对其它事件调用set_mode时缺少严格的FB_EVENT_MODE_CHANGE过滤，legacy driver的callback必须谨慎验证输入。

8. Blank与DRM

历史fbdev通过FB blank事件影响backlight；现代DRM connector/panel在atomic enable/disable中控制panel和backlight。

两条路径同时操作时需避免：

• 一边enable另一边blank；
• suspend重复关闭；
• brightness恢复顺序错误。

9. PM

Suspend：

1
2
3

mark suspended
 -> update_status -> hardware off
 -> panel/rail off

Resume先恢复power/PWM，再按保存brightness update。

10. 热管理

亮度可能被thermal cooling或LED framework限制。Sysfs requested和actual brightness不同是正常现象。

11. 安全

Backlight不是机密接口，但恶意高频写可造成闪烁、PWM负载和面板寿命问题。限制普通容器访问sysfs，并对更新做合理串行。

12. RK3588

大量板级panel节点引用backlight = <&backlight>，常见实现为pwm-backlight。Backlight class在本目录，panel/connector通常在DRM。

通过名称或OF节点查找到backlight对象后，非devm调用方需用put_device(&bd->dev)释放引用；本版本没有独立的backlight_put() API。

PWM 与 GPIO 背光驱动

1. PWM Backlight

pwm_bl.c是RK3588常用路径：

1
2
3
4
5
6

platform probe
 -> parse brightness-levels/default index
 -> get PWM/regulator/enable GPIO
 -> calculate period/duty mapping
 -> register backlight device
 -> update initial status

2. DTS

典型：

1
2
3
4
5
6
7
8

backlight: backlight {
    compatible = "pwm-backlight";
    pwms = <&pwmX channel period flags>;
    brightness-levels = <...>;
    default-brightness-level = <...>;
    power-supply = <&...>;
    enable-gpios = <&gpio ...>;
};

Panel通过backlight phandle关联。

3. Duty计算

用户brightness先映射到brightness-levels[]，再按scale和PWM period得到duty cycle。

需避免：

• 乘法溢出；
• levels非单调；
• index越界；
• 0亮度仍输出duty；
• polarity反向。

4. 上电顺序

常见enable：

1
2
3
4

enable regulator
 -> assert GPIO
 -> configure PWM duty/period
 -> enable PWM

关闭通常反向，并满足panel datasheet延迟。实际顺序可由driver/platform callback调整。

5. PWM极性

Active-high/low由PWM flags和硬件定义共同决定。配置错误会导致：

• 0最亮；
• 默认全亮；
• suspend漏光；
• enable瞬间闪白。

6. GPIO Backlight

gpio_backlight.c仅支持开/关级别，适合无亮度调节的简单板。它注册backlight class并控制enable GPIO。

7. LED Backlight

led_bl.c可把LED class设备聚合为backlight。适用于多通道LED，但需协调LED trigger和backlight ownership。

8. RK3588 DTS

本树tablet、EVB及vehicle显示DTS中存在大量compatible = "pwm-backlight"节点。SoC公共节点并不代表每块板都启用，需检查最终DTB的PWM、regulator和status。

9. DRM Panel协作

正确时序通常为：

1
2
3
4

panel prepare
 -> bridge/PHY enable
 -> panel enable
 -> backlight enable

关机反向。Backlight过早开启会显示未初始化帧。

10. Suspend/Resume

Driver保存requested brightness，通过Core suspended state让effective brightness为0。Resume恢复前需保证PWM clock和regulator已准备。

11. 调试

1
2
3

ls /sys/class/backlight
cat /sys/class/backlight/*/{brightness,actual_brightness,max_brightness,bl_power}
cat /sys/kernel/debug/pwm

示波器确认频率、duty和极性比只看sysfs更可靠。

12. 可靠性

PWM频率过低会闪烁，过高可能超出controller/背光芯片能力。Brightness曲线应按光学感知校准，而不是简单线性假设。

Aperture 与固件帧缓冲移交

1. 问题

Boot firmware可能建立simplefb/efifb并占用一段显存。真实GPU driver加载后必须接管同一PCI BAR或physical aperture，否则两个driver会同时写硬件。

2. Aperture Range

Aperture helper记录graphics device占用的physical range和回调。冲突判断基于区间重叠。

3. 注册

Firmware framebuffer在注册时登记aperture。Native graphics driver probe时调用remove conflicting helpers。

4. 接管

1
2
3
4
5
6
7

native DRM/GPU probe
 -> determine BAR/VRAM range
 -> aperture_remove_conflicting_devices()
 -> invoke firmware fb detach
 -> unregister fbdev
 -> unmap old aperture
 -> initialize native hardware

PCI driver可按BAR移除冲突。

5. 为什么必须移除

不移除可能出现：

• 双driver竞争寄存器；
• fbcon继续向旧mapping写；
• memory ownership冲突；
• suspend/resume恢复错误driver；
• UAF或黑屏。

6. nomodeset

nomodeset通常禁止native DRM modesetting，让firmware framebuffer继续工作。它适合救援，不代表完整显示能力，可能没有热插拔、加速和多显示器。

7. simplefb

simplefb只使用firmware给定的地址、尺寸、stride和format，不负责重新编程display controller。

因此：

• firmware必须保持scanout配置；
• mode固定；
• clock/power handoff必须稳定；
• native driver加载后应移除它。

8. DRM fbdev emulation

Native DRM接管后可以再创建新的fbdev兼容节点。用户看到fb0名称/设备可能变化，但底层ownership已切换。

9. RK3588

本树rk3588* DTS没有simple-framebuffer或efi-framebuffer节点，正常产品由Rockchip DRM/VOP2完成显示。Vendor boot logo主要通过route-*、drm-logo reserved memory和rockchip_drm_logo.c接管，不是simplefb aperture handoff。

因此本篇aperture机制对RK3588主要是通用框架知识；只有产品另外引入system framebuffer节点时才成为实际启动路径。

10. 生命周期

Remove callback必须先让fbcon和userspace停止访问，再unmap/release aperture。不能只从列表删除而保留可访问fb_info。

11. 调试

检查：

• boot log中simple-framebuffer和DRM probe顺序；
• /proc/iomem显存范围；
• /proc/fb名称变化；
• aperture conflict日志；
• nomodeset；
• boot logo消失到KMS首帧之间的时延。

12. 安全

Firmware给出的address/size属于不可信平台描述边界。Driver需防止区间overflow并避免映射系统RAM或其它设备MMIO。

FBDev 硬件驱动分类与现代 DRM 边界

1. 驱动分类

fbdev/包括：

• 旧PCI显卡：ATI、NVIDIA、Matrox、S3、SiS、VIA等；
• 各架构工作站framebuffer；
• 旧SoC LCDC；
• USB/虚拟化framebuffer；
• firmware framebuffer；
• virtual/test framebuffer；
• Core和software rendering helpers。

2. Legacy PCI驱动

这些driver直接：

• probe PCI；
• map BAR；
• 初始化PLL/CRTC；
• 管理VRAM；
• 注册fb_info。

它们与同硬件的DRM driver互斥，不能同时启用。

3. SoC LCDC

旧平台fb driver通常把controller、DMA framebuffer、panel timing和backlight耦合在一个driver。现代设计拆成DRM CRTC/plane/encoder/bridge/panel。

4. Firmware类

• efifb：EFI GOP framebuffer；
• vesafb/uvesafb：VESA；
• offb：Open Firmware；
• simplefb：DT simple-framebuffer。

它们主要维持已有scanout。

5. Virtual/Test

vfb提供system-memory虚拟framebuffer，可测试fbcon和应用；不是显示硬件。Hyper-V/Xen等frontend与host/backend通信。

6. Drawing Helper

错误选择可能造成cache、endianness或访问语义问题。

7. DRM替代

DRM提供：

• atomic modeset；
• planes/connectors/bridges；
• buffer objects；
• dma-buf；
• vblank/fence；
• render/display权限模型。

fbdev仅有全局screen buffer和有限mode ABI，不适合现代多plane/多display合成。

8. DRM fbdev emulation

DRM client在KMS之上分配buffer并构造fb_info：

1

/dev/fb0 -> fbdev Core -> DRM fb helper -> GEM/atomic KMS

该路径保留fbcon和legacy应用，不等于回退到legacy硬件driver。

9. RK3588

RK3588无本目录专用VOP fbdev driver。VOP2是DRM driver。本树RK3588 DTS没有simplefb/efifb节点；Vendor boot logo由Rockchip DRM的logo保留内存路径接管。只有产品自行增加firmware framebuffer描述时，simplefb才可能承担早期/救援显示。

10. 配置建议

启用：

• Rockchip DRM；
• 所需bridge/panel/PHY；
• backlight；
• 如需要console，再启用DRM fbdev emulation、FB和fbcon。

通常关闭不相关legacy fb drivers以减小攻击面和镜像。

11. 不能只按文件大小裁剪

Kconfig可能被其它架构select；构建时应基于目标.config验证对象，而不是删除源码目录。

12. 识别当前路径

1
2
3
4

cat /proc/fb
cat /sys/class/graphics/fb0/name
ls /sys/class/drm
dmesg | grep -Ei 'drm|fb0|framebuffer|simplefb'

名称若为DRM framebuffer，则底层不是legacy fb driver。

Rockchip Video 扩展目录总览

1. 性质

drivers/video/rockchip是vendor SDK集合，不是上游统一video framework。其模块有各自字符设备、ioctl、job和硬件资源。

2. 子目录

3. 构建

顶层虽obj-y += rockchip/，各子目录仅在对应CONFIG_*启用时链接。

4. 共同架构

多数加速模块采用：

1
2
3
4
5
6
7
8
9
10

userspace ioctl
 -> session/context
 -> import dma-buf/user buffer
 -> validate request/registers
 -> create job/task
 -> scheduler/policy
 -> map IOMMU
 -> program registers
 -> IRQ completion
 -> fence/wakeup

5. 共同硬件资源

• platform device/OF match；
• MMIO；
• IRQ；
• clocks；
• reset；
• regulator/power domain；
• IOMMU；
• devfreq/OPP；
• dma-buf。

6. ABI

Vendor ABI常由UAPI头、private ioctl和配套librga/mpp userspace定义。升级kernel时需同时核对userspace library版本。

7. RGA

RGA执行blit、scale、rotate、format conversion、blend、fill。RK3588通常采用Multi-RGA驱动统一调度不同核心。

8. MPP

MPP为多个decoder/encoder硬件提供service、session、task、register translation和reset。它与上游V4L2 mem2mem接口不是同一ABI。

9. IEP/RVE

IEP负责deinterlace、scale、format等图像增强；RVE是另一个vendor图像/矢量加速模块，具体能力按硬件表和UAPI。

10. DVBM/Vtunnel

用于producer-consumer间buffer路径或低延迟视频传递，需与dma-buf/fence及设备生命周期协同。

11. Vehicle

把摄像头decoder/CIF、buffer和VOP direct-show串成快速倒车链路，目标是在完整Android图形栈未就绪时尽快显示。

12. RK3588默认

Vendor defconfig明确启用Multi-RGA、IEP和MPP，并启用RKVDEC/RKVDEC2、RKVENC/RKVENC2、VDPU/VEPU、JPEG、AV1等backend。

13. 目录边界

这些模块通常生成处理结果buffer，不负责VOP scanout mode。最终显示仍由DRM/HWC完成，除vehicle direct-show等专用路径。

14. 风险

高风险输入包括用户寄存器数组、尺寸/stride/offset、dma-buf fd、job依赖、timeout。必须执行白名单、overflow、buffer bounds和IOMMU检查。

RGA 多核 2D 加速架构

1. 功能

RGA执行：

• copy/blit；
• crop和scale；
• rotate/mirror；
• colorspace/format conversion；
• alpha blend；
• fill/palette等。

2. 三代目录

• rga/：旧RGA；
• rga2/：RGA2；
• rga3/：Multi-RGA，统一管理多类核心。

RK3588 vendor defconfig启用ROCKCHIP_MULTI_RGA。

3. RGA3对象划分

4. 用户入口

RGA3注册misc device，rga_ioctl处理同步、异步、import/release和版本/能力等命令。Compat当前复用同一handler，因此UAPI结构必须保持32/64位布局可兼容。

5. 数据路径

1
2
3
4
5
6
7
8
9
10
11
12
13

request
 -> copy_from_user
 -> validate image/rect/format
 -> resolve handles/fds
 -> map source/destination buffers
 -> choose capable core
 -> build register command
 -> queue job
 -> runtime PM/clock on
 -> start hardware
 -> IRQ
 -> signal fence/wakeup
 -> unmap/release

6. Buffer

支持dma-buf等来源。每个plane都要验证：

• width/height；
• stride；
• format plane count；
• offset；
• required bytes；
• chroma alignment；
• address width；
• read/write direction。

7. 多核策略

Policy根据格式、尺寸、scale比例、功能和core忙闲选择硬件。不是所有RGA core支持同一操作。

8. Async

ROCKCHIP_RGA_ASYNC依赖sync_file。Input fences表示producer完成；output fence在RGA完成后signal。

同步请求等待job completion；等待超时后不能立即释放仍被硬件访问的buffer。

9. IOMMU

IOMMU把scatter-gather dma-buf映射到设备地址。Fault通常来自offset/size错误、提前unmap、设备地址位宽或IOMMU domain问题。

10. Reset

Timeout/error需：

1
2
3
4
5
6

stop queue
 -> dump state
 -> reset core
 -> fail active job/fence
 -> restore clocks/register context
 -> resume pending jobs

11. 性能

关键瓶颈常是DDR带宽而非计算。避免无意义格式转换、重复scale和cache bounce；批量提交可降低ioctl/PM开销。

12. 安全

Vendor ioctl直接驱动DMA硬件，必须防：

• integer overflow导致buffer越界；
• 任意寄存器写；
• fence cycle/deadlock；
• job队列DoS；
• IOMMU fault storm；
• secure/non-secure buffer混用。

13. 调试

可选procfs/debugfs由ROCKCHIP_RGA_DEBUGGER构建。结合job/core状态、IRQ、IOMMU fault、clock和fence timeline定位。

MPP 视频编解码服务框架

1. 组成

rk_vcodec.o基础对象：

• mpp_service.o：服务和字符设备；
• mpp_common.o：session/task/ioctl/queue；
• mpp_iommu.o：buffer映射。

Codec backend按Kconfig链接。

2. Backend

本树支持：

• RKVDEC/RKVDEC2；
• RKVENC/RKVENC2；
• VDPU1/VDPU2；
• VEPU1/VEPU2；
• IEP2；
• JPEG decoder/encoder；
• AV1 decoder；
• VDPP。

3. 设备入口

Service分配字符设备号、class和device。具体hardware device使用mpp_dev_ioctl，open创建session并与backend绑定。

4. 会话

Session隔离每个用户context：

• pending/running task；
• imported buffers；
• register offsets；
• codec type；
• wait状态；
• cleanup。

它是软件隔离，不代替IOMMU和输入验证。

5. Task

1
2
3
4
5
6
7
8
9
10
11

ioctl request
 -> parse message/register data
 -> allocate task
 -> translate offsets/buffers
 -> enqueue
 -> scheduler chooses device
 -> power on
 -> program registers
 -> IRQ finish
 -> readback result
 -> wake session

6. Register Translation

Userspace通常提交硬件寄存器参数。Backend必须只接受允许的register范围，并把buffer fd/offset转换为IOVA，不能允许任意physical address。

7. IOMMU

mpp_iommu.c负责attach/map/unmap和fault相关处理。Mapping lifetime至少覆盖硬件task；session close时先cancel/drain task再释放。

8. IRQ

Top-half应快速读取/清除status并标记结果；耗时完成处理放到thread/work/tasklet。Spurious IRQ和stale completion需通过active task状态判断。

9. Timeout和Reset

Codec可能因bitstream、寄存器、IOMMU或硬件问题hang。Timeout worker需reset硬件，并把当前task返回错误，不能让等待者永久阻塞。

10. PM

每个task开始前runtime-resume clock/power，完成后autosuspend。频率可能通过devfreq/OPP调整。

11. RK3588

rockchip_linux_defconfig启用了MPP service和RKVDEC2/RKVENC2/AV1等多backend。是否真正probe取决于最终DTS中对应codec节点、IOMMU、clock/reset和status。

12. 与V4L2的区别

MPP是Rockchip vendor ABI；上游codec通常使用V4L2 mem2mem/stateless API。用户库不能互换，容器镜像必须匹配目标kernel ABI。

13. 性能

• 减少buffer copy，使用dma-buf；
• 批量/链式task；
• 避免频繁power cycle；
• 正确配置IOMMU和DDR QoS；
• decoder/encoder并行时考虑共享带宽。

14. 安全

压缩bitstream和用户register均不可信。重点审计长度/offset乘法、register白名单、session close、timeout reset、IOMMU fault和信息泄露。

15. 调试

查看device node、MPP版本、procfs状态、session/task队列、IRQ计数、reset、IOMMU faults、clock以及userspace mpp库日志。

IEP、RVE、DVBM 与视频隧道

1. IEP

iep.o由：

• iep_drv.o；
• hw_iep_reg.o；
• iep_iommu_ops.o；
• DRM启用时的iep_iommu_drm.o

组成。

IEP提供图像增强/处理，注册misc device，通过ioctl提交图像参数和buffer。

2. IEP数据路径

1
2
3
4
5
6
7
8
9

open
 -> session/private data
 -> ioctl configure source/destination
 -> map buffers through IOMMU
 -> build registers
 -> power/clock on
 -> run
 -> IRQ/wait
 -> unmap

3. IEP与IEP2

旧IEP位于独立iep/；IEP2作为MPP backend由ROCKCHIP_MPP_IEP2构建。二者ABI和调度路径不同，不应仅按名称混用。

4. RVE

RVE目录包含：

• driver/ioctl；
• job；
• register conversion；
• fence；
• debugger。

它同样注册misc device，异步路径需维护input/output fence和job lifetime。

5. DVBM

Direct Video Buffer Manager用于视频producer/consumer间buffer状态协调。它不负责codec或scanout本身，而是减少复制并管理直接视频路径。

关键问题：

• producer不能覆盖consumer仍在用的buffer；
• generation/sequence避免ABA；
• disconnect后唤醒所有waiter；
• timeout不能留下永久占用slot。

6. Video Tunnel

rkvtunnel.c注册misc device，提供open/release/ioctl/compat ioctl。Tunnel建立producer/consumer及buffer传递关系。

7. Tunnel生命周期

1
2
3
4
5
6
7

create/connect
 -> allocate/import buffers
 -> producer queues frame
 -> consumer acquires
 -> consumer releases
 -> disconnect
 -> drain/wakeup/free

进程异常退出必须触发disconnect cleanup。

8. dma-buf与Fence

零拷贝并不意味着无同步：

• dma-buf解决共享；
• IOMMU解决device address；
• fence解决完成顺序；
• cache maintenance解决CPU/device一致性；
• ownership protocol解决谁能写。

9. 配置

• IEP；
• ROCKCHIP_RVE及可选proc/debugfs；
• ROCKCHIP_DVBM；
• ROCKCHIP_VIDEO_TUNNEL，默认n。

10. RK3588

Vendor defconfig明确启用IEP；RVE/DVBM/tunnel需以产品最终.config为准。节点存在但status disabled时不会probe。

11. 错误处理

硬件timeout必须fail fence并回收映射；tunnel disconnect必须使阻塞ioctl返回；IOMMU fault后不能继续复用已损坏task。

12. 安全

• 对fd/handle建立每session ownership；
• 禁止猜测别人的buffer ID；
• 校验plane边界；
• 限制队列深度；
• 防止close与IRQ double free；
• debugfs/procfs不要暴露地址和敏感帧信息；
• secure video buffer不得映射到普通CPU/userspace路径。

13. 调试

按“节点→session→buffer→fence→job→IRQ→IOMMU→clock/reset”顺序定位。只看到ioctl timeout时不要直接归因于codec，可能是consumer未release或fence未signal。

Vehicle 快速倒车影像链路

1. 目标

vehicle/为Rockchip vendor快速倒车影像方案，目标是在Android Camera/HWC完整启动前，以较短延迟显示后摄画面。

2. 构建依赖

VIDEO_REVERSE_IMAGE依赖：

• ARCH_ROCKCHIP；
• ROCKCHIP_DRM_DIRECT_SHOW；
• VIDEO_ROCKCHIP_CIF；
• PHY_ROCKCHIP_CSI2_DPHY。

因此它横跨camera capture和DRM direct display。

3. 组成

4. 数据路径

1
2
3
4
5
6
7
8

reverse GPIO/event
 -> power sensor/decoder
 -> configure CIF/CSI
 -> allocate capture buffers
 -> start frame capture
 -> vehicle flinger
 -> DRM direct-show/VOP
 -> display

5. 支持源

Kconfig可选TP2815、TP2855、NVP6324、NVP6188、MAX96714、GC2145和AD7181。实际I2C地址、video format和lane来自板级DTS/配置。

6. Buffer

Capture DMA与VOP scanout必须共享可访问buffer，并保证：

• stride/format一致；
• producer完成后再scanout；
• VOP释放后才复用；
• IOMMU domains/physical地址可达；
• cache属性正确。

7. 与标准栈关系

它是专用低延迟旁路，不等同于标准V4L2→userspace→DRM pipeline。优点是快，代价是跨子系统耦合和vendor ABI。

8. 状态机

至少区分：

• inactive；
• starting；
• streaming；
• stopping；
• error。

倒车信号抖动时必须去抖，start/stop不能并发重复执行。

9. 显示ownership

Direct show可能与正常HWC/DRM atomic commit争用VOP plane。必须明确：

• 哪个plane保留；
• 进入倒车时如何抢占；
• 退出时如何恢复；
• suspend/hotplug怎么办。

10. 错误恢复

• sensor无锁：显示安全提示/黑帧；
• CIF timeout：stop/reset/restart；
• buffer错误：禁止scanout损坏地址；
• DRM被卸载：停止capture；
• GPIO频繁变化：serialize work。

11. 安全

倒车画面属于安全相关功能。应有：

• 启动deadline和故障监测；
• stale frame检测；
• 明确fail-safe；
• userspace不能任意注入buffer；
• watchdog/health counters；
• production关闭过度debug。

12. RK3588配置

本树rk3588_vehicle.config明确写有# CONFIG_VIDEO_REVERSE_IMAGE is not set，说明“vehicle源码存在”不能推断该fragment启用；应以最终合并.config和具体车载DTS为准。

13. 调试顺序

倒车GPIO→decoder I2C/lock→CSI DPHY→CIF IRQ/frame counter→buffer address/fence→DRM direct-show→VOP route→panel/backlight。

RK3588 显示拓扑与 DRM 集成

1. 关键结论

RK3588主显示controller不是drivers/video/fbdev驱动，而是Rockchip DRM中的VOP2路径。drivers/video直接参与的是backlight、fbdev兼容、timing helper及vendor媒体模块。

2. DTS顶层

rk3588s.dtsi定义：

• display-subsystem；
• vop@fdd90000；
• VOP output ports；
• route-dp0/dsi0/dsi1/edp0/edp1/hdmi0/rgb等route；
• VOP IOMMU；
• clocks/resets/power domain/OPP/QoS。

3. Scanout拓扑

1
2
3
4
5
6
7
8

GEM/dma-buf
 -> VOP2 plane/window
 -> video port
 -> endpoint route
 -> encoder/bridge
 -> HDMI / DP / eDP / MIPI-DSI / RGB
 -> panel
 -> backlight

每条链路依赖DT graph两端endpoint互相连接。

4. VOP2

VOP2负责planes、blend、CRTC/video ports、timing和scanout。其driver主要在drivers/gpu/drm/rockchip，不要在drivers/video/rockchip查找。

5. 输出

• HDMI：controller、PHY、HPD、DDC/EDID；
• DP/eDP：link training、AUX、panel/bridge；
• DSI：host、PHY、panel；
• RGB/LVDS：可能经bridge/PHY；
• Backlight：常由本目录pwm_bl.c提供class device。

6. Route

SoC dtsi给出所有可能route，板级dts决定：

• endpoint连接；
• status；
  -默认logo/route；
• panel/bridge；
• regulator/GPIO/backlight。

仅有SoC节点不等于板上输出已启用。

7. IOMMU

VOP IOMMU保护scanout DMA并允许non-contiguous GEM buffer。Boot framebuffer handoff时需处理firmware physical buffer与native IOMMU地址切换。

8. RGA/MPP关系

RGA或MPP输出dma-buf，HWC/DRM再把buffer放到VOP plane。它们是producer/processor，不是connector或CRTC。

9. Backlight实例

本树RK3588 tablet、EVB和vehicle dtsi包含大量pwm-backlight节点。最终有效性取决于：

• PWM controller status/pinctrl；
• power-supply；
• enable GPIO；
• brightness table；
• panel phandle。

10. 配置

Vendor defconfig启用：

• DRM_ROCKCHIP=y；
• BACKLIGHT_CLASS_DEVICE=y；
• BACKLIGHT_PWM=y；
• Multi-RGA；
• IEP；
• MPP及多数RK3588 codec。

FB/fbcon未在该defconfig中显式列出，应检查最终Kconfig结果和产品fragment，不能宣称必然启用。

基线Kconfig中DRM_FBDEV_EMULATION默认开启，并可进一步带入framebuffer console；因此普通Rockchip Linux构建通常会得到DRM模拟的/dev/fb0。产品fragment仍可覆盖，例如NVR配置明确关闭fbdev emulation。

11. 启动链

1
2
3
4
5
6
7
8

U-Boot/VOP logo buffer
 -> drm-logo reserved memory与route接管
 -> Rockchip DRM component bind
 -> VOP/output probe
 -> atomic modeset
 -> panel/backlight enable
 -> optional DRM fbdev emulation/fbcon
 -> userspace compositor

该Vendor路径不依赖simplefb/efifb；本树RK3588 DTS也没有相应节点。

12. 常见故障

13. 运行核对

1
2
3
4
5

ls /sys/class/drm
cat /sys/kernel/debug/dri/0/state
cat /sys/kernel/debug/clk/clk_summary
cat /sys/kernel/debug/pwm
dmesg | grep -Ei 'rockchip|vop|drm|hdmi|edp|dsi|iommu'

14. 产品建议

以DRM为单一显示ownership；仅在确有需求时启用fbdev emulation。保留实际使用的output、panel、backlight和媒体backend，关闭不相关legacy fbdev及vendor debug接口。