瑞芯微RK3568芯片是一款定位中高端的通用型SOC,采用22nm制程工艺,搭载一颗四核Cortex-A55处理器和Mali G52 2EE 图形处理器。RK3568 支持4K 解码和 1080P 编码,支持SATA/PCIE/USB3.0 外围接口。RK3568内置独立NPU,可用于轻量级人工智能应用。RK3568 支持安卓 11 和 linux 系统,主要面向物联网网关、NVR 存储、工控平板、工业检测、工控盒、卡拉 OK、云终端、车载中控等行业。
【公众号】迅为电子
【粉丝群】824412014(加群获取驱动文档+例程)
【视频观看】嵌入式学习之Linux驱动(第十三篇 输入子系统_全新升级)_基于RK3568
【购买链接】迅为RK3568开发板瑞芯微Linux安卓鸿蒙ARM核心板人工智能AI主板
第143章 多对多的匹配关系分析
143.1 joydev.c事件处理层匹配分析
drivers/input/joydev.c文件的input_handler结构体内容如下所示:
static struct input_handler joydev_handler = {
.event = joydev_event,
.match = joydev_match,
.connect = joydev_connect,
.disconnect = joydev_disconnect,
.legacy_minors = true,
.minor = JOYDEV_MINOR_BASE,
.name = "joydev",
.id_table = joydev_ids,
};
static int __init joydev_init(void)
{
return input_register_handler(&joydev_handler);
}
与上面讲解的通用设备驱动层evdev.c的evdev_handler结构体不同的是,joydev_handler结构体中有着对应的匹配函数,也就是说当设备驱动层与事件处理层进行匹配的时候,需要joydev_ids结构体数组和相应的匹配函数共同决定,首先来看joydev_ids结构体,joydev_ids结构体内容如下所示:
static const struct input_device_id joydev_ids[] = {
// 第一个标识符,匹配X轴(ABS_X)的绝对事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_ABSBIT,
.evbit = { BIT_MASK(EV_ABS) }, // 匹配的事件类型是EV_ABS(绝对事件)
.absbit = { BIT_MASK(ABS_X) }, // 匹配的绝对事件类型是ABS_X(X轴)
},
// 第二个标识符,匹配Z轴(ABS_Z)的绝对事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_ABSBIT,
.evbit = { BIT_MASK(EV_ABS) }, // 匹配的事件类型是EV_ABS(绝对事件)
.absbit = { BIT_MASK(ABS_Z) }, // 匹配的绝对事件类型是ABS_Z(Z轴)
},
// 第三个标识符,匹配滚轮(ABS_WHEEL)的绝对事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_ABSBIT,
.evbit = { BIT_MASK(EV_ABS) }, // 匹配的事件类型是EV_ABS(绝对事件)
.absbit = { BIT_MASK(ABS_WHEEL) }, // 匹配的绝对事件类型是ABS_WHEEL(滚轮)
},
// 第四个标识符,匹配油门(ABS_THROTTLE)的绝对事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_ABSBIT,
.evbit = { BIT_MASK(EV_ABS) }, // 匹配的事件类型是EV_ABS(绝对事件)
.absbit = { BIT_MASK(ABS_THROTTLE) }, // 匹配的绝对事件类型是ABS_THROTTLE(油门)
},
// 第五个标识符,匹配游戏杆(BTN_JOYSTICK)的按键事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT,
.evbit = { BIT_MASK(EV_KEY) }, // 匹配的事件类型是EV_KEY(按键事件)
.keybit = { [BIT_WORD(BTN_JOYSTICK)] = BIT_MASK(BTN_JOYSTICK) }, // 匹配的按键类型是BTN_JOYSTICK(游戏杆)
},
// 第六个标识符,匹配游戏手柄(BTN_GAMEPAD)的按键事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT,
.evbit = { BIT_MASK(EV_KEY) }, // 匹配的事件类型是EV_KEY(按键事件)
.keybit = { [BIT_WORD(BTN_GAMEPAD)] = BIT_MASK(BTN_GAMEPAD) }, // 匹配的按键类型是BTN_GAMEPAD(游戏手柄)
},
// 第七个标识符,匹配快乐键(BTN_TRIGGER_HAPPY)的按键事件
{
.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
INPUT_DEVICE_ID_MATCH_KEYBIT,
.evbit = { BIT_MASK(EV_KEY) }, // 匹配的事件类型是EV_KEY(按键事件)
.keybit = { [BIT_WORD(BTN_TRIGGER_HAPPY)] = BIT_MASK(BTN_TRIGGER_HAPPY) }, // 匹配的按键类型是BTN_TRIGGER_HAPPY(快乐键)
},
{ } /* 终止项 */
};
结构体input_device_id的作用是描述输入设备的特征,以便内核能够识别和匹配正确的驱动程序。在通用设备驱动层evdev.c中的evdev_ids结构体数组设置的是driver_info表示匹配全部设备,而joydev.c中的joydev_ids结构体数组包含以下字段:
(1)flags:标识符的标志位,用于指定匹配方式。在这里,使用flags字段的INPUT_DEVICE_ID_MATCH_EVBIT和INPUT_DEVICE_ID_MATCH_ABSBIT标志表示匹配事件类型和绝对事件类型。
(2)evbit:事件类型的位掩码,用于指定要匹配的事件类型。在这里,evbit字段的位掩码表示匹配的事件类型是EV_ABS(绝对事件)或EV_KEY(按键事件)。
(3)absbit:绝对事件类型的位掩码,用于指定要匹配的绝对事件类型。在这里,absbit字段的位掩码表示匹配的绝对事件类型是ABS_X(X轴)、ABS_Z(Z轴)、ABS_WHEEL(滚轮)或ABS_THROTTLE(油门)。
(4)keybit:按键类型的位掩码,用于指定要匹配的按键类型。在这里,keybit字段的位掩码表示匹配的按键类型是BTN_JOYSTICK(游戏杆)、BTN_GAMEPAD(游戏手柄)或BTN_TRIGGER_HAPPY(快乐键)。
这个结构体数组中的每个元素都描述了一种输入设备的特征,包括事件类型和按键类型。内核可以使用这些标识符来匹配输入设备并加载适当的驱动程序,以便正确解析和处理设备的输入数据。
然后来看相应的匹配链接相关的函数,具体内容如下所示:
static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
const struct input_device_id *id;
int error;
// 通过输入设备和处理程序的匹配函数来确定是否适用于该设备
id = input_match_device(handler, dev);
if (!id)
return -ENODEV;
// 调用处理程序的连接函数来建立设备和处理程序之间的连接
error = handler->connect(handler, dev, id);
if (error && error != -ENODEV)
pr_err("failed to attach handler %s to device %s, error: %d\n",
handler->name, kobject_name(&dev->dev.kobj), error);
// 如果连接失败且错误码不是-ENODEV,则打印错误消息
return error;
}
第7行通过input_match_device函数,进行输入设备和处理程序的匹配,input_match_device函数内容如下所示:
static const struct input_device_id *input_match_device(struct input_handler *handler, struct input_dev *dev)
{
const struct input_device_id *id;
// 遍历处理程序的输入设备ID表,直到找到匹配的ID或遍历完所有ID为止
for (id = handler->id_table; id->flags || id->driver_info; id++) {
// 使用输入设备ID匹配函数判断给定的输入设备是否与当前ID匹配
if (input_match_device_id(dev, id) &&
(!handler->match || handler->match(handler, dev))) {
// 如果输入设备与ID匹配,并且处理程序的匹配函数返回true(或者没有匹配函数),则返回该ID
return id;
}
}
return NULL;
}
在6-13行的for循环中首先会依次取出id_table的值,即上面讲解的joydev_ids结构体数组中的值,一一进行匹配,在for循环中由于每个joydev_ids结构体数组中都存在flags参数且值不为零,所以for循环的条件是成立的,在for循环中会调用input_match_device_id函数判定给定的输入设备是否与当前ID匹配,input_match_device_id函数内容如下所示:
bool input_match_device_id(const struct input_dev *dev,
const struct input_device_id *id)
{
// 检查设备的总线类型是否匹配
if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)
if (id->bustype != dev->id.bustype)
return false;
// 检查设备的厂商ID是否匹配
if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
if (id->vendor != dev->id.vendor)
return false;
// 检查设备的产品ID是否匹配
if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
if (id->product != dev->id.product)
return false;
// 检查设备的版本号是否匹配
if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
if (id->version != dev->id.version)
return false;
// 检查设备的事件位图是否是给定ID的子集
if (!bitmap_subset(id->evbit, dev->evbit, EV_MAX) ||
!bitmap_subset(id->keybit, dev->keybit, KEY_MAX) ||
!bitmap_subset(id->relbit, dev->relbit, REL_MAX) ||
!bitmap_subset(id->absbit, dev->absbit, ABS_MAX) ||
!bitmap_subset(id->mscbit, dev->mscbit, MSC_MAX) ||
!bitmap_subset(id->ledbit, dev->ledbit, LED_MAX) ||
!bitmap_subset(id->sndbit, dev->sndbit, SND_MAX) ||
!bitmap_subset(id->ffbit, dev->ffbit, FF_MAX) ||
!bitmap_subset(id->swbit, dev->swbit, SW_MAX) ||
!bitmap_subset(id->propbit, dev->propbit, INPUT_PROP_MAX)) {
return false;
}
// 所有匹配条件都满足,返回true
return true;
}
在5、10、15、20行的if判断中,由于flags的值和后面的宏都不为零,所以if判断都是成立的,但是第6、11、16、21四行中,dev->id在我们编写的最简单设备驱动层代码中并没有赋值,所以值为零,而在joydev.c中id->bustype、id->vendor、id->product和id->version同样没有赋值,所以值同样为0,所以第二层if判断不成立。
然后来看25-36行的if判断,bitmap_subset在上面讲解过,它是一个内联函数,用于判断两个位图是否具有子集关系,这时就需要用到上面讲解的joydev_ids结构体数组的描述特征了。在编写的最简单的设备驱动层代码中的设置如下所示:
__set_bit(EV_KEY, myinput_dev->evbit); // 设置支持按键事件
__set_bit(KEY_1, myinput_dev->keybit); // 设置支持按键1
结合joydev_ids结构体数组的描述特征来对比,在上述的if判断中并不能与之匹配,所以最终会返回false,导致匹配失败。
讲解joydev.c的目的是让了解匹配规则是有多种多样的,对设备驱动层和事件处理层的知识重新进行梳理,在下次遇到相似的情况时可以自行分析。
143.2 扩展:多对多匹配关系
143.2.1 内核源码修改
首先对内核源码进行修改,修改涉及到两个函数分别是input_match_device_id函数和input_match_device函数,修改完成的代码内容如下所示:
bool input_match_device_id(const struct input_dev *dev,
const struct input_device_id *id)
{
if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)
if (id->bustype != dev->id.bustype)
return false;
if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
if (id->vendor != dev->id.vendor)
return false;
if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
if (id->product != dev->id.product)
return false;
if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
if (id->version != dev->id.version)
return false;
if (!bitmap_subset(id->evbit, dev->evbit, EV_MAX) ||
!bitmap_subset(id->keybit, dev->keybit, KEY_MAX) ||
!bitmap_subset(id->relbit, dev->relbit, REL_MAX) ||
!bitmap_subset(id->absbit, dev->absbit, ABS_MAX) ||
!bitmap_subset(id->mscbit, dev->mscbit, MSC_MAX) ||
!bitmap_subset(id->ledbit, dev->ledbit, LED_MAX) ||
!bitmap_subset(id->sndbit, dev->sndbit, SND_MAX) ||
!bitmap_subset(id->ffbit, dev->ffbit, FF_MAX) ||
!bitmap_subset(id->swbit, dev->swbit, SW_MAX) ||
!bitmap_subset(id->propbit, dev->propbit, INPUT_PROP_MAX)) {
printk("input dev is error %s\n", dev->name);
return false;
}
printk("input dev is ok %s\n", dev->name);
return true;
}
EXPORT_SYMBOL(input_match_device_id);
static const struct input_device_id *input_match_device(struct input_handler *handler,
struct input_dev *dev)
{
const struct input_device_id *id;
printk("handler name is %s\n", handler->name);
for (id = handler->id_table; id->flags || id->driver_info; id++) {
if (input_match_device_id(dev, id) &&
(!handler->match || handler->match(handler, dev))) {
return id;
}
}
return NULL;
}
相较于原函数只是在第30、33和42三行添加了printk打印,目的是在匹配过程中通过打印更好的了解匹配流程,由于修改的是内核源码,所以需要在修改之后重新编译内核源码,并将编译完成后生成的boot.img内核镜像烧写到开发板上。
注:joydev事件处理层代码在内核中默认是没有勾选的,需要根据输入子系统的裁剪和配置相关章节对内核的默认配置文件进行修改,勾选"Joystick interface"选项即可,勾选完成如下所示:
修改编译完成的boot.img内核镜像的网盘路径为“iTOP-RK3568开发板【底板V1.7版本】\03_【iTOP-RK3568开发板】指南教程\02_Linux驱动配套资料\04_Linux驱动例程\92_myinput_dev_02\01_img”,如下图所示:
143.2.2 运行测试
本节测试仍旧使用前面编写的最简单的设备驱动层的ko文件,需要注意的是要想得到跟实验效果相同的结论,必须已经按照上一小节的操作修改过了内核源码,并重新烧写到了开发板上。
开发板上电正常启动之后如下所示:
由于myinput_dev.ko在之前已经拷贝到了开发板上,所以这里可以直接使用下面的命令加载myinput_dev.ko文件,打印内容如下所示:
insmod myinput_dev.ko
其中红色框中的是joydev相关的打印,可以看到joydev是匹配失败的,证明在第一小节中我们的推理是正确的,而红色框下方的蓝色框中的是evdev通用设备驱动层程序,根据打印可以看到evdev匹配成功了,这时候细心的小伙伴可能发现了,除了evdev之外还有kbd、cpufreq_interactive和dmcfreq也匹配成功了,这是为什么呢?
143.2.3 结论
在输入子系统中,输入设备和输入处理器之间的关系是多对多的。这意味着一个输入设备可以与多个输入处理器关联,而一个输入处理器也可以处理多个输入设备的事件。
这种多对多的关系设计是为了提供更大的灵活性和可扩展性。不同的输入设备可能具有不同的特性和事件类型,而不同的输入处理器可能针对特定的事件类型提供不同的处理逻辑。通过将输入设备和输入处理器解耦并建立多对多的关系,可以使输入子系统更加灵活,可以根据需求将特定的输入设备与适合的输入处理器进行匹配,以实现定制化的事件处理。例如,对于鼠标输入设备,它可以产生鼠标移动事件、鼠标点击事件和滚轮滚动事件等,对于键盘输入设备,它可以产生按键事件,包括按下和释放按键的事件。
所以在上个小节中最简单的设备驱动层代码会跟内核中全部的事件处理层想匹配,最终匹配成功了evdev、kbd、cpufreq_interactive和dmcfreq四个事件处理层程序。