📚 课程目录第3章帧缓冲驱动框架

3. 帧缓冲驱动框架：核心结构与模型

帧缓冲（FrameBuffer）驱动是 Linux 显示子系统的基石。本章深入剖析帧缓冲驱动的核心数据结构 fb_info、操作集 fb_ops、注册/注销机制以及 platform 驱动模型的整合方式。理解这些内容，是编写稳定、高效的显示驱动的第一步。

  核心要点：帧缓冲驱动的本质是将显存抽象为一个字符设备，通过 fb_info 描述硬件能力，通过 fb_ops 提供操作接口，最终通过 fbmem.c 中的框架注册到内核。

3.1 fb_info 结构体详解

fb_info 是帧缓冲驱动的“身份证”，它包含了显示设备的所有硬件信息和状态。每个帧缓冲设备对应一个 fb_info 实例。

3.1.1 核心字段与功能

字段名	类型	功能描述
`state`	`struct fb_state`	记录当前显示状态（开启/关闭/休眠）
`node`	`int`	设备编号（如 /dev/fb0 的 node=0）
`flags`	`int`	设备标志位（如 FBINFO_FLAG_DEFAULT）
`fbops`	`struct fb_ops *`	指向操作函数集的指针
`screen_base`	`char __iomem *`	显存虚拟基地址（CPU 访问显存的入口）
`screen_size`	`unsigned long`	显存总大小（字节）
`var`	`struct fb_var_screeninfo`	可变屏幕参数（分辨率、位深、时序等）
`fix`	`struct fb_fix_screeninfo`	固定屏幕参数（显存物理地址、步长等）
`pseudo_palette`	`void *`	伪调色板（用于 8/16 位色模式）
`device`	`struct device *`	关联的 Linux 设备模型指针

开发提示：var 和 fix 是用户空间与内核空间交互的主要通道。用户通过 FBIOPUT_VSCREENINFO 修改 var，驱动则通过 fix 报告硬件固定属性。

3.1.2 fb_info 结构体关系图

下图展示了 fb_info 与周边核心数据结构的关系：

3.2 fb_ops 操作集

fb_ops 是帧缓冲驱动的“函数表”，驱动开发者通过实现这些回调函数来提供具体的硬件操作能力。用户空间的 ioctl 调用最终都会映射到 fb_ops 中的某个函数。

3.2.1 关键回调函数

回调函数	触发场景	必须实现？
`fb_open`	用户打开 /dev/fbX 时	否（默认空）
`fb_release`	用户关闭 /dev/fbX 时	否（默认空）
`fb_read`	用户读取显存数据	否（使用默认实现）
`fb_write`	用户写入显存数据	否（使用默认实现）
`fb_check_var`	用户设置显示参数前校验	是
`fb_set_par`	应用显示参数到硬件	是
`fb_setcolreg`	设置颜色寄存器（调色板）	视硬件而定
`fb_blank`	屏幕开关/休眠	推荐实现
`fb_pan_display`	硬件 panning（滚动显示）	可选
`fb_mmap`	用户 mmap 映射显存	推荐实现

常见陷阱：很多初学者只实现 fb_set_par 而忽略 fb_check_var。这会导致用户设置非法参数时驱动无法拒绝，可能造成硬件崩溃。务必先校验，再应用。

3.2.2 fb_ops 调用流程

3.3 注册与注销：fbmem.c 核心机制

fbmem.c 是帧缓冲子系统的核心文件，它负责管理所有帧缓冲设备的注册、注销以及字符设备接口的创建。驱动开发者通过调用 register_framebuffer 和 unregister_framebuffer 来与 fbmem.c 交互。

3.3.1 注册流程

分配 fb_info：使用 framebuffer_alloc 分配并初始化 fb_info 结构体。
填充字段：设置 var、fix、fbops、screen_base 等核心字段。
调用 register_framebuffer：将 fb_info 注册到内核帧缓冲子系统。
创建设备节点：fbmem.c 自动创建 /dev/fbX 字符设备。

关键函数原型：

struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
int register_framebuffer(struct fb_info *fb_info);
int unregister_framebuffer(struct fb_info *fb_info);
void framebuffer_release(struct fb_info *fb_info);

3.3.2 注册与注销对比

操作	函数	注意事项
分配	`framebuffer_alloc`	第二个参数传入 platform_device 的 dev
注册	`register_framebuffer`	注册后立即生效，用户可访问
注销	`unregister_framebuffer`	必须在释放内存前调用
释放	`framebuffer_release`	释放 framebuffer_alloc 分配的内存

内存泄漏风险：如果 register_framebuffer 失败，必须立即调用 framebuffer_release 释放已分配的内存。很多驱动在 probe 失败路径上遗漏了这个步骤。

3.4 platform 驱动模型整合

在现代 Linux 内核中，帧缓冲驱动通常基于 platform 驱动模型实现。platform 驱动模型将硬件设备抽象为 platform_device，将驱动抽象为 platform_driver，通过匹配机制实现自动探测。

3.4.1 驱动结构模板

static const struct of_device_id myfb_of_match[] = {
    { .compatible = "vendor,myfb" },
    { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, myfb_of_match);

static struct platform_driver myfb_driver = {
    .probe  = myfb_probe,
    .remove = myfb_remove,
    .driver = {
        .name = "myfb",
        .of_match_table = myfb_of_match,
    },
};

module_platform_driver(myfb_driver);

3.4.2 probe 函数典型实现

static int myfb_probe(struct platform_device *pdev)
{
    struct fb_info *info;
    struct resource *res;

    // 1. 分配 fb_info
    info = framebuffer_alloc(0, &pdev->dev);
    if (!info)
        return -ENOMEM;

    // 2. 获取硬件资源（IO内存、中断等）
    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    info->screen_base = devm_ioremap_resource(&pdev->dev, res);
    if (IS_ERR(info->screen_base)) {
        framebuffer_release(info);
        return PTR_ERR(info->screen_base);
    }

    // 3. 填充 fb_info 字段
    info->fbops = &myfb_ops;
    info->var = myfb_default_var;
    info->fix = myfb_default_fix;
    info->screen_size = resource_size(res);
    info->pseudo_palette = NULL;

    // 4. 注册帧缓冲设备
    if (register_framebuffer(info) < 0) {
        framebuffer_release(info);
        return -EINVAL;
    }

    // 5. 保存 info 指针供 remove 使用
    platform_set_drvdata(pdev, info);

    return 0;
}

3.4.3 platform 驱动模型架构图

3.5 完整驱动框架总结

一个完整的帧缓冲 platform 驱动包含以下关键步骤：

设备树匹配：通过 of_match_table 与硬件设备绑定。
资源获取：在 probe 中获取 IO 内存、时钟、中断等资源。
fb_info 初始化：填充 var、fix、fbops、screen_base。
注册帧缓冲：调用 register_framebuffer 使设备可用。
注销与清理：在 remove 中先 unregister_framebuffer，再 framebuffer_release。

最佳实践：使用 devm_* 系列函数（如 devm_ioremap_resource）管理资源，可以简化错误处理路径，避免资源泄漏。