zoukankan      html  css  js  c++  java
  • 深入解析Linux Platform_device及驱动

    关注、星标嵌入式客栈,干货及时送达

    [导读] 前文分析了Linux设备驱动的驱动模型,本文来聊聊Platform_driver/Platform_device这个类。做嵌入式Linux的驱动,这个也是绕不开的,所以来学习分析总结一下。

    阅读本文,建议先读:学Linux驱动:应先了解总线驱动模型

    上文点击即可阅读。注:代码分析基于linux-5.4.31

    为什么有Platform_driver

    前文谈到的总线驱动模型(注这个图是照着bootlin的文档绘制的):

    同时,根据代码分析其基础数据结构框架关系如下(UML关系并不严谨,仅为理解方便):

    可见驱动程序的模型分层有一层总线基础层,那么对于嵌入式开发领域而言,有很多SOC芯片内置了各种外设,并比如LCD,UART、audio、摄像头口等等,并没有总线。为了统一驱动架构抽象,所以引入了platform bus这个虚拟的总线模型。做过嵌入式开发的人应该都有体会,这类设备在嵌入式系统中非常多,所以在研究具体某类设备的驱动开发之前,有必要研究platform 设备的驱动模型。在强调一下这个是统一在总线驱动模型这个体系内的。

    驱动模型的实现

    定义在./include/linux/platform_device.h中,来梳理一下这些数据结构间的关系:

    • platform_device 用于抽象平台设备

    • platform_driver 用于抽象匹配平台设备对应的驱动程序

    • 通过继承演化关系分析,platform_device/platform_driver 仍然统一于总线驱动模型,只是虚拟出来了一条platform bus这样一条虚拟总线。

    • platform_bus在哪里实现的呢?该模块的实现位于./driver/base/platform.c中

    struct device platform_bus = {
     .init_name = "platform",
    };
    
    • platform.c导出了一系列内核全局操作接口集:

    EXPORT_SYMBOL_GPL(platform_bus);
    EXPORT_SYMBOL_GPL(__platform_driver_register);
    EXPORT_SYMBOL_GPL(__platform_driver_probe);
    EXPORT_SYMBOL_GPL(platform_get_resource_byname);
    EXPORT_SYMBOL_GPL(platform_get_irq_byname);
    ....
    
    • 那么既然这条总线并不存在,往往并不能实现设备枚举、热插拔等功能。

    • 既然不能利用总线自动枚举,那么底层又是怎么玩的呢?实际上可选的有这样几种方式

      • 通过内核代码静态描述实现

      • 通过设备树进行匹配加载

      • BIOS ACPI表(X86/PC体系)

    • 平台设备是通常在系统中显示为自治实体的设备。这包括基于旧端口的设备和到外围总线的主机桥接,以及集成到片上系统平台中的大多数控制器。它们通常的共同点是从CPU总线直接寻址。很少有platform_device通过某种其他类型的总线的一部分连接的。但其寄存器仍将直接可寻址。

    设备探测

    • probe()通常应该验证指定的设备硬件确实存在;有时平台设置代码不能确定。该函数用于检测可以使用设备资源,包括时钟和设备platform_data。

    • 设备的注册则是通过下面函数实现

    int platform_driver_register(struct platform_driver *drv);
    

    设备命令以及绑定

    • platform_device.dev.bus_id 设备名由两个部分组成

      • platform_device.name 用于驱动匹配

      • platform_device.id 设备实例号,或者用“-1”表示只有一个实例

      • 如"serial/0“ 表示 bus_id "serial.0","serial/3“ 表示 bus_id "serial.3"

    • 驱动程序绑定由驱动程序核心自动执行,在发现设备和驱动程序之间的匹配之后调用驱动程序probe()。如果probe()成功,驱动程序和设备将像往常一样绑定。有三种不同的方法来找到这样的匹配:

      • 每当注册一个设备时,就会检查该总线的驱动程序是否匹配。平台设备应该在系统启动时尽早注册.

      • 当使用platform_driver_register()注册一个驱动程序时,将检查总线上所有未绑定的设备是否匹配。驱动程序通常在引导期间稍后注册,或者通过模块加载注册。

      • 使用platform_driver_probe()注册驱动程序与使用platform_driver_register()一样,不同的是,如果以后有其他设备注册,驱动程序不会被探测。

    资源机制

    • 每个由特定驱动程序管理的设备通常使用不同的硬件资源:I/O寄存器地址、DMA通道、IRQ线路等。

    • struct resource就是用于抽象描述驱动程序需要用到的硬件资源,struct resource 被包进platform_device,实现与 struct platform_device关联。

    • 允许驱动程序被实例化为多个功能类似的设备,但具有不同的地址、irq等。

    • 硬件资源如时针、IO口等的分配现在基本基于设备树,对于设备树这里不展开,后面有机会总结分享,这里举个栗子:

    uart0: serial@44e09000 {
        compatible = "ti,omap3-uart";
        ti,hwmods = "uart1";
        clock-frequency = <48000000>;
        reg = <0x44e09000 0x2000>;
        interrupts = <72>;
        status = "disabled";
    };
    

    platform_driver实例

    以samsung.c 串口驱动程序为例:

    /*兼容匹配表*/
    static const struct platform_device_id s3c24xx_serial_driver_ids[] = {
     {
      .name  = "s3c2410-uart",
      .driver_data = S3C2410_SERIAL_DRV_DATA,
     }, {
      .name  = "s3c2412-uart",
      .driver_data = S3C2412_SERIAL_DRV_DATA,
     }, {
      .name  = "s3c2440-uart",
      .driver_data = S3C2440_SERIAL_DRV_DATA,
     }, {
      .name  = "s3c6400-uart",
      .driver_data = S3C6400_SERIAL_DRV_DATA,
     }, {
      .name  = "s5pv210-uart",
      .driver_data = S5PV210_SERIAL_DRV_DATA,
     }, {
      .name  = "exynos4210-uart",
      .driver_data = EXYNOS4210_SERIAL_DRV_DATA,
     }, {
      .name  = "exynos5433-uart",
      .driver_data = EXYNOS5433_SERIAL_DRV_DATA,
     },
     { },
    };
    MODULE_DEVICE_TABLE(platform, s3c24xx_serial_driver_ids);
    
    #ifdef CONFIG_OF
    /*设备树对应解析匹配表*/
    static const struct of_device_id s3c24xx_uart_dt_match[] = {
     { .compatible = "samsung,s3c2410-uart",
      .data = (void *)S3C2410_SERIAL_DRV_DATA },
     { .compatible = "samsung,s3c2412-uart",
      .data = (void *)S3C2412_SERIAL_DRV_DATA },
     { .compatible = "samsung,s3c2440-uart",
      .data = (void *)S3C2440_SERIAL_DRV_DATA },
     { .compatible = "samsung,s3c6400-uart",
      .data = (void *)S3C6400_SERIAL_DRV_DATA },
     { .compatible = "samsung,s5pv210-uart",
      .data = (void *)S5PV210_SERIAL_DRV_DATA },
     { .compatible = "samsung,exynos4210-uart",
      .data = (void *)EXYNOS4210_SERIAL_DRV_DATA },
     { .compatible = "samsung,exynos5433-uart",
      .data = (void *)EXYNOS5433_SERIAL_DRV_DATA },
     {},
    };
    MODULE_DEVICE_TABLE(of, s3c24xx_uart_dt_match);
    #endif
    /*串口设备驱动实体*/
    static struct platform_driver samsung_serial_driver = {
     .probe  = s3c24xx_serial_probe,
     .remove  = s3c24xx_serial_remove,
     .id_table = s3c24xx_serial_driver_ids,
     .driver  = {
      .name = "samsung-uart",
      .pm = SERIAL_SAMSUNG_PM_OPS,
      .of_match_table = of_match_ptr(s3c24xx_uart_dt_match),
     },
    };
    

    总结一下

    对于做嵌入式Linux驱动开发,个人体会是先对总线驱动模型有一个相对清晰的概念认识会比较好,而平台设备以及平台设备驱动模型同样是衍生于总线驱动模型,这样从体系结构上就变得相对统一了。平台设备及驱动在嵌入式系统里大量应用,很多SOC内置了大量丰富的各类设备接口,这些接口往往都是通过处理器内部总线进行直接寻址的,这类型的设备几乎都是通过平台设备及驱动模型进行抽象实施的,所以深入理解平台设备/平台设备驱动模型,无疑对开发此类设备驱动程序大有助益。

    END

    往期精彩推荐,点击即可阅读

    ▲学Linux驱动:应先了解总线驱动模型

    读U-Boot源码-C语言编程大法总结篇一

    基于Buildroot的Linux构建之根文件系统

    手把手教系列之移动平均滤波器C实现

    手把手教系列之IIR数字滤波器设计实现

    为节约时间,文章同步自公众号(首发) 如需学习资料,请用微信关注文中公众号二维码,后台发送"领取",可免费获取海量学习资料,涵盖单片机技术,信号处理,人工智能,嵌入式linux,C/C++编程,数据结构与算法
  • 相关阅读:
    java 使用相对路径读取文件
    appium 使用过程问题踩坑-笔记
    CentOS下启动Tomcat
    jodis遇到的问题
    CentOS 7.0 防火墙
    sentinel
    keepalived
    在Tomat7上使用Redis保存Session
    Log4j 使用
    java路径问题
  • 原文地址:https://www.cnblogs.com/embInn/p/14038143.html
Copyright © 2011-2022 走看看