Linux系统之Platform设备驱动

已于 2023-07-06 11:50:19 修改
阅读量1.6k 收藏 1
点赞数
文章标签： linux 驱动开发 系统架构
于 2023-07-06 00:56:04 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/userpid/article/details/131566543
版权

Linux系统之Platform设备驱动https://mp.weixin.qq.com/s?__biz=Mzg3NDkwMjc2NA==&mid=2247483754&idx=1&sn=222dcdd1d30fa541b40bdf29c440f6c0&chksm=cec8e4e9f9bf6dffd6213094f1dee1d3a6bec6a8e08c4dedeff3dab6e4ba854d11d03898d2ca#rd

在Linux系统中，驱动的设计充分体现了“高内聚、低耦合”的软件设计思想。这种思想体现在驱动设计的分层、分离上，下文将简单介绍platform设备驱动的实现，让我们来感受一下驱动设计的哲学。

platform设备驱动包含platform总线、platform设备和platform驱动三个部分，下面将分别介绍这三个部分。

1 platform 设备

platform设备通常包含设备的硬件资源。

未引入设备树之前，片上外设的硬件资源通常在arch/arm/mach-xxx/board-xxx.c定义，并由内核自动注册为platform设备。

引入设备树后，硬件资源不再集成到Linux源码中，而是按照设备树语法编写成设备树文件，并进行单独编译（.dtb）。把板级的硬件信息从源码中分离出来，并对其使用统一的方式管理，我认为既降低了系统维护的难度，也有利于保持代码的干净。

在内核启动的过程中，会对设备树进行解析，把对应的设备节点转换成platform设备。

flatform设备在Linux系统中的抽象如下：

//linux-4.1.15/include/linux/platform_device.h
struct platform_device {
	const char	*name;
	int		id;
	bool		id_auto;
	struct device	dev;
	u32		num_resources;
	struct resource	*resource;

	const struct platform_device_id	*id_entry;
	char *driver_override; /* Driver name to force a match */

	/* MFD cell pointer */
	struct mfd_cell *mfd_cell;

	/* arch specific additions */
	struct pdev_archdata	archdata;
};

其中resource结构体就是用于登记相关的硬件资源信息，如资源的类型、资源的地址空间等等，这里将不展开叙述，有兴趣的朋友可以查阅注册platform设备的相关代码。

2 platform 驱动

platform驱动一般由驱动工程师编写。当我们把platform驱动注册到platform总线时，platform总线会根据platform驱动的参数，查找与之匹配的设备。当存在与驱动匹配的设备时，总线将会把设备和驱动绑定。驱动可调用相关的接口获取设备资源，并驱动设备。

flatform设备在Linux系统中的抽象如下：

//linux-4.1.15/include/linux/platform_device.h
struct platform_driver {
	int (*probe)(struct platform_device *);
	int (*remove)(struct platform_device *);
	void (*shutdown)(struct platform_device *);
	int (*suspend)(struct platform_device *, pm_message_t state);
	int (*resume)(struct platform_device *);
	struct device_driver driver;
	const struct platform_device_id *id_table;
	bool prevent_deferred_probe;
};

将在示例中详细说明这个结构体的各个元素的作用。

3 platform 总线

platform总线是Linux系统发明的虚拟总线。如同I2C、SPI等总线，其作用是建立主机和从机通信的通道。platform总线的作用是根据相关规则匹配设备和驱动，使驱动与对应的设备建立联系。

flatform总线在Linux系统中的抽象如下：

//linux-4.1.15/drivers/base/platform.c
struct bus_type platform_bus_type = {
	.name		= "platform",
	.dev_groups	= platform_dev_groups,
	.match		= platform_match,
	.uevent		= platform_uevent,
	.pm		= &platform_dev_pm_ops,
};
EXPORT_SYMBOL_GPL(platform_bus_type);

其中 platform_match 就是负责设备与驱动的匹配工作。

/** -> linux-4.1.15/drivers/base/platform.c
 * platform_match - bind platform device to platform driver.
 * @dev: device.
 * @drv: driver.
 *
 * Platform device IDs are assumed to be encoded like this:
 * "<name><instance>", where <name> is a short description of the type of
 * device, like "pci" or "floppy", and <instance> is the enumerated
 * instance of the device, like '0' or '42'.  Driver IDs are simply
 * "<name>".  So, extract the <name> from the platform_device structure,
 * and compare it against the name of the driver. Return whether they match
 * or not.
 */
