rk drm系统分为两个部分:
display-subsystem
,包括mode、timing相关的驱动ip driver
,包括vop+hdmi,dp,dsi等tx模块
使用了component
技术架构来管理复杂的多ip probe的同步问题;
从程序宏观主线上分析:
rockchip_drm_init( ): (start_entry){
add_rk_Sub_driver(hdmi/dp/dsi/vop)
platform_register_drivers( xxx_sub_drivers),xxx are dw-dp, dw-hdmi, dsi …
//这个过程触发xxx-probe函数,并完成xxx-component-add,注册了xxx-bind函数
platform_driver_register(&rockchip_drm_platform_driver);
}
//这个是display-subsystem驱动注册,并注册comp-master,初始化aggregate-dev
rockchip_drm_platform_driver(){
rockchip_drm_platform_probe( ): “display_subsystem” probe, get dts parameters
→ component_match_add( ), add xxx component, try to bringup aggregate-device
→ component_master_add( ), add master-comp ops, try to bringup adev
==> master-comp.ops.bind() = rockchip_drm_bind( ):
==> component_bind_all( )
==> drm_general_init(): alloc drm_dev, mode_config, gem, sysfs, debugfs …
}
核心全局数据结构,
drm_device, 全局唯一的当前显示设备,管理所有有关的组件
component_list, 每个组件probe时都以component挂载在list上,积木块
aggregate-device, 最终的component-master设备,积木作品
其他组件:hdmi-bind,dw-dp-bind,dsi2-bind,…
例如,hdmi-bind:
初始化hdmi硬件,
初始化hdmi drm数据结构,encoder
找到dts里面link的crtc,并attach到encoder,
如果有bridge可以attach bridge,
hdmi-drm component就初始化完成了:
VOP2 CRTC -> Planes -> Layers -> encoder (HDMI/MIPI/etc) - connector
“display_subsystem” probe 的dts图:主要是vop节点,vop节点再通过remote-ep链接encoder-hdmi/dp
Component Linux 内核中的 Component 框架机制
Component 框架是 Linux 内核中用于管理复杂设备组件间绑定的机制,特别适用于 DRM (Direct Rendering Manager) 等需要多个独立驱动协同工作的子系统。
ref link: https://www.cnblogs.com/zyly/p/17678424.html
核心设计目的
解决复杂设备的模块化问题:例如 SoC 显示子系统可能由多个独立 IP 核组成
支持延迟绑定:允许组件按任意顺序加载和初始化
简化驱动依赖关系:避免硬编码的设备依赖
典型使用场景(以DRM为例)
显示控制器驱动 (Master):
定义 component_master_ops
注册 master 组件
显示接口驱动 (Component):
定义 component_ops
调用 component_add() 注册自己
典型应用场景
Rockchip DRM驱动:
VOP (CRTC) 作为master
HDMI/DP/MIPI 驱动作为components
复杂音频子系统:
编解码器作为master
各种音频接口作为components
Component框架通过这种松耦合的设计,使得Linux内核能够更好地支持现代SoC中复杂的硬件模块化架构,特别是在显示、音频等需要多组件协同工作的子系统中表现出色。