LCD/HDMI OUT调试经验（1）------驱动软件架构

因为调试的平台是高通，所以只介绍关于高通平台的软件架构，以下总结基于我的调试经验，与专业总结会有差距。

一、高通平台驱动文件架构

上图为目前我所接触到最多的文件架构，高通平台的代码有很多，作为初级bsp工程师暂时无需了解其余文件，主要是kernel中的driver、Makefile以及设备树。基本的配置步骤是：设备树->bp->驱动文件。在设备树先添加自己所需节点与设备信息，在bp修改一些权限之类的配置辅助驱动申请，再去添加或者修改驱动文件编译。

（1）设备树的解析

它是一种dtsi或者dts的文件类型，位置一般为kernel/msm/arch/arm64/boot/dts/qcom或者vendor/qcom/proprietary/devicetree/qcom；文件中的内容也呈现树形结构，又因为定义了各种设备的信息所以叫设备树。

不像大学写的C语言demo只需要依赖一些库文件，驱动工程类的代码里还需要依赖设备树。一般的驱动.c文件中不会有具体的设备信息，比如9211芯片的pin脚不会直接在c文件定义，而是存储在设备树文件中，等编到驱动（也就是编译到.c文件）时，再去设备树文件中获取信息。高通平台有相关接口来实现，了解这个概念就行，下面我们来举个例子。

以lt9611芯片为例：

该文件位置为kernel/msm/arch/arm64/boot/dts/qcom/sdm845-mtp.dtsi

打开该文件其他的先不用看，先找到这些9611芯片的配置。从硬件原理图与芯片数据手册提炼的有用信息都在这里。学过数据结构的应该知道，这是一个树形结构，即上图中有多少组括号就有多少层树，qupv3_se0_i2c是一个i2c的根节点，它有一个lt9611的子节点，lt9611节点中又有compatible和reg等内容，这些内容就是驱动代码里面主要解析的。

了解了它的结构后继续看他里面具体内容是什么意思，其实从起的名字来看就很好理解。最重要的是compatible这个属性，因为有很多.c的驱动文件在driver中，.c驱动文件需要通过匹配compatible来决定获取哪个设备树信息，如下图。

 在9611的驱动中有这样一个结构体存储了compatible，因为它的值和上面设备树中的compatible一样，所以这个驱动在运行解析的时候就回去解析上面设备树的文件，比如：

在9611驱动文件中有这样一句话，不用管其他的看到函数有个参数为hdmi-lvds-switch意思就是去获取设备树中的名称叫hdmi-lvds-switch的内容，我们在设备树定义了hdmi-lvds-switch为<&tlmm 42 0>；其实就是把这个内容赋值给了hdmi_lvds_switch_gpio，相当于是

#define pdata->hdmi_lvds_switch_gpio  42

这样一句话，至于为什么是42不是<&tlmm 42 0>，记住就行了，之后会讲。

设备树是一种非常方便且规范的信息配置文件，一是因为它和宏定义一样，硬件上有修改只需要改一个数字就行，使代码具有健壮性与可移植性。二是设备树我觉得是一种具有设备概念的文件，一组设备树配置就代表了一块芯片，而宏定义没有这样的意思。

关于设备树只需要了解设备树与驱动文件怎么交互的就行，具体的实现代码先不看，具体怎么配置设备树也先不看。

（2）Makefile文件

 字面意思就可以理解，这是决定编译的文件。在每一个驱动文件夹甚至其他文件夹都会有Makefile

上图是最规范的写法，每一行的意思都是一样的，看9611_v1那一行的意思翻译一下就是：

如果CONFIG_DRM_LT_LT9611为y，那我就编译该文件夹下面的lt9611_v1.c，以lt9611_v1.o的形式生成编译结果。在哪定义CONFIG_DRM_LT_LT9611这个东西？

还是以9611为例，文件位置为kernel\msm-4.9\arch\arm64\configs\sdm845_defconfig和sdm845-perf_defconfig，打开他们就可以定义上述变量为y了，如果不定义就不会编译9611。具体到时候是configs下的哪个文件需要问别人。

还有一种比较懒的方式：

直接等于y，就不用那些定义了，但是这只是自己调试时写写，提交代码还需要符合规范。

 （3）其他驱动文件

 在driver那个目录下有很多驱动，具体配置到哪个驱动文件中可以问别人或者看提交记录，一般来说，都是一份驱动文件对应一个Makefile编译语句，对应一组设备树配置。

（4）BP侧的一些配置文件

bp接触的不是特别多，只有在遇到申请权限以及需要开机就上电这些问题时需要配置到，boot中的一些文件需要关注，因为这边的操作在机器一上电就会实现，具体之后也会涉及。

二、驱动代码结构

如何分析一份驱动对之后的调试和功能完善都很有帮助，高通平台驱动和普通的c语言demo不太一样，学校所学的c语言demo一般都是从main函数开始跑，但是驱动文件里从probe函数开始，作用和main函数差不多。

以9611驱动为例，我们来了解一下这份驱动的结构，学会一份驱动，其他的都是大差不差。

首先是包含一些库函数，定义一些需要用到的宏，这些无关紧要，一些参数和大部分代码都会提供。

 然后是定义结构体和枚举类型数据，这里的结构体可以看作实现一组功能的信息或者直接当成一块芯片的信息，比如lt9611这个结构体，里面存放一些芯片的信息。lt9611_reg_cfg和lt9611_video_cfg这些结构体都是存储一些配置信息，如地址显示器分辨率等等，一般用这两个结构体实现一些功能。这部分主要是对结构体理解到位就行，不用在意结构体里面的细节，下面probe函数中会具体说明。

中间定义的所有功能函数先不看具体操作，明白里面在干什么就行，其他功能函数就不截图了。

下面是最重要的probe函数：

probe函数就是main函数，进这个文件先执行probe，上面说到lt9611的结构体存储芯片的信息，那进probe后先得定义一个9611的设备结构体，这个结构体一旦定义就只代表你机器上的那块芯片了，下面所有对该结构体的操作，实际都是在对你机器上的芯片进行操作。接下来是很常规的分配设备的内存，解析设备树函数和其他各种功能函数了。

 在驱动的最后是该驱动的设备注册以及注销的函数，不用管它，大部分驱动都是这个结构。等之后的一些功能调试会涉及。

所以这样看来一份驱动的结构很明朗了，probe函数就是main函数，进去先定义自己的设备，再对设备进行一系列操作，呈现分-总结构。之后的所有功能添加，都直接从probe函数先分析，再去找到对应功能函数添加功能即可。

三、总结

本章主要介绍高通平台LCD/HDMI OUT调试的一些文件架构以及具体驱动的结构，高通平台的文件架构其实也比较清晰，大部分只需要接触AP侧的driver与设备树，BP侧的boot；最后举例的9611驱动呈现分-总的结构，按照这样的方式入手分析驱动应该更简单一些。

在中间又具体介绍了其中的设备树文件、Makefile和一些配置文件，有个大概的了解即可，下一章将介绍LCD/HDMI OUT在开机时的运行流程。