static int platform_match(struct device *dev, struct device_driver *drv)
{
	struct platform_device *pdev = to_platform_device(dev);
	struct platform_driver *pdrv = to_platform_driver(drv);

	/* When driver_override is set, only bind to the matching driver */
	if (pdev->driver_override)
		return !strcmp(pdev->driver_override, drv->name);

	/* Attempt an OF style match first */
	if (of_driver_match_device(dev, drv)) /* --> 匹配设备树的compatible属性和设备驱动的compatible属性 */
		return 1;

	/* Then try ACPI style match */
	if (acpi_driver_match_device(dev, drv))
		return 1;

	/* Then try to match against the id table */
	if (pdrv->id_table) 
		return platform_match_id(pdrv->id_table, pdev) != NULL;/* --> 匹配设备和驱动的id table */

	/* fall-back to driver name match */
	return (strcmp(pdev->name, drv->name) == 0); /* --> 匹配设备和驱动的名字 */
}

可以看到这个接口根据struct platform_device和struct platform_driver的信息进行匹配绑定。

4 示例

在这个示例中，

  • 调用<late_initcall>接口，

    注册一个module：<pwm_backlight_init>

    在Linux启动过程中将会加载这个module

  • 在这个module中注册一个platform设备驱动

    （这个驱动抽象为<pwm_backlight_driver>结构体）

    <platform_driver_register(&pwm_backlight_driver); >

  • 在<pwm_backlight_driver>中可以看到该驱动的名字<.name= "pwm-backlight",>和设备树的匹配属性<{ .compatible = "pwm-backlight" },>

    platform总线将会根据这两个参数匹配已注册的设备

  • 当我们的platform驱动注册后，platform总线将驱动与总线上的设备进行匹配，当匹配属性一致时，驱动将与该设备进行绑定，并执行<pwm_backlight_driver>中的<pwm_backlight_probe>函数

  • 在probe函数中，我们将解析设备节点的资源，并以此初始化相关的硬件外设（GPIO、PWM等）

  • 完成初始化的外设可以通过系统调用的方式供上层应用使用，也可以导出符号表供其他驱动模块使用

  • 当我们卸载驱动（insmod加载，rmmod卸载）后

    将会执行<pwm_backlight_driver>中的

    <pwm_backlight_remove>函数，这个函数将会释放驱动所占用的硬件和内存资源，如注销pwm，释放申请的内存空间等

/linux-4.1.15/drivers/video/backlight/pwm_bl.c
/*
 * linux/drivers/video/backlight/pwm_bl.c
 *
 * simple PWM based backlight control, board code has to setup
 * 1) pin configuration so PWM waveforms can output
 * 2) platform_data being correctly configured
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
......

struct pwm_bl_data {
	struct device		*dev;
	......
};

static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness)
{
	......
}

static void pwm_backlight_power_off(struct pwm_bl_data *pb)
{
	......
}

static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
{
	......
}

static int pwm_backlight_update_status(struct backlight_device *bl)
{

	......
}

static int pwm_backlight_check_fb(struct backlight_device *bl,
				  struct fb_info *info)
{
	......
}
}

static const struct backlight_ops pwm_backlight_ops = {
	.update_status	= pwm_backlight_update_status,
	.check_fb	= pwm_backlight_check_fb,
};

#ifdef CONFIG_OF
static int pwm_backlight_check_fb_name(struct device *dev, struct fb_info *info)
{
	struct backlight_device *bl = dev_get_drvdata(dev);
	struct pwm_bl_data *pb = bl_get_data(bl);

	if (strcmp(info->fix.id, pb->fb_id) == 0)
		return true;

	return false;
}

static int pwm_backlight_parse_dt(struct device *dev,
				  struct platform_pwm_backlight_data *data)
{
	struct device_node *node = dev->of_node;
	struct property *prop;
	int length;
	u32 value;
	const char *names;
	......
	/* determine the number of brightness levels */
	prop = of_find_property(node, "brightness-levels", &length);
	......

	/* read brightness levels from DT property */
	if (data->max_brightness > 0) {	
		......
		ret = of_property_read_u32_array(node, "brightness-levels",
						 data->levels,
						 data->max_brightness);
		......

		ret = of_property_read_u32(node, "default-brightness-level",
					   &value);
		......
	}

	if (!of_property_read_string(node, "fb-names", &names)){
		strcpy(data->fb_id, names);
		......
	}
	......
	return 0;
}

