精华内容
下载资源
问答
  • 整理--Linux驱动框架概念之LED

    千次阅读 2017-01-29 01:28:17
    知识整理Linux驱动框架入门之LED 驱动框架;驱动框架也用模块这种’机制’实现;驱动框架是内核开发人员提供,属于整个驱动的一部分

    知识整理–Linux驱动框架概念之LED

    驱动框架也用模块这种’机制’实现,为了在不需要的时候也能够卸载

    何谓驱动框架

    什么是驱动框架,为什么需要驱动框架,基于驱动框架写驱动有什么优势

    驱动编程协作要求:(1)接口标准化;(2)尽量降低驱动开发者难度

    什么是驱动框架:标准化的驱动实现``统一管控系统资源,维护系统稳定

    (1)内核中驱动部分维护者针对每个种类的驱动设计一套成熟的、标准的、典型的驱动实现,并把不同厂家的同类硬件驱动中相同的部分抽出来自己实现好,再把不同部分留出接口给具体的驱动开发工程师来实现,这就叫驱动框架。

    譬如LED 亮灭肯定都会有,这就是同类硬件的相同部分,用内核开发工程师开发的这套成熟的、标准的、典型的驱动去实现。
    A厂家的LED能调亮度,B厂家的LED就只有亮灭,那A厂家的调亮度就是同类硬件的不同部分,驱动工程师就要在基本的驱动实现上去添加
    

    (2)内核维护者在内核中设计了一些统一管控系统资源的体系,这些体系让内核能够对资源在各个驱动之间的使用统一协调和分配,保证整个内核的稳定健康运行。譬如系统中所有的GPIO就属于系统资源,每个驱动模块如果要使用某个GPIO就要先调用特殊的接口先申请,申请到后使用,使用完后要释放。又譬如中断号也是一种资源,驱动在使用前也必须去申请。其他比如框架中的设备锁等。这些也是驱动框架的组成部分

    (3)一些特定的接口函数、一些特定的数据结构,这些是驱动框架的直接表现。

    驱动框架这个概念单靠文字说明很难理解,应在实际驱动编程中去体会上面的这几点

    LED驱动框架分析

    内核驱动框架中LED的基本情况

    开始一件事,不盲目,简单分析后再去分析源码。像分析uboot和kernel先看地图(Makefile)那样

    相关文件:
    (1)drivers/leds目录,这个目录就是驱动框架规定的LED这种硬件的驱动应该待的地方。
    (2)led-class.c和led-core.c,这两个文件加起来属于LED驱动框架的第一部分,这两个文件是内核开发者提供的,他们描述的是内核中所有厂家的不同LED硬件的相同部分的逻辑。必要的需要花时间的就是内核提供的led-class.c和led-core.c文件。
    (3)leds-xxxx.c,这个文件是LED驱动框架的第2部分,是由不同厂商的驱动工程师编写添加的,厂商驱动工程师结合自己公司的硬件的不同情况来对LED进行操作,使用第一部分提供的接口来和驱动框架进行交互,最终实现驱动的功能。

    我自己学习使用的开发板是九鼎厂商生产的s5pv210,内核源码树为其提供的linux+qt的kernel
    其(九鼎移植的内核)led驱动没有使用内核推荐的led驱动框架,文件放在放在drivers/char/led/x210-led.c
    

    案例分析驱动框架的使用:
    (1)以leds-s3c24xx.c为例。leds-s3c24xx.c中通过调用led_classdev_register来完成LED驱动的注册,而led_classdev_register是在drivers/leds/led-class.c中定义的。所以其实SoC厂商的驱动工程师是调用内核开发者在驱动框架中提供的接口来实现自己的驱动的。
    (2)驱动框架的关键点就是:分清楚内核开发者提供了什么,驱动开发者自己要提供什么

    典型的驱动开发行业现状:
    (1)内核开发者对驱动框架进行开发和维护、升级,对应led-class.c和led-core.c
    (2)SoC厂商的驱动工程师对设备驱动源码进行编写、调试,提供参考版本,对应leds-s3c24xx.c
    (3)做产品的厂商的驱动工程师以SoC厂商提供的驱动源码为基础,来做移植和调试

    LED驱动框架源码

    涉及到的文件:led-core.c和led-class.c

    经过基本分析经过基本分析,发现LED驱动框架中内核开发者实现的部分主要是led-class.c。
    led-class.c就是一个内核模块,对led-class.c分析应该从下往上,遵从对模块的基本分析方法。
    为什么LED驱动框架中内核开发者实现的部分要实现成一个模块?因为内核开发者希望这个驱动框架是可以被装载/卸载的。
    

    blog009

    subsys_initcall
    点击这里:linux内核段属性机制(以subsys_initcall和module_init为例)

    leds_init
    blog010

    类的创建。leds_init除了对class结构体变量进行赋值,还做了class_create,所以到开发板下 ls /sys/class可以看到多了一个类leds,但是里面是空的。里面的用来与应用层进行交互的文件是驱动程序要去创建的,这就是驱动工程师要做的(用提供的接口去创建)

    led_class_attrs:
    (1)attribute是什么,对应将来/sys/class/leds/xxx目录里的内容,一般是文件和文件夹。这些文件其实就是sysfs开放给应用层的一些操作接口(非常类似于/dev/目录下的那些设备文件)
    (2)attribute有什么用,作用就是让应用程序可以通过/sys/class/leds/xxx目录下面的属性文件来操作驱动进而操作硬件设备。
    (3)attribute其实是另一条驱动实现的路线。有区别于之前讲的file_operations那条线。不同设备驱动实现走的路不一定,像这边的led走的是attribute,而LCD走的是file_operations

    leds_class(class结构体):
    以下文件在/include/linux/device.h

    struct class {
        const char      *name;
        struct module       *owner;
    
        struct class_attribute      *class_attrs;
        struct device_attribute     *dev_attrs;
        struct kobject          *dev_kobj;
    
        int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
        char *(*devnode)(struct device *dev, mode_t *mode);
    
        void (*class_release)(struct class *class);
        void (*dev_release)(struct device *dev);
    
        int (*suspend)(struct device *dev, pm_message_t state);
        int (*resume)(struct device *dev);
    
        const struct kobj_ns_type_operations *ns_type;
        const void *(*namespace)(struct device *dev);
    
        const struct dev_pm_ops *pm;
    
        struct class_private *p;
    };

    唤醒(resume)、挂起(suspend):

    led_classdev_register
    blog011

    属于某一类的设备的创建。分析可知,led_classdev_register这个函数其实就是去创建一个属于leds这个类的一个设备。其实就是去注册一个设备。所以这个函数其实就是led驱动框架中内核开发者提供给SoC厂家驱动开发者的一个注册驱动的接口
    当使用led驱动框架去编写驱动的时候,这个led_classdev_register函数的作用类似于驱动程序使用file_operations方式去注册字符设备驱动时的register_chrdev函数。

    led_classdev:
    以下文件在/include/linux/leds.h

    struct led_classdev {
        const char      *name;
        int          brightness;
        int          max_brightness;
        int          flags;
        ...
        /* Set LED brightness level */
        /* Must not sleep, use a workqueue if needed */
        void        (*brightness_set)(struct led_classdev *led_cdev,
                          enum led_brightness brightness);
        /* Get LED brightness level */
        enum led_brightness (*brightness_get)(struct led_classdev *led_cdev);
        ...
        struct device       *dev;
        struct list_head     node;          /* LED Device list */
        const char      *default_trigger;   /* Trigger to use */
    
        ...
    };
    

    基于驱动框架写LED驱动

    实践之前需要确认内核是否添加led驱动框架支持(通过make menuconfig配置,设置成功后到开发板下ls /sys/class可以看到多了一个类leds 但是里面是空的)

    一般不从零开始写,参考哪里? drivers/leds/leds-s3c24xx.c;
    思路/关键点:led_classdev_register,我们之前写的led驱动,直接看的是内核里面提供的操作接口,譬如register_chardev,cdev结构体等那些
    仍然是驱动模块,module_init(XXX),insmod时会去调用XXX去注册,在xxx模块安装函数中去使用专用的接口

    注:以前看注册成功与否,cat     /proc/devices去看信息变化。现在要看/sys/class/leds 如果注册成功该目录下会多一些文件
    

    示例程序leds-s5pv210.c

    图片.5-2-05

    现象:
    第1:写的驱动能够工作了,被加载了,/sys/class/leds/目录下多出来了一个表示设备的文件夹。文件夹里面有相应的操控led硬件的2个属性brightness和max_brightness
    第2:led-class.c中brightness方法有一个show方法和store方法,这两个方法对应用户在/sys/class/leds/myled/brightness目录下直接去读写这个文件时实际执行的代码。
    show brightness ...时,实际就会执行led_brightness_show函数
    echo 1 > brightness时,实际就会执行led_brightness_store函数

    show方法实际要做的就是读取LED硬件信息,然后把硬件信息返回给用户即可。所以show方法和store方法必须能够操控硬件。但led-class.c文件属于驱动框架中的文件,本身无法直接读取具体硬件,因此在show和store方法中使用函数指针的方式调用了struct led_classdev结构体中的相应的读取/写入硬件信息的方法(在linux/leds.h中,写驱动就一定要包含这个头文件和对应的led_classdev结构体类型变量。当有多个个同类设备(即多个led_classdev结构体类型变量)它是怎么判段的呢?–不难,文章不想写太长,自行分析)(算了还是写一下吧,都整理出来了)。
    struct led_classdev结构体中的实际用来读写硬件信息的函数,就是驱动文件leds-s5pv210.c中要提供的(如示例程序)。

    分析echo 1 > b brightness 是如何传递的:
    p.5-2-06

    在硬件操作上驱动只应该提供机制而不是策略

    在驱动中将4个LED分开,使应用层可以完全按照自己的需要对LED进行控制

    好处:驱动层实现对各个LED设备的独立访问,并向应用层展示出4个操作接口led1、led2、led3、led4,这样应用层可以完全按照自己的需要对LED进行控制。

    驱动的设计理念:不要对最终需求功能进行假定,而应该只是直接的对硬件的操作。有一个概念就是:机制和策略的问题。在硬件操作上驱动只应该提供机制而不是策略。策略由应用程序来做。比如有人要造反,提供枪支弹药这就是机制;比如马克思主义,没有枪支弹药,但是有策略

    将4个LED分开程序:
    leds-s5pv210.c

    总结:LED驱动开发

    不是很复杂的一个框架,多分析思考;关键点:细节另外,要明白写的驱动如何与框架结合(即应用到硬件是怎样的一条路线)

    p.5-2-07

    展开全文
  • linux驱动(一):linux驱动框架

    万次阅读 多人点赞 2017-12-23 11:46:28
    编写linux驱动先看一下驱动框架是什么样子的。 驱动编写和应用层编写有什么区别呢? (一)首先 入口函数的问题。应用层编写我们的入口就是main函数,但在驱动编写时不是这样的,有两种情况, 1、缺省情况下 int...

    编写linux驱动先看一下驱动框架是什么样子的。

    驱动编写和应用层编写有什么区别呢?

    (一)首先 入口函数的问题。应用层编写我们的入口就是main函数,但在驱动编写时不是这样的,有两种情况,

    1、缺省情况下

    int __init init_module(void)  加载模块时的初始化函数,也就是驱动模块的入口函数

    void __exit cleanup_module(void) 卸载模块时的函数,也就是卸载某个驱动时要执行的函数

    2、

    static int __init xxxx_init(void)  加载模块时的初始化函数,也就是驱动模块的入口函数

    static void __exit xxxx_exit(void)  卸载模块时的函数,也就是卸载某个驱动时要执行的函数

    上述两种情况相比,我们一般用第二种,因为第一种的名称是固定的,我们不能做更改,第二种我们可以改写xxxx为我们自己模块的名字。可以达到见文知义。

    在用第二种模式时,我们要首先用固定格式声明一下:

    module_init(xxxx_init);
    module_exit(xxxx_exit);

    来表明加载初始化函数和卸载函数。

    (二)c语言的标准函数库不能使用

            驱动属于内核的一部分,我们此时还无法使用类似像printf这样的c库,但是内核会提供自己的c库,在内核中我们用printk代替printf函数。

    (三)添加LICENSE声明

            linux是开源的系统,那就要我们遵守一定的规范,我们一般用GPL规范,所以在驱动编写时都要声明一下

            MODULE_LICENSE(“GPL”);

    基本的区别就是这些,我们来看一个简单的驱动框架

    #include <linux/init.h>
    #include <linux/module.h>
    #include <linux/kernel.h>
    
    
    MODULE_LICENSE("GPL");
    
    static int __init demo_init(void)
    {
    	printk("%s,%d\n", __func__, __LINE__);
    
    	printk("val:%d\n", obj.val);
    	obj.func();
    
    
    	return 0;
    }
    
    static void __exit demo_exit(void)
    {
    	printk("%s,%d\n", __func__, __LINE__);
    }
    
    module_init(demo_init);
    module_exit(demo_exit);
    完成驱动编写后,如何才能加载到内核呢?我们需要通过Makefile生成.ko文件,一个简单的Makefile如下,这是在ubutnu下的Makefile,如果换为ARM平台下的linux需要更换源文件目录。具体解释可以看内核模块编译makefile入门。执行make即可生成模块.ko文件
    $(warning KERNELRELEASE = $(KERNELRELEASE))
    
    ifeq ($(KERNELRELEASE),)
    
    #内核的源码路径, ?= 条件赋值, uname -r  得到内核的版本号
    KERNELDIR ?= /lib/modules/$(shell uname -r)/build  
    
    # := 立即赋值, 得到当前的绝对路径
    PWD := $(shell pwd)
    
    
    # -C 切换工作路径, make -c
    modules:
    	$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
    
    clean:
    	rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c .tmp_versions Module* modules*
    
    .PHONY: modules  clean
    
    else
    	  # 生成模块
           obj-m := used.o 
    	
    endif
    
    


    下面我们来看几个驱动中常用的命令

    1、加载驱动模块insmod

         将生成驱动模块.ko文件加载,

         insmod xxx.ko

         加载后就会执行xxxx_init函数

    2、卸载驱动模块rmmod

         对应的卸载驱动的命令

         rmmod xxxx 注意不用带.ko

    3、查看内核中的模块信息

         lsmod

    4、查看模块的描述信息

         modinfo xxxx.ko

         我们可以在驱动程序添加一些辅助信息,例如作者 ,驱动描述等。

    5、查看模块打印信息

         dmesg   

         printk是内核打印函数,默认模式下在中断下无法显示(当然,可以设置成打印到终端),用dmesg可以查看一下打印到内核的信息。

    上述几个比较常用,有其他的我们可以以后再看。

    我们把上述几个熟悉一下

    insmod /rmmod/dmesg

     

    加载模块后执行初始化函数,打印函数名和行号


    卸载模块后执行卸载函数,打印函数名和行号

    打印模块信息 modinfo


    查看内核中模块信息lsmod


    module为模块名称   size为模块打下  usedby 表明有几个其他文件使用

    实际上lsmod是读取并分析“/proc/modules”文件,我们来看一下这个文件


    内核已经加载的模块的信息也存在于/sys/module目录下,加载demo.ko后,内核中将包含/sys/moudle/demo目录,demo的目录树结构如下


    除了使用insmod加载模块以外,还可以用modprobe命令来加载模块,并且使用modprobe加载模块时,会同时加载模块所依赖的其他模块。insmod必须按顺序一个一个加载模块。同样在卸载时,modprobe -r filename的方式会同时卸载该模块所依赖的模块。

    模块之间的依赖关系放在/lib/modules/<kernel-version>/modules.dep文件中。实际上是在整体编译内核的时候由depmod工具生成的,该文件的格式很简单:有依赖的直接在“:”后面加上。











    展开全文
  • 于此,将框架(Framework)和设计模式(Design Pattern)应用于Linux驱动开发,说明了如何以面向对象、设计模式和框架概念来看待Linux驱动程序的架构。其直接的益处就是:让我们能基于一致的设计理念来结合Android HAL与...
  • linux驱动框架--hwmon学习

    千次阅读 2015-11-30 14:10:32
    linux驱动中,hwmon越来越多的被使用,利用hwmon下的节点查看内核导出的信息非常方便,也用hwmon框架做了两个设备的驱动了,该梳理下,做为知识储备了。 在3.4内核中,hwmon非常简单,对外只有一个函数:struct ...

    linux驱动中,hwmon越来越多的被使用,利用hwmon下的节点查看内核导出的信息非常方便,也用hwmon框架做了两个设备的驱动了,该梳理下,做为知识储备了。

    在3.4内核中,hwmon非常简单,对外只有一个函数:struct device *hwmon_device_register(struct device *dev),调用这个接口实现的hwmon设备,在/sys/class/hwmon/下会多出个文件夹,都是按照hwmon 0/1/2/3 编号,当有些注册失败时,编号就会发生变化,用脚本去自动采集这些数据时,每次都有根据实际情况修改脚本,非常不便,不过这个接口是调用了hwmon_device_register_with_groups(struct device *dev, const char *name, void *drvdata, const struct attribute_group **groups),可以将此接口导出,将第二个参数赋成设备名,在/sys/class/hwmon/下的文件夹就是所定义的名字了。

    在3.13内核中,hwmon改变很大,终于有了可以更多选择的接口了,使用也更方便,只需调用一个函数:

    hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
      data, lm73_groups);
    if (IS_ERR(hwmon_dev))
    return PTR_ERR(hwmon_dev);

    甚至连定义好的节点都会帮我们初始化好,省去了自己将lm73_groups的属性节点注册。

    展开全文
  • Linux驱动框架----hwmon

    千次阅读 2015-12-17 10:53:02
    你所要实现的功能会是千差万别的---这就是变的地方,而所谓既定的规范,包括建立目录和属性文件这是Linux系统已经为我们做好了的,我们只需要直接拿来引用就OK了。 那么今天,我们就来看看hwmon框架是怎么样的。 对...

    写在前面的话:

    对于框架,我觉得就是在一定规范的形式下去实现你要的功能。这里就涉及到一个变与不变的地方。你所要实现的功能会是千差万别的---这就是变的地方,而所谓既定的规范,包括建立目录和属性文件这是Linux系统已经为我们做好了的,我们只需要直接拿来引用就OK了。

    那么今天,我们就来看看hwmon框架是怎么样的。


    对hwmon而言,它是sysfs框架下的一个类,但是所有有关该类与sys的接口都已经在drivers/hwmon/hwmon.c实现,因而我们也不必过多的关心。

    那么我们到底要做些什么呢?

    对于你要实现的功能部分,你就自己去想象吧,下面我们来说说在我们的程序中对于不变的那部分要如何去实现。

    我就以最基本的读CPU温度的程序为例,来说明整个框架的编写。


    一.作为驱动,首先我们要做就是驱动的注册和撤销。

    因此,在XXX_hwmon_init()函数中对hwmon驱动和该驱动的属性文件等进行注册。

    my_hwmon_dev = hwmon_device_register(NULL);

    ret = sysfs_create_group(&my_hwmon_dev->kobj,&my_hwmon_attribute_group);

    ret = create_sysfs_temp_files(&my_hwmon_dev->kobj);

    在有这么多的注册函数时,对于函数的异常处理,我个人觉得用goto来实现,比较直观和易用,让人看起来一目了然。

    static int __init my_hwmon_init(void)
    {
            int ret;
    
            printk(KERN_INFO "my cpu temperature hwmon enter!\n");
    
            my_hwmon_dev = hwmon_device_register(NULL);
            if (IS_ERR(my_hwmon_dev)) {
                    ret = -ENOMEM;
                    printk(KERN_ERR "my_hwmon_device_register fail!\n");
                    goto fail_hwmon_device_register;
            }
    
            ret = sysfs_create_group(&my_hwmon_dev->kobj,
                                    &my_hwmon_attribute_group);
            if (ret) {
                    printk(KERN_ERR "fail to create my hwmon!\n");
                    goto fail_create_group_hwmon;
            }
    
            ret = create_sysfs_temp_files(&my_hwmon_dev->kobj);
            if (ret) {
                    printk(KERN_ERR "fail to create temperature files!\n");
                    goto fail_create_sysfs_temp_files;
            }
            return ret;
    
    fail_create_sysfs_temp_files:
            sysfs_remove_group(&my_hwmon_dev->kobj, &my_hwmon_attribute_group);
    fail_create_group_hwmon:
            hwmon_device_unregister(my_hwmon_dev);
    fail_hwmon_device_register:
            return ret;
    }

    而在XXX_hwmon_exit()函数中,和XXX_hwmon_init()函数相对应的,以相反的顺序对已注册的设备进行撤销。

    remove_sysfs_temp_files(&my_hwmon_dev->kobj);

    sysfs_remove_group(&my_hwmon_dev->kobj,&my_hwmon_attribute_group);

    hwmon_device_unregister(my_hwmon_dev);

    好了,至此,hwmon架构的初始化和撤销的工作已经完成。

    二.接下去就是对hwmon下的各种属性文件的创建和对温度的读写。

    1.hwmon整体属性框架

    总的来讲分为三部曲:

    首先,每个hwmon设备都会有自己独有的属性,这些独有属性就被SENSOR_DEVICE_ATTR声明为struct attribute结构体。

    1 #define SENSOR_DEVICE_ATTR(_name, _mode, _show, _store, _index) \
    2 
    3 struct sensor_device_attribute sensor_dev_attr_##_name          \
    4 
    5         = SENSOR_AT


    在程序中,则被写作:

    1 static SENSOR_DEVICE_ATTR(name, S_IRUGO, get_my_hwmon_name, NULL, 0);

    然后,加入到sysfs框架的struct attribute属性结构体数组中,注意该结构体数组最后一项必须以NULL结尾。

    struct attribute定义在include/linux/sysfs.h中。

    1 static struct attribute *my_hwmon_attributes[] = {
    2         &sensor_dev_attr_name.dev_attr.attr,
    3         NULL,
    4 };


    最后,将这些众多的属性汇总到结构struct attribute_group中。这个struct attribute_group被sysfs_create_group()函数调用建立整个属性框架。

    struct attribute_group定义在include/linux/sysfs.h中。

    1 static struct attribute_group my_hwmon_attribute_group = {
    2         .attrs = my_hwmon_attributes,
    3 };
    


    在我的程序中,这里只有一个属性—name,表示该hwmon驱动的名称。

    2.温度相关属性文件的建立

    在上面,整个hwmon的框架已经建立,接下来就是温度的读取,显示。这个过程其实是sysfs框架的内容。

    首先,确定会有多少属性,每个属性文件都会被SENSOR_DEVICE_ATTR声明为struct attribute结构体。其中的_show和_store是以函数形式实现,因此对应的实现相应的函数,若没有这个功能的实现就以NULL代替;

    _show表示的是从属性文件中读取出数据。

    _store表示的是向属性文件中写入数据。

    因此,如果该属性文件是不可写是,_store实现为NULL。

    然后,将同一seneor的属性加入到sysfs框架的struct attribute属性结构体数组中,注意该结构体数组最后一项必须以NULL结尾,被sysfs_create_files()函数调用。

    以上两步是建立属性文件最基本的两步,我们的具体功能可以在_show和_store两个函数中去实现。当然对于一些复杂的设备来讲仅仅这两步是不够的,如果该设备属于平台驱动或者是某一大类设备,如I2C,我们此时就需要根据具体情况去声明相应的结构,并按照相应结构的规范去操作。

    在我的程序中仅限于前两步,因为程序中并未涉及到任何其他设备,只是简单的读取了温度寄存器。程序中定义了两个属性my_cpu_temp_label和get_my_cpu_temp。

    下面是我模块在加载后生成目录的tree型图:

           

    这些就是我对hwmon框架在目前基础上的了解。

    最后向大家做个推荐啊:我的所有程序都会在github上,所以,大家要是有兴趣的话,可以去github上去clone。

    我的github地址为:https://github.com/Antonio-Zhou

    这篇文章中完整代码的下载方式为:git clone git://github.com/Antonio-Zhou/LoongsonDriver.git

    下载之后,其中会有一个cpu_temp的目录,里面存放着makefile文件和源代码。

    希望大家多多提意见哦!



    展开全文
  • Linux下PCI设备驱动程序开发 --- PCI驱动的实现(三) 》 <!-- google_ad_client = "pub-2299987709779770"; google_ad_width = 728; google_ad_height = 15; google_ad_format = "728x15_0ads_al_s"; google_...
  • Linux驱动(三)字符设备驱动框架

    千次阅读 2017-12-26 21:13:34
    前面我们讲了linux驱动框架linux驱动(一)驱动框架,对驱动的基本框架有了了解。现在我们来说一说字符设备驱动,我们一般讲驱动分为三类,字符设备、块设备、网络设备。字符设备和块设备是按照传输时的基本单位来...
  • Linux网络驱动框架

    千次阅读 2017-07-09 18:56:29
    Linux网络驱动框架Linux网卡驱动框架 网络协议接口层向网络层协议提供提供统一的数据包收发接口,都通过dev_queue_xmit()函数发送数据,并通过netif_rx()函数接受数据。这一层的存在使得上层协议独立于具体的设备...
  • linux设备驱动框架

    万次阅读 多人点赞 2018-05-26 11:32:00
    一.Linux设备分类字符设备: 以字节为单位读写的设备。块设备 : 以块为单位(效率最高)读写的设备。网络设备 : 用于网络通讯设备。字符设备: 字符(char)设备是个能够像字节流(类似文件)一样被访问的设备,...
  • 本课程是linux驱动开发的第4个课程,主要内容是驱动框架的引入。通过led驱动框架和gpiolib的这两个框架的详细解释,让大家学习内核中驱动框架的使用方法,这个对后续学习基于框架的复杂驱动非常有帮助。
  • Linux IIC驱动框架理解

    2014-07-09 09:51:23
    看了一周的Linux IIC驱动框架
  • linux中spi驱动框架

    千次阅读 2018-10-12 11:39:32
    linux中spi驱动框架 2016年09月14日 15:57:06 andylauren 阅读数:403 &lt;span class="tags-box artic-tag-box"&gt; &...
  • linux clk驱动框架

    万次阅读 2016-06-14 16:25:41
    它的框架图如下所示: 上图中的黄色区域都是clk core所实现的功能,灰色区域是clock驱动开发需要做的事情,而绿色区域是其他device driver需要使用clock时要调用到的clk功能。 二、 clk framework的实现 ...
  • linux驱动开发(一)—GPIO驱动框架

    万次阅读 2016-01-26 20:18:15
     GPIO驱动是Linux驱动开发中最基础、但却是很常用、很重要的驱动。比如你要点亮一个LED灯、键盘扫描、输出高低电平等等。而Linux内核的强大之处在于对最底层的GPIO硬件操作层的基础上封装了一些统一的GPIO操作接口...
  • Linux摄像头驱动框架

    千次阅读 2019-06-14 11:18:05
    qemu没有摄像头驱动模拟, 就用驱动程序读取文件系统中的bmp图片当做摄像头的输出图像,做了一个摄像头驱动程序。 左边的为根文件系统中的3张bmp图片,驱动程序每次读取一张图片当做摄像头输出图像,送给内核驱动,...
  • Linux SPI驱动框架剖析

    千次阅读 2015-09-14 21:43:16
    Linux SPI驱动框架剖析 http://www.cnblogs.com/lubiao/p/4806146.html (说明:我的开发平台是TQ210,处理器是cotex-A8架构的s5pv210,Linux内核版本:linux-3.10.46。) 一、SPI(Serial Peripheral ...
  • linux总线驱动框架分析

    千次阅读 2018-08-08 15:30:31
    linux的总线驱动模型主要可以分为三个部分:总线、设备、驱动。  内核初始化会先调用platform_bus_init()初始化platform_bus总线,之后由_initcall的优先级顺序可知先初始化各种实际总线例如spi、i2c。之后注册...
  • 1、USB驱动引入 ...Linux USB子系统较为庞大,本文主要对Linux系统下的USB总线驱动整体框架进行概述,重点的细节待后续文章展开。 首先来看一个现象,插入USB设备后打印如下日志: usb 1-1: new full ...
  • Linux GPIO驱动 - 驱动框架概述

    千次阅读 2015-11-11 18:37:06
    但直到最近才发现Linux自身就有完善的GPIO驱动框架,并且通过sysfs向用户空间提供操作接口。 Linux的GPIO驱动框架层次及数据结构如下:最上层是用来向向用户空间提供接口,用户可以通过该接口方去控制GPIO PIN脚。...
  • platform驱动框架是利用总线(bus_type)+驱动(driver)+设备(device)模型建立的驱动框架。这个模型中总线只有一条,而驱动和设备可以有多个,驱动和设备全都挂接到总线上,总线完成驱动和设备的匹配工作,一旦驱动和...
  • 1-Linux驱动基本框架结构

    千次阅读 2016-09-01 18:54:51
    学习linux驱动编程,首先应该学习linux的驱动框架,而本次博文是最基本的驱动框架,对学习很实用!
  • linux设备驱动模型 - 驱动框架

    千次阅读 2017-03-29 23:08:49
    linux驱动模型框架如图所示:1. kernfs驱动最终是提供给用户层使用,那么其中的接口就是通过kernfs文件系统来注册,kernfs是一个通用的内核虚拟文件系统2. sys/kobjectsys是设备驱动文件系统,在/sys目录下会把各个...
  • Linux USB驱动框架分析

    千次阅读 2009-09-18 10:49:00
    Linux USB驱动框架分析http://hi.baidu.com/nuaabus/blog/item/dff2ea50f5de2b6a85352494.html 补充一些网上资源:一个USBinterface对应一种USB逻辑设备,比如鼠标、键盘、音频流。所以,在USB范畴中,device一般...
  • 一、SPI 驱动框架简介 和I2C一样,SPI 也是很常用的串行通信协议,SPI 驱动框架和 I2C 很类似,都分为主机控制器驱动和设备驱动,主机控制器也就是 SOC 的 SPI 控制器接口。 1、 SPI 主机驱动 SPI 主机驱动就是 SOC ...
  • 1. PCI设备驱动的组成   PCI 驱动只是为了辅助设备本身的驱动,它不是目的,而是手段。例如,对于通过PCI 总线与系统连接的...在Linux 内核中,用pci_driver 结构体来定义PCI 驱动,该结构体中包含了PCI 设备的探测

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 99,146
精华内容 39,658
关键字:

linux驱动框架

linux 订阅