当前位置：网站首页>LCD DRM驱动框架分析二
LCD DRM驱动框架分析二
2022-08-10 09:36:00 【沉沦者】
本文是基于rk3566 / rk3568平台从LCD代码层面上对LCD DRM框架进行分析。
一、uboot阶段
1、涉及的驱动文件
2、uboot代码流程分析
2.1）各probe函数的加载
2.1.1)各bind函数是在设备和驱动匹配时（uboot启动阶段）加载的。
2.1.2）各probe函数是在rockchip_display_probe中解析设备树时，通过uclass_get_device_by_xxx（uclass_get_device_by_ofnode/uclass_get_device_by_phandle）系列函数加载的
->rockchip_display_bind
->rockchip_vop_bind
->dw_mipi_dsi_bind
->rockchip_display_probe
->uclass_get_device_by_ofnode(UCLASS_VIDEO_CRTC, np_to_ofnode(vop_node), &crtc_dev)
->rockchip_vop_probe
->rockchip_of_find_connector
->uclass_get_device_by_ofnode(UCLASS_DISPLAY, conn, &dev)
->dw_mipi_dsi_probe
->rockchip_of_find_phy
->uclass_get_device_by_phandle(UCLASS_PHY, dev, "phys", &phy_dev)
->inno_video_phy_probe
->rockchip_of_find_bridge
->uclass_get_device_by_ofnode(UCLASS_VIDEO_BRIDGE, node, &dev)
->rockchip_of_find_panel
->uclass_get_device_by_ofnode(UCLASS_PANEL, panel_node, &panel_dev)
->rockchip_panel_probe2.2）开机后uboot阶段LCD的初始化流程
2.2.1）rockchip_show_logo 为显示 U-Boot logo 和 kernel logo。
2.2.2）load_bmp_logo加载logo数据，其中包括查找logo数据（find_or_alloc_logo_cache）和获取显示的缓存buffer（get_display_buffer)
2.2.3）display_logo显示进行logo的显示（传参为logo图像数据）
board_late_init
->rockchip_show_logo
->load_bmp_logo
->find_or_alloc_logo_cache
->rockchip_read_resource_file
->get_display_buffer
->display_logo2.2.4）display_init函数为各模块进行初始化其中包括：
2.2.4.1）panel_matching进行屏匹配过程，主要是先对各模块上电达到链路为通的状态，接着通过读取硬件panel_id 来决定使用相应的dtsi文件，从而在后续使用匹配的dtsi文件（有效的面板数据）对屏进行初始化、操作时序等。
2.2.4.2）display_set_plane设置图层
2.2.4.3）display_enable重新上电、各模块使能、亮背光等操作。
->board_late_init
->rockchip_show_logo
->display_logo
->display_init
->panel_matching
->conn_funcs->init(state)
->rockchip_panel_init
->rockchip_panel_getId
->panel->funcs->getId(panel)=rockchip_dsi_panel_getId //读取实际panel id和dtsi文件的id进行比较
->mipi_dsi_dcs_read
->conn_funcs->disable(state)
->conn_funcs->unprepare(state)
->crtc_funcs->preinit(state)
->rockchip_panel_init
->conn_funcs->init(state)
->rockchip_phy_init
->crtc_funcs->init
->display_set_plane
->crtc_funcs->set_plane(state)=rockchip_vop_set_plane
->display_enable
->crtc_funcs->prepare(state)=rockchip_vop_prepare
->conn_funcs->prepare(state)=dw_mipi_dsi_connector_prepare
->rockchip_bridge_pre_enable(conn_state->bridge)
->rockchip_panel_prepare(panel_state->panel)=panel_simple_prepare
->crtc_funcs->enable(state)=rockchip_vop_enable
->conn_funcs->enable(state)=dw_mipi_dsi_connector_enable
->rockchip_bridge_enable(conn_state->bridge)
->rockchip_panel_enable(panel_state->panel)=panel_simple_enable二、kernel 阶段
1、涉及的驱动文件
2、内核LCD驱动加载流程
3、LCD驱动加载具体分析
通过各模块probe函数和bind函数的执行来实现各模块的初始化，如下：
rockchip_drm_init
->vop2_probe
->dw_hdmi_rockchip_probe
->dw_mipi_dsi_probe
->rockchip_drm_platform_probe
->rockchip_drm_bind
->rockchip_drm_mode_config_init
->component_bind_all
->show_loader_logo
->rockchip_drm_fbdev_init
->drm_fb_helper_prepare
->drm_dev_register
->vop2_bind
->vop2_win_init
->vop2_create_crtc
->vop2_plane_init
->drm_crtc_init_with_planes
->drm_crtc_helper_add
->rockchip_register_crtc_funcs
->dw_hdmi_rockchip_bind
->dw_mipi_dsi_bind
->drm_encoder_init
->drm_encoder_helper_add
->drm_connector_init
->drm_connector_helper_add
->panel_simple_dsi_probe
->panel_simple_probe
->drm_panel_init注：
drm_device用于抽象一个完整的DRM设备，而其中与Mode Setting相关的部分则由drm_mode_config进行管理。为了让一个drm_device支持KMS相关的API，DRM框架要求驱动：
1）注册drm_driver时，driver_features标志位中需要存在DRIVER_MODESET。
2）在probe函数中调用drm_mode_config_init函数初始化KMS框架，本质上是初始化drm_device中的mode_config结构体。
3）填充mode_config中int min_width, min_height; int max_width, max_height的值，这些值是framebuffer的大小限制。
4）设置mode_config->funcs指针，本质上是一组由驱动实现的回调函数，涵盖KMS中一些相当基本的操作。
5）最后初始化drm_device中包含的drm_connector，drm_crtc等对象.
4、DRM helper架构
基本思想是通过一组回调函数抽象特定组件的操作，比如drm_connector_funcs，同时又使用另外一组helper函数给出了原先那组回调函数的通用实现，让开发最者实现这组helper函数抽象出的回调函数即可。可以保证开发者有足够高的自由度（完全不用helper函数），也能简化开发者的开发（使用helper函数），同时提供给开发者hook特定helper函数的能力。以drm_connector为例说明helper架构的实现方式与使用方式。
正常情况下，创建drm_connector对象时需要提供struct drm_connector_funcs回调函数组，而使用helper函数时，可以直接用helper函数填充对应回调函数：
static const struct drm_connector_funcs dw_mipi_dsi_atomic_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = dw_mipi_dsi_drm_connector_destroy,
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_get_property = dw_mipi_dsi_atomic_connector_get_property,
};事实上helper函数并不万能，只是抽象出了大多数驱动程序应该共享的行为，而特定于硬件的部分，则需要以回调函数的形式提供给helper函数，这个回调函数组由struct drm_connector_helper_funcs提供。在创建drm_connector时，需要通过drm_connector_helper_add函数注册。函数将对应的回调函数对象的地址保存在了drm_connector中的helper_private指针中，如下：
drm_connector_helper_add(connector, &dw_mipi_dsi_connector_helper_funcs);
static inline void drm_connector_helper_add(struct drm_connector *connector,
const struct drm_connector_helper_funcs *funcs)
{
connector->helper_private = funcs;
}
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
};5、用户态和内核态间的交互
驱动会注册一个支持KMS的DRM设备时，会在/dev/drm/下创建一个card%d文件，用户态可以通过打开该文件，并对文件描述符做相应的操作实现相应的功能。该文件描述符对应的文件操作回调函数（filesystem_operations）位于drm_driver中，并由驱动程序填充。典型如下：
static const struct file_operations rockchip_drm_driver_fops = {
.owner = THIS_MODULE,
.open = drm_open,
.mmap = rockchip_gem_mmap,
.poll = drm_poll,
.read = drm_read,
.unlocked_ioctl = drm_ioctl,
.compat_ioctl = drm_compat_ioctl,
.release = drm_release,
};
long drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev;
const struct drm_ioctl_desc *ioctl = NULL;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
int retcode = -EINVAL;
char stack_kdata[128];
char *kdata = NULL;
unsigned int in_size, out_size, drv_size, ksize;
bool is_driver_ioctl;
dev = file_priv->minor->dev;
if (drm_dev_is_unplugged(dev))
return -ENODEV;
is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
if (is_driver_ioctl) {
/* driver ioctl */
unsigned int index = nr - DRM_COMMAND_BASE;
if (index >= dev->driver->num_ioctls)
goto err_i1;
index = array_index_nospec(index, dev->driver->num_ioctls);
ioctl = &dev->driver->ioctls[index];
} else {
/* core ioctl */
if (nr >= DRM_CORE_IOCTL_COUNT)
goto err_i1;
nr = array_index_nospec(nr, DRM_CORE_IOCTL_COUNT);
ioctl = &drm_ioctls[nr];
}
drv_size = _IOC_SIZE(ioctl->cmd);
out_size = in_size = _IOC_SIZE(cmd);
if ((cmd & ioctl->cmd & IOC_IN) == 0)
in_size = 0;
if ((cmd & ioctl->cmd & IOC_OUT) == 0)
out_size = 0;
ksize = max(max(in_size, out_size), drv_size);
DRM_DEBUG("pid=%d, dev=0x%lx, auth=%d, %s\n",
task_pid_nr(current),
(long)old_encode_dev(file_priv->minor->kdev->devt),
file_priv->authenticated, ioctl->name);
/* Do not trust userspace, use our own definition */
func = ioctl->func;
if (unlikely(!func)) {
DRM_DEBUG("no function\n");
retcode = -EINVAL;
goto err_i1;
}
if (ksize <= sizeof(stack_kdata)) {
kdata = stack_kdata;
} else {
kdata = kmalloc(ksize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (copy_from_user(kdata, (void __user *)arg, in_size) != 0) {
retcode = -EFAULT;
goto err_i1;
}
if (ksize > in_size)
memset(kdata + in_size, 0, ksize - in_size);
retcode = drm_ioctl_kernel(filp, func, kdata, ioctl->flags);
if (copy_to_user((void __user *)arg, kdata, out_size) != 0)
retcode = -EFAULT;
err_i1:
if (!ioctl)
DRM_DEBUG("invalid ioctl: pid=%d, dev=0x%lx, auth=%d, cmd=0x%02x, nr=0x%02x\n",
task_pid_nr(current),
(long)old_encode_dev(file_priv->minor->kdev->devt),
file_priv->authenticated, cmd, nr);
if (kdata != stack_kdata)
kfree(kdata);
if (retcode)
DRM_DEBUG("pid=%d, ret = %d\n", task_pid_nr(current), retcode);
return retcode;
}通过访问drmModeSetCrtc相关的legacy接口，从而调用到了drm_ioctl_kernel - > IOCTL上：
return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETCRTC, &crtc);而所有与drm相关的定义都在drivers/gpu/drm/drm_ioctl.c中：
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, DRM_MASTER),即最终处理函数是drm_mode_setcrtc。函数首先检查DRM设备的feature：
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;最终调用的就是drm_crtc_funcs->set_config回调函数，也就是drm_atomic_helper_set_config函数：
if (drm_drv_uses_atomic_modeset(dev))
ret = crtc->funcs->set_config(&set, &ctx);
else
ret = __drm_mode_set_config_internal(&set, &ctx);struct drm_crtc_funcs结构体：
static const struct drm_crtc_funcs vop2_crtc_funcs =
{
.gamma_set = vop2_crtc_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.destroy = vop2_crtc_destroy,
.reset = vop2_crtc_reset,
.atomic_get_property = vop2_crtc_atomic_get_property,
.atomic_set_property = vop2_crtc_atomic_set_property,
.atomic_duplicate_state = vop2_crtc_duplicate_state,
.atomic_destroy_state = vop2_crtc_destroy_state,
.enable_vblank = vop2_crtc_enable_vblank,
.disable_vblank = vop2_crtc_disable_vblank,
.set_crc_source = vop2_crtc_set_crc_source,
.verify_crc_source = vop2_crtc_verify_crc_source,
};drm_atomic_helper_set_config实现：
int drm_atomic_helper_set_config(struct drm_mode_set *set,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_atomic_state *state;
struct drm_crtc *crtc = set->crtc;
int ret = 0;
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
return -ENOMEM;
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
goto fail;
ret = handle_conflicting_encoders(state, true);
if (ret)
goto fail;
ret = drm_atomic_commit(state);
fail:
drm_atomic_state_put(state);
return ret;
}用户态A-KMS调用的入口函数drmModeAtomicCommit内部使用了不同的IOCTL调用：
ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ATOMIC, &atomic);对应内核态为：
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl, DRM_MASTER),drm_mode_atomic_ioctl实现为：
int drm_mode_atomic_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
//省略无关代码
drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
state->acquire_ctx = &ctx;
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
retry:
copied_objs = 0;
copied_props = 0;
fence_state = NULL;
num_fences = 0;
for (i = 0; i < arg->count_objs; i++) {
uint32_t obj_id, count_props;
struct drm_mode_object *obj;
if (get_user(obj_id, objs_ptr + copied_objs)) {
ret = -EFAULT;
goto out;
}
obj = drm_mode_object_find(dev, file_priv, obj_id, DRM_MODE_OBJECT_ANY);
if (!obj) {
ret = -ENOENT;
goto out;
}
if (!obj->properties) {
drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
if (get_user(count_props, count_props_ptr + copied_objs)) {
drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
copied_objs++;
for (j = 0; j < count_props; j++) {
uint32_t prop_id;
uint64_t prop_value;
struct drm_property *prop;
if (get_user(prop_id, props_ptr + copied_props)) {
drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
prop = drm_mode_obj_find_prop_id(obj, prop_id);
if (!prop) {
drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
if (copy_from_user(&prop_value,
prop_values_ptr + copied_props,
sizeof(prop_value))) {
drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
ret = drm_atomic_set_property(state, obj, prop,
prop_value);
if (ret) {
drm_mode_object_put(obj);
goto out;
}
copied_props++;
}
drm_mode_object_put(obj);
}
ret = prepare_signaling(dev, state, arg, file_priv, &fence_state,
&num_fences);
if (ret)
goto out;
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
} else {
if (unlikely(drm_debug & DRM_UT_STATE))
drm_atomic_print_state(state);
ret = drm_atomic_commit(state);
}
//省略无关代码
return ret;
}
6、Atomic KMS 架构
Atomic Mode Setting（后续简称A-KMS）。该架构会弥补之前API的不足，由于原先的API不支持同时更新整个DRM显示pipeline的状态，因此KMS过程中会出现一些中间状态，容易造成开发者不希望看见的结果，影响用户体验。同时，原先的KMS接口也不支持回滚，需要应用程序自己记录原先的配置状态，Atomic Mode Setting也解决了这个问题。Atomic commit 表示：本次 commit 操作，要么成功，要么保持原来的状态不变。即如果中途操作失败了，那些已经生效的配置需要恢复成之前的状态，就像没发生过 commit 操作似的。而Commit，则是因为本次操作可能会修改到多个参数，等修改好这些参数后，再一次性发起操作请求，有点类似与填表后“提交”材料的意思
Atomic Mode Setting接口在用户态看来，是将原先各个KMS object的状态由隐式的通过API更新，变成了显式的对象属性。用户态程序可以通过通用的属性操作接口读写KMS object上的属性，更改不会立即生效，而是缓存起来。当应用程序更新完其所有想要更新的属性时，可以通过Commit操作告知要求KMS层真正的更新硬件的状态。此时驱动程序需要验证应用程序要求进行的修改是否合法，在合法的情况下，可以一次性完成整个显示状态的修改。A-KMS也实现了只用于检查新状态是否合法的接口。
KMS框架提供了一套helper函数以帮助驱动程序作者实现原先的Legacy KMS接口，本质上，就是原先的legacy相关的接口都通过A-KMS兼容层实现的helper函数实现，实质上就是使用带有drm_atomic_helper前缀的helper函数实现原有的legacy接口。
用户态相关接口：
typedef struct _drmModeAtomicReq drmModeAtomicReq, *drmModeAtomicReqPtr;
extern drmModeAtomicReqPtr drmModeAtomicAlloc(void);
extern drmModeAtomicReqPtr drmModeAtomicDuplicate(drmModeAtomicReqPtr req);
extern int drmModeAtomicMerge(drmModeAtomicReqPtr base,
drmModeAtomicReqPtr augment);
extern void drmModeAtomicFree(drmModeAtomicReqPtr req);
extern int drmModeAtomicGetCursor(drmModeAtomicReqPtr req);
extern void drmModeAtomicSetCursor(drmModeAtomicReqPtr req, int cursor);
extern int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
uint32_t object_id,
uint32_t property_id,
uint64_t value);
extern int drmModeAtomicCommit(int fd,
drmModeAtomicReqPtr req,
uint32_t flags,
void *user_data);用户态接口的本质就是扩展原有的属性接口，允许用户描述一个状态集合，然后通过drmModeAtomicCommit函数进行commit操做。从libdrm的代码中可以看到，commit的操作最后实质上调用了DRM_IOCTL_MODE_ATOMIC的ioctl，这就是Native接口唯一的入口。从内核代码中可以看到，该ioctl的处理函数为drm_mode_atomic_ioctl。以drm_mode_atomic_ioctl为线索，可以发现许多相关的实现。
1）状态对象
A-KMS的核心是整个显示控制器的状态集合，由一个独立的状态对象表示。一个DRM显示pipeline的整体状态由struct drm_atomic_state表示：
struct drm_atomic_state {
struct kref ref;
struct drm_device *dev;
bool allow_modeset : 1;
bool legacy_cursor_update : 1;
bool async_update : 1;
bool duplicated : 1;
struct __drm_planes_state *planes;
struct __drm_crtcs_state *crtcs;
int num_connector;
struct __drm_connnectors_state *connectors;
int num_private_objs;
struct __drm_private_objs_state *private_objs;
struct drm_modeset_acquire_ctx *acquire_ctx;
struct drm_crtc_commit *fake_commit;
struct work_struct commit_work;
};可以看到他由每个独立组件（即drm_mode_object）的状态对象组成。
2）state的创建
drm_atomic_state的创建由drm_atomic_state_alloc实现。函数中可以看到，drm_mode_config_funcs中提供了名为atomic_state_alloc的hook，允许我们自己实现state对象的创建。在默认情况下，函数会调用简单分配内存，然后使用drm_atomic_state_init进行初始化。初始化函数仅仅是简单分配分配drm_atomic_state中几个指针指向的内存区域。
对于各个drm object对应的state，其创建操作由其对应的drm_{object}_funcs->atomic_duplicate_state实现，在驱动程序没有扩展drm_atomic_state的情况下，这个回调函数一般填写为drm_atomic_helper_{object}_duplicate_state。而在commit过程中，是由drm_atomic_get_{object}_state函数触发这个创建操作的。该函数触发复制state操作后，还会将复制后的state及原本的state填入drm_atomic_state中对应的__drm_{object}_state中。
struct __drm_{object}_state {
struct drm_{object} *ptr;
struct drm_{object}_state *state, *old_state, *new_state;
/* extra fields may exist */
};这里的old_state保存drm_{object}现有的state，而state及new_state就保存我们复制后的state。
最后描述一下commit时创建state的简单流程：
2.1）drm_mode_atomic_ioctl函数中会将用户态传入的property更新依次调用drm_atomic_set_property写入前面创建的drm_atomic_state
2.2）drm_atomic_set_property函数会根据传入object的类型调用对应的drm_atomic_get_{object}_state函数，得到对应于该object类型的drm_{object}_state。在这个调用中，如果drm_atomic_mode中对应的__drm_{object}_state不存在，则复制原有的state并填入
2.3）随后drm_atomic_set_property会调用drm_atomic_{object}_set_property将属性更新写入到新的state当中
2.4）最后drm_mode_atomic_ioctl调用对应函数（drm_atomic_commit及其非阻塞版本）进行commit操作（该操作前提是没有设置TEST_ONLY的标志）
3）state更新
state更新由drm_atomic_{object}_set_property函数实现，前面已经分析了整体流程。目前我们看到的state更新是作为一个整体出现的，即通过用户态的commit操作触发。事实上DRM还支持partial update。atomic_duplicate_state和atomic_state_alloc等hook的存在目的是允许驱动程序开发者在原有的state中加入自己的状态，通常情况下用既有helper即可。
4）状态检测 drm_atomic_check_only
由于整个接口是atomic的，这要求实现这套接口的驱动程序能够检测一个特定的显示pipeline（mode）状态是否合法（即能被硬件接受且正确运行）。drm_atomic_check_only函数即为汇总驱动这项功能的的入口。DRM的用户态API提供了DRM_MODE_ATOMIC_TEST_ONLY标志位，其目的是允许用户态直接要求驱动检测配置的合法性而不commit配置。
函数主要操作如下：
4.1）对所有的CRTC，Connector和Plane，分别调用drm_atomic_{crtc,connector,plane}_check对其进行基本的合法性检查，注意这个检查并不涉及驱动实现的回调，完全是DRM框架自己的检查。
4.2）如果mode_config->funcs->atomic_check回调函数存在，则调用其进行检查。注意这个函数一般情况下为drm_atomic_helper_check，或者是驱动自行实现的该函数的wrapper。
4.3）如果state->allow_modeset为false，即要求不进行modeset操作，则对所有的CRTC调用drm_atomic_crtc_needs_modeset函数进行检查。
5）drm_atomic_helper_check
A-KMS的主要操作主要分为两个：
5.1）检查显示mode的合法性，确认硬件确实在该mode下正常工作
5.2）commit操作，将硬件完整的设置成对应的状态
drm_atomic_helper_check就是一般情况下drm_mode_config_funcs->atomic_check内的回调函数。其主要包含两个大的功能点：
5.3）drm_atomic_helper_check_modeset
5.4）drm_atomic_helper_check_planes
前者逐级调用CRTC下面组件的atomic_check回调函数，确认modeset是否合法。
6）commit操作
6.1）drm_crtc_commit
commit操作从感念上来看是基于每一个CRTC的，因此每个commit操作由drm_crtc_commit进行抽象：
struct drm_crtc_commit {
struct drm_crtc *crtc;
struct kref ref;
struct completion flip_done;
struct completion hw_done;
struct completion cleanup_done;
struct list_head commit_entry;
struct drm_pending_vblank_event *event;
bool abort_completion;
};drm_crtc_commit会被放入drm_crtc->commit_list中，且drm_crtc_commit实质上仅仅起到一个同步的作用，分别对应三个事件：
6.1.1）flip_down
6.1.2）hw_down
6.1.3）cleanup_down
6.2）drm_atomic_commit
真正的commit操作由drm_atomic_commit函数实现， 如下：
int drm_atomic_commit(struct drm_atomic_state *state)
{
struct drm_mode_config *config = &state->dev->mode_config;
int ret;
ret = drm_atomic_check_only(state);
if (ret)
return ret;
DRM_DEBUG_ATOMIC("committing %p\n", state);
return config->funcs->atomic_commit(state->dev, state, false);
}主要分为检查state合法性和调用drm_mode_config_funcs->atomic_commit函数进行commit操作。默认情况下，atomic_commit回调函数的功能是由drm_atomic_helper_commit实现的。函数内部有两个code path：阻塞和非阻塞。此处以阻塞情况进行分析，因为上面看到，drm_atomic_commit调用的是非阻塞的实现。
6.3）drm_atomic_helper_commit
大多数情况下，驱动程序会使用DRM框架中提供的默认实现。而DRM框架为atomic_commit回调函数提供个的默认实现为drm_atomic_helper_commit，接下来就对该函数进行分析。函数的实现很明显被drm_atomic_state参数中的async_update分成两段，如下：
if (state->async_update) {
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
return ret;
drm_atomic_helper_async_commit(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
return 0;
}在非异步模式下，函数首先调用drm_atomic_helper_setup_commit做合法性检查并且创建drm_crtc_commit。随后函数初始化state->commit_work，后续相应操作可能放到workqueue中完成。
函数最后调用drm_atomic_helper_prepare_planes对所有的state中新出现的plane依次调用其helper中的prepare_fb回调函数。对于非阻塞的情况，调用drm_atomic_helper_wait_for_fences进行等待操作。最后调用软件层核心的drm_atomic_helper_swap_state函数将新的状态更新到旧的状态，注意这里是软件层面的更新，单纯的是修改state对象。
如果函数调用时使用非阻塞模式，则直接调度起workqueue执行后续操作，反之则直接调用commit_tail函数，如下：
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
commit_tail(state);实际上state->commit_work的处理函数也是直接调用commit_tail：
static void commit_work(struct work_struct *work)
{
struct drm_atomic_state *state = container_of(work,
struct drm_atomic_state,
commit_work);
commit_tail(state);
}而commit_tail的实现用到了多个helper：
static void commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
const struct drm_mode_config_helper_funcs *funcs;
funcs = dev->mode_config.helper_private;
drm_atomic_helper_wait_for_fences(dev, old_state, false);
drm_atomic_helper_wait_for_dependencies(old_state);
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
drm_atomic_helper_commit_tail(old_state);
drm_atomic_helper_commit_cleanup_done(old_state);
drm_atomic_state_put(old_state);
}6.4）drm_atomic_helper_setup_commit
函数首先遍历所有状态发生改变的CRTC，然后对其创建drm_crtc_commit，前面看到这个对象是对Commit操作的进度进行追踪用的。创建之后的drm_crtc_commit就保存在new_crtc_state->commit中。之后函数会调用stall_checks检查当前的commit队列中是否有停滞的commit：
list_for_each_entry(commit, &crtc->commit_list, commit_entry) {
if (i == 0) {
completed = try_wait_for_completion(&commit->flip_done);
/* Userspace is not allowed to get ahead of the previous
* commit with nonblocking ones. */
if (!completed && nonblock) {
spin_unlock(&crtc->commit_lock);
return -EBUSY;
}
} else if (i == 1) {
stall_commit = drm_crtc_commit_get(commit);
break;
}
i++;
}
spin_unlock(&crtc->commit_lock);从逻辑上来看，从commit队列中取下第一个drm_commit，然后检查其flip_done的completion是否已经被完成了。如果没有完成，且运行drm_atomic_helper_commit时为为非阻塞模式（nonblock参数为true），则直接让整次commit操作返回-EBUSY。随后，取下第二个drm_commit（如果存在的话），并认为其为stall的，直接以10秒为timeout等待其cleanup_done完成。
函数接下来做了两个简单的优化：
/* Drivers only send out events when at least either current or
* new CRTC state is active. Complete right away if everything
* stays off. */
if (!old_crtc_state->active && !new_crtc_state->active) {
complete_all(&commit->flip_done);
continue;
}
/* Legacy cursor updates are fully unsynced. */
if (state->legacy_cursor_update) {
complete_all(&commit->flip_done);
continue;
}新旧两个状态的CRTC都为关闭状态时肯定flip_done是直接完成的。且使用Legacy Cursor相关的API时，因为这个API本身就不同步，所以可以直接视为完成了flip_done。随后函数为每个CRTC创建drm_pending_event并放入new_crtc_state->event中，注意新创建的drm_pending_event的completion指针直接指向前面创建的drm_commit->flip_event，也就是这个drm_pending_event进行处理的时候，会直接完成相应的flip_done。
6.5）drm_atomic_helper_wait_for_fences
这个函数对于所有的新状态涉及的plane都会依次对new_plane_state->fence调用dma_wait_fence。也就是单纯研究这个函数没有什么意义，需要结合plane相关的实现进行分析。
6.6）drm_atomic_helper_wait_for_dependencies
该函数依次对本次commit的旧状态，即原先的状态对应的commit（将显示控制器置成oldstate的commit）中相应的事件进行等待。简单来说，就是等待old_{crtc,plane,connector}_state->commit 上的hw_done和flip_done。
6.7）drm_atomic_helper_commit_tail
commit_tail中调用了drm_cmode_config_helpers->atomic_commit_tail回调函数，在其为空的情况下，则直接调用drm_atomic_helper_commit_tail
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_planes(dev, old_state, 0);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
drm_atomic_helper_fake_vblank(old_state);
drm_atomic_helper_commit_hw_done(old_state);
drm_atomic_helper_wait_for_vblanks(dev, old_state);
drm_atomic_helper_cleanup_planes(dev, old_state);
}边栏推荐
- [Metaverse Omi Says] Listen to how Rabbit Fan Rabbit creates a new era of trendy play from virtual to reality
- BUUCTF problem solving PWN 】 【 record (4-6 pages continuously updated)
- 多元线性回归分析（Stata）
- 如何理解BIO、NIO、AIO的区别
- Mongo的简单操作-数据库用户的查询、创建与删除
- Basic concepts, structures, and classes of thread pools
- 细说Redis监控和告警
- shell之函数和数组
- MUDA：对齐特定域的分布和分类器以实现来自多源域的跨域分类
- navicat导入SQL文件报：[ERR] 2006 - MySQL server has gone away [ERR] -- MySQL dump 10.13 Distrib 5.7.34
猜你喜欢
Vivado时序约束中Tcl命令的对象及属性
UE4 Sequence添加基础动画效果 （04-在序列中使用粒子效果）
The first offline workshop in 2022!Data application experience day for application developers is coming | TiDB Workshop Day
BUUCTF problem solving PWN 】 【 record (4-6 pages continuously updated)
JVM探究
Chapter 3 Search and Graph Theory (3)
win下的开发环境变量记录
支付 x 聚合 x 分账 - 回流平台“二清”风险规避之路
DataStream API（基础篇） 完整使用 (第五章)
91.（cesium之家）cesium火箭发射模拟
随机推荐
属性动画QPropertyAnimation
Basic concepts, structures, and classes of thread pools
MUDA：对齐特定域的分布和分类器以实现来自多源域的跨域分类
日期类（暑假每日一题 19）
Optimistic and pessimistic locking
shell之函数和数组
FPGA时钟篇(一) 7系列的时钟结构
第三章 搜索与图论(三)
裸辞→自我放松→闭关→复习→斩获Offer
JVM探究
[OAuth2] 20. OAuth2 Extended Protocol PKCE
数据库注入提权总结（一）
2022年固定资产管理系统的概况
Lasso regression (Stata)
Relearn bubble sort
【Software Exam System Architect】System Reliability Analysis and Design ① System Reliability Analysis
JWT: To own me is to have power
【API架构】REST API 行业辩论：OData vs GraphQL vs ORDS
在“企业通讯录”的盲区，融云的边界与分寸
FPGA的虚拟时钟如何使用？