static struct of_device_id pwm_backlight_of_match[] = {
	{ .compatible = "pwm-backlight" },
	{ }
};

MODULE_DEVICE_TABLE(of, pwm_backlight_of_match);
#else
static int pwm_backlight_parse_dt(struct device *dev,
				  struct platform_pwm_backlight_data *data)
{
	return -ENODEV;
}
#endif

static int pwm_backlight_probe(struct platform_device *pdev)
{
	struct platform_pwm_backlight_data *data = dev_get_platdata(&pdev->dev);
	struct platform_pwm_backlight_data defdata;
	struct backlight_properties props;
	struct backlight_device *bl;
	struct pwm_bl_data *pb;
	int ret;

	if (!data) {
		ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
		......
		data = &defdata;
	}

	if (data->init) {
		ret = data->init(&pdev->dev);
		......
	}

	......
	if (data->levels) {
		unsigned int i;

		for (i = 0; i <= data->max_brightness; i++)
			if (data->levels[i] > pb->scale)
				pb->scale = data->levels[i];

		pb->levels = data->levels;
	} else
		pb->scale = data->max_brightness;

	......
	pb->dev = &pdev->dev;
	......

	pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
	......

	/*
	 * Compatibility fallback for drivers still using the integer GPIO
	 * platform data. Must go away soon.
	 */
	if (!pb->enable_gpio && gpio_is_valid(data->enable_gpio)) {
		ret = devm_gpio_request_one(&pdev->dev, data->enable_gpio,
					    GPIOF_OUT_INIT_HIGH, "enable");
		......
		pb->enable_gpio = gpio_to_desc(data->enable_gpio);
	}

	if (pb->enable_gpio)
		gpiod_direction_output(pb->enable_gpio, 1);

	pb->power_supply = devm_regulator_get(&pdev->dev, "power");
	......

	pb->pwm = devm_pwm_get(&pdev->dev, NULL);
	......

	dev_dbg(&pdev->dev, "got pwm for backlight\n");

	/*
	 * The DT case will set the pwm_period_ns field to 0 and store the
	 * period, parsed from the DT, in the PWM device. For the non-DT case,
	 * set the period from platform data if it has not already been set
	 * via the PWM lookup table.
	 */
	pb->period = pwm_get_period(pb->pwm);
	if (!pb->period && (data->pwm_period_ns > 0)) {
		pb->period = data->pwm_period_ns;
		pwm_set_period(pb->pwm, data->pwm_period_ns);
	}

	pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);

	memset(&props, 0, sizeof(struct backlight_properties));
	props.type = BACKLIGHT_RAW;
	props.max_brightness = data->max_brightness;
	bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
				       &pwm_backlight_ops, &props);
	if (IS_ERR(bl)) {
		dev_err(&pdev->dev, "failed to register backlight\n");
		ret = PTR_ERR(bl);
		goto err_alloc;
	}

	if (data->dft_brightness > data->max_brightness) {
		dev_warn(&pdev->dev,
			 "invalid default brightness level: %u, using %u\n",
			 data->dft_brightness, data->max_brightness);
		data->dft_brightness = data->max_brightness;
	}

	bl->props.brightness = data->dft_brightness;
	backlight_update_status(bl);

	platform_set_drvdata(pdev, bl);
	return 0;

......
	return ret;
}

static int pwm_backlight_remove(struct platform_device *pdev)
{
	struct backlight_device *bl = platform_get_drvdata(pdev);
	struct pwm_bl_data *pb = bl_get_data(bl);

	backlight_device_unregister(bl);
	pwm_backlight_power_off(pb);

	if (pb->exit)
		pb->exit(&pdev->dev);
	if (pb->legacy)
		pwm_free(pb->pwm);

	return 0;
}

static void pwm_backlight_shutdown(struct platform_device *pdev)
{
	......
}

#ifdef CONFIG_PM_SLEEP
static int pwm_backlight_suspend(struct device *dev)
{
	......
	return 0;
}

static int pwm_backlight_resume(struct device *dev)
{
	......
	return 0;
}
#endif

