一  
    
    
    
、pinctrl 和gpio子系统

pinctrl子系统

借助pinctrl子系统来设置一个PIN的复用（用作什么功能和电气属性）

pinctrl_test: testgrp { fsl,pins = < //下面这句话是描述这个pin的设置信息  
    
    
    
，也就是需要设置成什么样子 MX6UL_PAD_GPIO1_IO00__GPIO1_IO00 0x10B0 /*config 是具体设置值*/ >; }

  MX6UL_PAD_UART1_RTS_B__GPIO1_IO19         0x0090 0x031C 0x0000 0x5 0x0

< mux_reg     conf_reg   input_reg       mux_mode  input_val>

  0x0090        0x031C    0x0000           0x5              0x0

IOMUXC父节点首地址0x020e0000

     


     


     


，因此UART1_RTS_B这个PIN的mux寄存器地址 就是：0x020e0000+0x0090=0x020e 0090    
    
    
。

conf_reg：0x020e0000+0x031C=0x020e 031C 




 




 




 ，这个寄存器就是UART1_RTS_B的电气属性配置寄存器   


     


     


     。

input_reg  

   

   

   
，便宜为0

     

     

     

，表示UART1_RTS_B这个PIN没有input功能



 




 




 



。

mux_mode：5表示复用为GPIO1_IO19  




  




  




 ，将其写入0x020e 0090

input_val：就是写入input_reg寄存器的值   

   

   

。

 GPIO子系统

使用gpio子系统来控制gpio  


  


  


  
，控制gpio的输入输出

在设备树中添加设备节点

gpioled { #address-cells = <1>; #size-cells = <1>; compatible = "atkalpha-gpioled"; pinctrl-names = "default"; // pinctrl-0 属性设置 LED 灯所使用的 PIN 对应的 pinctrl 节点 pinctrl-0 = <&pinctrl_led>; 下面这个与gpio子系统有关 //led-gpio 属性指定了 LED 灯所使用的 GPIO
     
     
     
，在这里就是 GPIO1这一组第四个引脚
   




   




   




 ，低电平有效（也急速GPIO1d第三个引脚） led-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>; status = "okay"; };

二

     


     


     


、设备树

设备树就是将关于硬件配置信息的文件独立出去 



 



 



 
，驱动程序中只留下关于硬件的操作

修改设备树

1 




 




 




 、添加pinctrl节点

2  

   

   

   
、添加设备节点

三

     

     

     

、平台总线框架

主机驱动：一般负责对具体设备进行硬件级别的操作                ，然后向外提交api函数接口

    




    




    




 ，主机驱动一般都是开发板厂家写好的

设备驱动：所有的设备驱动都可以调用主机驱动的api函数去实现与外界交互功能

 当我们向系统注册一个驱动的时候















，总线就会在右侧的设备中查找                 ，看看是有没有设备与之匹配的设备

     



     



     



 ，如果有的话就将二者联系起来














，同样的  
    
    
    
，当向系统中注册一个设备的时候

     


     


     


，总线就会在左侧的驱动中查找有没有与之匹配的设备

驱动与设备分离

我们知道设备驱动的分离 




 




 




 ，并且引出了总线  




  




  




 、驱动  


  


  


  
、设备的模型  

   

   

   
，比如i2c
     
     
     
、spi
   




   




   




 、usb等总线    

     

     

    。但是在soc中有些外设没有这个概念

     

     

     

，但是我们有想使用这个模型  




  




  




 ，Linux提出了platform这虚拟总线  


  


  


  
，于是就对应的platfor_driver和platform_device

 当我们向系统注册一个驱动的时候
     
     
     
，总线就会在右侧的设备中查找
   




   




   




 ，看看有没有与之匹配

的设备 



 



 



 
，如果有的话就将两者联系起来




  




  




  


。同样的                ，当向系统中注册一个设备的时候

    




    




    




 ，总线就会在左侧的驱动中查找看有没有与之匹配的设备















，有的话也联系起来  


  


  


。Linux 内核中大量的驱动程序都采用总线 



 



 



 
、驱动和设备模式                 ，我们一会要重点讲解的 platform 驱动就是这一思想下的产物     
     
     
   。

1                、platform总线

Linux系统内核用bus_type结构体表示总线

bus_type结构体中 platform_match函数负责驱动与设备的匹配

struct bus_type platform_bus_type = { .name = "platform", .dev_groups = platform_dev_groups, .match = platform_match, .uevent = platform_uevent, .pm = &platform_dev_pm_ops, }

2

    




    




    




 、platform驱动

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; //这个结构体变量中包含了设备树匹配的of_match_tableha函数 const struct platform_device_id *id_table; //无设备树匹配 bool prevent_deferred_probe; }

 第二行： probe 函数

     



     



     



 ，当驱动与设备匹配成功以后 probe 函数就会执行














，probe函数就是负   责注册驱动设备到内核的哪些东西

 第 七 行   driver 成员  
    
    
    
，该结构体中包含了设备树匹配的of_match_table函数

 第八行 ：id_table  用在与无设备树匹配

   注意：在无设备树的时候platform_driver name 和 platfor_device  compliate属性 对应就可以匹配上

struct device_driver {    const struct of_device_id *of_match_table; //设备树匹配 }

驱动入口函数里面调用的platform_driver_register函数向Linux内核注册一个platform驱动

驱动卸载函数里面调用platform_driver_unregister函数卸载platform驱动

编写platform驱动需要的一些东西

0















、寄存器地址定义                 、因为这里是用地址映射

     


     


     


，用虚拟地址进行操作 //传统字符设备驱动

1

     



     



     



 、设备结构体

2














、设备具体操作函数

3  
    
    
    
、字符设备驱动操作集（file_operations）

4

     


     


     


、platform驱动的probe函数 




 




 




 ，驱动与设备匹配后此函数就会执行（注册字符设备驱动  

   

   

   
，初始化设备（寄存器地址映射 




 




 




 、设备））

5  

   

   

   
、remove（）（卸载字符设备驱动

     

     

     

，取消寄存器地址映射）

6

     

     

     

、匹配列表（如果使用设备树的话通过此匹配表进行驱动匹配）

7  




  




  




 、platform平台驱动结构体（其中包含name（其中name移动要和设备字段相对应）  




  




  




 ，匹配列表  


  


  


  
，probe和remove）

8  


  


  


  
、驱动模块的加载/卸载

三
     
     
     
、设备树

platform_devices和设备里面具体的节点功能是一样的
     
     
     
，所以说如果有设备树
   




   




   




 ，就没必要整个platform_devices




   




   




   

。在编写基于设备树的platform驱动我们需要注意以下几点：

1.在设备树中创建设备节点

2.编写platform要注意兼容属性

这里需要注意 



 



 



 
，我们就是用

设备节点的compatible属性：“atkalpha-gpioled  
    
    
    
”和platform驱动的of_match_table属性表中compatible属性：

     


     


     


”atkalpha-gpioled"来进行匹配的