bruk_spp的博客

最近在工作中遇到了gpio解析失败的问题，跟踪发现设备树配置的字符串不匹配，在这里再次学习并记录下。

源码路径：bionic/libc/arch-arm64/bionic/syscall.Smov x8, x0mov x0, x1mov x1, x2mov x2, x3mov x3, x4mov x4, x5mov x5, x6svc #0ret路径：bionic/libc/include/bits/glibc-syscalls.h#endif#endif#endif#endif#endif#endif#endif#endif#endif#endif#endif。

首先来看看root节点解析大体调用流程这里只关注具体的解析函数的实现，中间的调用流程可以看上图自行跟踪。

spi回环测试是确认spi通讯是否正常的一个常用手段，硬件上将master的输入、输出口短接即可。软件上主要确认以下几步：1、bootloader阶段的spi使用的几个gpio口复用功能是否配置正确，本人就曾经在工作中遇到过spi控制器，spi dev都正常加载。但就是spi无法回环测试成功，原因就是IO口复用给别的功能了2、确认spi控制器是否正常加载，如果spi控制器都没能正常加载。那么spi相关的dev是无法产生的3、设备树上配置spi相关的设备信息，确保相应的spi能够正常加载。

在用linux mtk8518平台做sourdbar的时候，发现appmain进程和audio进程使用消息队列进行通信，当高频率发送消息时会无规律的漏掉部分消息。现在就带着这个目地来学习下驱动层是如何实现的。

这里最终会调用调度器的回调函数put_prev_task，对于deadline来说这会将当前task进行插入到二叉树当中，因为pick_next_task的时候已经将task从二叉树中删除了，如果没有重新插入二叉树，那么这个task将永远不会运行第二次，对于其它调度器有对应的回调函数。这里需要注意的是对于fair调度器，挑选task是有两个流程的，需要结合fair调度器的相关函数来一起看。本文就schedule函数与各调度器使用逻辑方向来研究学习。TASK_RUNNING状态宏定义为0。

本篇通过几个方面来看deadline调度器：1、deadline的设置2、deadline的任务的添加3、deadline的任务的调度。

上述的流程核心就是创建super_block,并各种初始化填充里面的数据成员，另外一个就是生成root inode。mkdir核心内容是创建一个inode并加入到链表，这个inode节点会被赋值对文件和目录操作的回调函数，这里只看下核心代码。->fc->ops->get_tree //这里就会使用到上述的legacy_fs_context_ops。这个是对目录的操作，文件操作也会走到上面的这个函数拿到inode节点并赋值回调函数。do_new_mount_fc创建一个新的挂载点，这里就详细研究了。

本文从三个方向研究tty设备１、tty驱动的加载2、tty设备的打开3、tty设备的访问。

上面这段代码主要是生成设备，这里需要注意的是cdev设备号与vdev->dev的设备号是一致的。所以上层通过open ioctl来访问/dev/videox，实际操作的是v4l2_fops这个通过回调函数，这个回调函数会调用对应器件驱动提供的fops结构体的回调函数。上面的代码主要是次设备号的确定，主设备号都是81。一般的v4l2驱动程序都会有上面类型的初始化的动作，核心的是fops和ioctl_ops两个回调函数。上面的这段代码看起来是有问题的，如果video_device足够多，会有内存越界的问题。

此源文件里面有个函数mt8518_evb_parse_of会解析dts，并根据里面的配置动态的修改源码里面的结构体数组成员dai_link codec和codec_dai的赋值。其中i2c1挂载了四个，i2c2挂载了1个，共五个器件，i2c1上的器件通过slave地址加以区分，fs2105驱动probe函数会重入5次。Codec _driver是同一个，但是Codec_dai的名字需要彼此区别，所以由frsm_codec_init这个函数代码实现字符串拼接.其中下标由dts配置。是否需要进入睡眠模式。

在card注册的时候，会对已经增加到devices链表上的所有device进行处理，调用其提供的dev_register回调函数。当使用open打开alsa这个字符设备时，会调用上面的open函数，在这里就会把文件操作回调函数替换成snd_ctl_f_ops。到这里就完成了对所有card->devices的处理，实际上会保存到数组中，会后续访问提供支持。看上述代码，这里还有个链表加入的排序动作，根据type来确认的。２、control device的处理。control device的处理。