static const struct dev_pm_ops pwm_backlight_pm_ops = {
#ifdef CONFIG_PM_SLEEP
	.suspend = pwm_backlight_suspend,
	.resume = pwm_backlight_resume,
	.poweroff = pwm_backlight_suspend,
	.restore = pwm_backlight_resume,
#endif
};

static struct platform_driver pwm_backlight_driver = {
	.driver		= {
		.name		= "pwm-backlight",
		.pm		= &pwm_backlight_pm_ops,
		.of_match_table	= of_match_ptr(pwm_backlight_of_match),
	},
	.probe		= pwm_backlight_probe,
	.remove		= pwm_backlight_remove,
	.shutdown	= pwm_backlight_shutdown,
};

static int __init pwm_backlight_init(void) 
{ 
        return platform_driver_register(&pwm_backlight_driver); 
} 
//module_init(pwm_backlight_init); 
late_initcall(pwm_backlight_init); 

static void __exit pwm_backlight_exit(void) 
{ 
        platform_driver_unregister(&pwm_backlight_driver); 
} 
module_exit(pwm_backlight_exit);

//module_platform_driver(pwm_backlight_driver);

MODULE_DESCRIPTION("PWM based Backlight Driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:pwm-backlight");

5 结束语

至此，Platform设备驱动已介绍完毕，希望本文可以帮助到大家！

欢迎大家通过后台与我交流学习心得，水平有限，如有错漏的地方请不吝指出，谢谢！

