Linux 驱动开发 四十二：Platform 平台设备驱动框架

最后将device_node链表赋给of_root，即of_root代表所有的device_node的root，通过它，可以遍历所有的device_node。从start_kernel开始是找不到platform device这一部分转换的源头的，这个转换过程的函数是of_platform_default_populate_init(),它被调用的方式是一个声明：arch_initcall_sync(of_platform_default_populate_init);但这种方式应该很少见了。

嵌入式系统中有很多的物理总线：I2c、SPI、USB、uart、PCIE、APB、AHB。像这样的总线很多，而 Linux 系统要考虑到驱动的可重用性，因此提出了驱动的分离与分层这样的软件思路，于是 Linux从2.6起就加入了 platform 设备驱动，也叫做平台设备驱动。它是一条虚拟的总线, 并不是一个物理的总线。如下图所示：（本文不考虑设备树的情况）：

要满足 Linux 设备模型，就必须有总线、设备和驱动。但是有的设备并没有对应的物理总线，比如 LED、RTC 和蜂鸣器等。为此，内核专门开发了一种虚拟总线一-platfomm总线，用来连接这些没有物理总线的设备或者一些不支持热插拔的设备，DM9000 网卡设备就是挂接在这条总线上的。

platform驱动框架： //设备结构体 struct device {}; //驱动结构体 struct device_driver {}; //平台设备驱动框架 struct platform_driver { int (*probe)(struct platform_device *); int (*remove)(struct platform_device *); void (*shutdown)(struct platform_device *); int (*suspend)(s

一、platform总线、设备与驱动         一个现实的Linux设备和驱动通常都需要挂接在一种总线上，对于本身依附于PCI、USB、I2C、SPI等的设备而言，这自然不是问题，但是在嵌入式系统里面，SoC系统中集成的独立的外设控制器、挂接在SoC内存空间的外设等确不依附于此类总线。基于这一背景，Linux发明了一种虚拟的总线，称为platform总线，相应的设备称为platform_d

Table of Contents 1、设备层注册、注销函数 1.1、platform_device_register 1.2、platform_device_unregister 1.3、platform_add_devices 2、驱动层注册注销函数 2.1、platform_driver_register 2.2、platform_driver_ unregister 3、...

linux系列目录： linux基础篇（一）——GCC和Makefile编译过程 linux基础篇（二）——静态和动态链接 ARM裸机篇（一）——i.MX6ULL介绍 ARM裸机篇（二）——i.MX6ULL启动过程 ARM裸机篇（三）——i.MX6ULL第一个裸机程序 ARM裸机篇（四）——重定位和地址无关码 ARM裸机篇（五）——异常和中断 linux系统移植篇（一）—— linux系统组成 linux系统移植篇（二）—— Uboot使用介绍 linux系统移植篇（三）—— Linux 内核使用介绍 li

在之前的字符设备程序中驱动程序，我们只要调用open()函数打开了相应的设备文件，就可以使用read()/write()函数， 通过file_operations这个文件操作接口来进行硬件的控制。这种驱动开发方式简单直观，但是从软件设计的角度看，却是一种十分糟糕的方式。它有一个严重的问题，就是设备信息和驱动代码杂糅在一起，在我们驱动程序中各种硬件寄存器地址随处可见。本质上，这种驱动开发方式与单片机的驱动开发并没有太大的区别，一旦硬件信息发生变化甚至设备已经不在了，就必须要修改驱动源码。

platform设备驱动详解     前面我们讲了设备驱动的分离,并且引出了总线(bus)、驱动(driver)和设备(device)模型,比如 I2C、SPI、USB 等总线。但是在 SOC 中有些外设是没有总线这个概念的,但是又要使用总线、驱动和设备模型该怎么办呢?为了解决此问题,Linux 提出了 platform 这个虚拟总线,相应的就有 platform_driver 和 platfo...

plattorm是为了驱动的分离与分层而提出来的一种框架，其驱动的具体实现还是需要字符设备驱动、块设备驱动或网络设备驱动。 对于一个完整的驱动程序，必须提供“有设备树”和“无设备树”两种匹配方法。

基于STM32MP1Linux 驱动开发实战 平台设备驱动

Linux系统内核使用bus_type结构体表示总线，该结构体定义在文其中的match函数用于总线完成设备和驱动之间匹配 dev为设备，drv为驱动，所以每一条总线都必须实现这个函数。platform总线是bus_type的一个示例，在其中使用进行驱动和设备之间的匹配。return!return 1;return 1;= NULL;：设备树的匹配方式，通过compatible属性在OF表匹配，匹配后执行probe函数。

平台设备框架(platform)是将一个驱动分为设备层和驱动层两个部分，通过总线模型将设备和驱动进行绑定。在系统中每注册一个设备，都会与之匹配一个驱动，同样的，每注册一个驱动也会与之匹配一个设备。通常 Linux 设备和驱动通常都需要挂接在一种总线上，对于本身依附于 PCI、 USB、 I2 C、 SPI 等的设备而言，这自然不是问题，但是在嵌入式系统里面， SOC 系统中集成的独立的外设控制器、挂接在 SOC 内存空间的外设等却不依附于此类总线。

【Linux驱动】platform设备驱动基础框架

驱动框架-platform驱动框架

硬件上同一总线上的设备遵循一致的时序通信，在其基础上增加管理设备和驱动的软件功能，于是引入总线（BUS），各种总线的核心框架有内核来实现，通信时序一般由SOC供应商支持；初期方案，各种device需要编码方式注册进内核中的设备管理结构中，为了进一步减少这样的编码，引入设备树。3.2 id匹配（可想象成八字匹配）：一个驱动可以对应多个设备 ------优先级次低。3.3 设备树匹配：内核启动时根据设备树自动产生的设备 ------ 优先级最高。总线：匹配设备和驱动——婚介所：提供沟通机制，完成拉郎配。

在内核中对挂载在总线上的设备编写驱动时，整个驱动框架遵循总线驱动模型：即在总线驱动模型中分为了三部分 device\driver\bus.device是保存当前设备的设备信息的对象，它会放在一个klist_device链表中进行管理，driver是一个设备的驱动信息对象，它会放在内核中的一个链表klist_driver链表进行管理。

本文介绍Linux下platform驱动框架，包括驱动的分离和分层，platform模型等，并给出了platform驱动的代码框架。

printk和printf非常相似，它用于输出驱动程序的调试信息，但是printk的功能更强大，可以规定打印等级，显示打印时的系统时间，此外，printk仅用于输出调试信息，它输出的内容不会进入stdio的缓冲流内。该文件夹提供了整个linux的所有配置选项，对于驱动开发来说，我们需要重点关注的是/sys/class文件夹，因为该文件夹下的对象是创建/dev下设备文件的必要条件之一，并且它通常用于存放驱动程序的配置选项。此处只讲片上设备的操作，因为对外部设备的操作都可以归结为对CPU的片上设备进行操作。