前言首先：设备树上只要拥有compatible属性的节点，都会自己被添加到platform总线上，保存在device链表中。i2c控制器也是在这个时候被添加的，主板上有几个i2c接口就有几个i2c控制器(adapter)其次：因为控制器device被添加到了platform总线上，所以控制器驱动也需要被注册到platform总线上，使之能匹配到device，驱动很重要的一点就是向i2c总线注册adapter(控制器），调用i2c_add_numbered_adapter接口１.i2c_add_num

中断映射的大体过程如下：先来看一个比较典型的例子，linux驱动开源源码static int bcm2835_mbox_probe(struct platform_device *pdev){ struct device *dev = &pdev->dev; int ret = 0; struct resource *iomem; struct bcm2835_mbox *mbox; mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_K

看linux驱动，发现module_param_string的用法module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);网上查了下，说是为可以在用户空间设置参数。特地的看了下代码实现文件路径：include/linux/moduleparam.h#define module_param_string(name, string, len, perm) \ static const struct kparam_str

platform总线是我们驱动编程中经常用的一种，之间的大体关系如下：１.platform_bus_init　由start_kernel在加载各自init之前调用。主要就是注册一个bus，最终会添加到bus_kset链表中去，总线本身不会涉及到休眠唤醒，其休眠唤醒函数都是一个中间过程。为各自具体的设备驱动准备的。２.platform_device_register如上图描述所示，主要内部逻辑有下：１）：首先将dev添加到devices_kset链表中去２）：其次将dev添加到总线的device

request_threaded_irq先来看头文件的申明。文件：include/linux/interrupt.hextern int __must_checkrequest_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long flags, const char *name, void *dev);static inline int

module_init这个网上讲解的一大堆，这里作个学习记录。首先module_init的定义是在文件：include/linux/module.h下面来看看具体定义#ifndef MODULE#define module_init(x) __initcall(x);#define module_exit(x) __exitcall(x);#else /* MODULE */#define early_initcall(fn) module_init(fn)#define core_

在读kernel代码时候又一次碰到early_param这个调用，网上查了下大体和__setup函数作用是一样的，都是在驱动起来后很早加载其回调函数，用来作一些早期的初始化。一直没注意其实现的逻辑过程，只知道应该这样用。现在来看看其到底是如何实现的。先来看看一个序列图，比较简单：上面的序列图调用过程会显得比较简单，逻辑并不复杂。由bootloader拉起start_kernel开始进行驱动加载，在加载moudle_init各种驱动之前会处理__setup和early_param这两种结构，如下图：

１各个源文件具体位置main.c : linux-4.5-rc1\init\main.csetup.c :linux-4.5-rc1\arch\arm64\kernel\setup.cinit.c :linux-4.5-rc1\arch\arm64\mm\init.cmemblock.c :linux-4.5-rc1\mm\memblock.cfdt.c :linux-4.5-rc1\drivers\of\fdt.cof_reserved_me.

１start_kernelstart_kernel是kernel起始的地方，由bootloader拉起来。具体的调用在汇编里面，截取部分代码如下：__mmap_switched: // Clear BSS adr_l x0, __bss_start mov x1, xzr adr_l x2, __bss_stop sub x2, x2, x0 bl __pi_memset adr_l sp, initial_sp, x4 mov x4, sp and x4, x4, #~(THRE.

１.video_device的初始化static struct video_device viu_template = { .name = "FSL viu", .fops = &viu_fops, .minor = -1, .ioctl_ops = &viu_ioctl_ops, .release = video_device_release, .tvnorms = V4L2_STD_NTSC_M | V4L2_STD_PAL,};一般我们使用上.

在内核种，有各种各样的器件。有时候各个器件之间需要通信或者交互，我把它称为模块间通信。实际上在写Ｃ的应用代码时候，这种技术经常用到。但是写应用程序一般不会涉及到内存屏障。１.Notifier Chain各种结构介绍来看下结构体定义：struct notifier_block { notifier_fn_t notifier_call; //回调函数 struct notifier_block __rcu *next; //指向下一个结构体 int priority; //优先级别

首先来一幅lsm的逻辑图：上幅图来至：Linux Security Module Framework一文，很清晰的描述了LSM的逻辑，从用户空间到系统调用再到selinux模块接口。selinux驱动模块位置： \linux-4.5-rc1\security1.selinux核心驱动的加载１)selinux文件节点的创建： 在selinuxfs.c文件中，__initcall(init_sel_fs)驱动模块的加载，会注册文件节点。这些节点作为内核与用户空间通信的接口。其核心API调用