userpid
关注
Linux驱动的platform机制
JuanA1的专栏
11-10 6755
最近在看SPI、I2C这样简单点的总线驱动程序，从Linux2.6起，内核引入了一套新的驱动管理和注册机制：Platform_device和Platform_driver。现在Linux中大部分的设备驱动都可以使用这套机制，总线为platform_bus，设备用platform_device表示，驱动用platform_driver进行注册。     Linux的这种platform drive
Linux驱动——platform设备驱动实验
m0_56561130的博客
05-25 809
文章目录1. 驱动的分离和分层1.1 驱动的分离1.3 驱动的分层2. platform平台驱动模型 1. 驱动的分离和分层 1.1 驱动的分离     假设平台A、B、C都有MPU6050这个IIC接口的六轴传感器，那么驱动框架应该如上图所示。主机驱动是必须的，但设备驱动都是相同的，没必要每个平台都写一个驱动。     那么最好的做法就是每个平台的I2C控制器都提供一个统一的接口，每个设备也只提供一个驱动程序，每个设备通过统一的I2C接口驱动来访问，这样就大大方便了。     实际的I2C驱动设备
10 - platform 设备驱动
最新发布
uuxiang的博客
10-09 890
platform设备驱动
Linux中的platform
yimiyangguang1314的专栏
02-22 4566
总线设备驱动模型主要包含总线、设备、驱动三个部分，总线可以是一条真实存在的总线，例如USB、I2C等典型的设备。但是对于一些设备（内部的设备）可能没有现成的总线。Linux 2.6内核中引入了总线设备驱动模型。总线设备驱动模型与之前的三类驱动（字符、块设备、网络设备）没有必然的联系。设备只是搭载到了总线中。在linux内核中假设存在一条虚拟总线，称之为platform总线。platform总线相比
【IMX6ULL】Linux中的platform驱动
qq_43940175的博客
05-11 371
Linux中的platform驱动 platform 设备驱动，也叫做平台设备驱动。它来源于将驱动分离和分层的软件设计思路。 驱动的分离 ​ 也就是将主机驱动和设备驱动分离，不同主机的同一类驱动提供统一的接口API，然后在写设备驱动的时候只要调用这些API函数就能完成驱动的编写。减少了编写驱动底层代码的时间。 驱动的分层 ​ 分层即是将驱动分成不同的层次，每个层只要做自己的事。例如 input 子系统的最底层是设备原始驱动，负责获取输入设备的原始值，然后上传给核心层；核心层会处理这些数据，然后提供 file
Linux 设备驱动之platform子系统
12-27
本文档主要讲解了platform总线的原理及总线设备的注册跟驱动的编写
Linux驱动开发之platform设备驱动实验【完整教程】
weixin_57037095的博客
03-26 1813
Linux驱动开发之platform设备驱动实验【附有完整代码】
platform平台设备_railroadzts_q_linux驱动_platform驱动_
10-03
在“platform驱动”中，有以下几个关键函数值得注意： - platform_driver_register()：注册平台驱动。 - platform_driver_unregister()：注销平台驱动。 - platform_device_register()：注册平台设备。 - platform_...
Linux设备驱动+platform驱动框架示例代码
11-17
本资源提供的"Linux设备驱动+platform驱动框架示例代码"旨在帮助开发者理解和学习如何编写针对这类设备的驱动程序。 平台驱动通常涉及以下关键知识点： 1. **平台设备（Platform Device）**：这是Linux内核中用于...
linux驱动学习（六） 应用中的linux驱动 platform_device
emowuyi
10-26 184
一个现实的linux设备和驱动通常要挂接在一种总线上，像pci，usb，iic，spi等都是总线结构，这当然不是问题，但是嵌入式系统中，Soc系统集成的独立外设控制器，挂接在soc内存空间的外设等却不依附于此类总线。 基于这个背景，linux发明了一种虚拟总线：platform总线，相应的设备称为platform_device，而驱动成为platform_driver。 注意，pl...
linux中的platform设备
边缘之火
05-15 467
linux中有一类设备，platform 。平台设备，或者说是总线，在将linux移植到mini2440上时，在mach-mini2440.c中有这样一段代码 static struct platform_device *mini2440_devices[] __initdata = {  &s3c_device_usb,  &s3c_device_rtc,  &s3c_device_lc
Linux下platform驱动简介
wojiaxiaohuang2014的博客
03-13 542
Linux下platform驱动简介
Linux中Platform设备驱动
好学力行
06-05 664
一般情况下，linux设备和驱动都需要挂接在一种总线上，除了本身依附于PCI、USB、I2C、SPI等总线的设备，在嵌入式系统中，SoC系统中集成的独立的外设控制器、挂接在SoC内存空间的外设等外设的驱动不能使用上述的总线。所以，linux新增了一种虚拟的总线，称为platform总线。 相应的外设称为platform_device。
Linux设备模型(十一) - platform设备
滴水藏海
03-03 1354
在Linux2.6以后的设备驱动模型中，需关心总线、设备和驱动这3个实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反的，在系统每注册一个设备的时候，会寻找与之匹配的设备，而匹配由总线完成。一个现实的Linux设备和驱动通常都需要挂接在一种总线上，而对于本身依附于PCI、USB、I2C、SPI等的设备而言，这自然不是问题，但是在嵌入式系统里面，在SoC系统中集成的独立外设控制器、挂接在SoC内存空间的外设等却不依附于此类总线。基于这一背景，Linux。
Linux驱动-platform驱动模型
weixin_47491758的博客
06-03 903
Linux-驱动开发-platform驱动模型
Linux驱动_Platform平台驱动
qq_42174306的博客
02-19 4559
在Linux操作系统中，驱动程序占用了Linux内核代码量的大头，如果不进行管理，将会造成数量庞大的结果。因此引入了驱动的分离。 上图所示就是驱动的分离，相当于驱动使用标准方法去获取到设备信息(比如从设备树中获取到设备信息)，然后根据获取到的设备信息来初始化设备。 这样就相当于驱动只负责驱动，设备只负责设备，想办法将两者进行匹配即可。这个就是 Linux 中的总线(bus)、驱动(driver)和设备(device)模型，也就是常说的驱动分离。总线就是驱动和设备信息的月老...
＜Linux开发＞驱动开发 -之-platform 驱动
qq_39257814的博客
06-18 1283
在前面几篇文章讲解分析编写的设备驱动是相对简单，都是对 IO进行最简单的读写操作。那么如果像I2C、SPI、LCD 等，这类比较复杂外设的驱动就不能这么去写了，如果每一个I2C芯片都单独写一个I2C驱动对应IO的话，这样内核代码会很累赘，所以Linux 系统要考虑到驱动的可重用性，因此提出了驱动的分离与分层这样的软件思路，在这个思路下诞生了platform 设备驱动，也叫做平台设备驱动。本文主要分析一下 Linux 下的驱动分离与分层，以及 platform 框架下的设备驱动该如何编写。
深入理解Linux设备模型与Platform驱动开发
"该课程主要围绕Linux设备模型及Platform驱动展开，旨在帮助学习者理解Linux设备模型的内容和重要性，掌握设备模型驱动的编写技巧，并专门探讨Platform设备驱动的实现方法。课程分为三个章节：Linux设备模型、Linux...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值