This essay, I go to a deeply studying to android HAL device driver program.

  

  According to the android architecture we disscus in last essay, when we are designing a android device driver, we should follow the steps below :

  (1) linux device driver

  In this driver, we should try our best to cut down the mechanism and change them to be more concise.

  (2) HAL libraries

  The HAL serves as a standard interface that allows the Android system to call into the device driver layer while being agnostic about the lower-level implementations of your drivers and hardware.

  (3)Service libraries

  System service access the hardware in HAL libraries and provide the APIs for android framework. Service libraries usually are JNI libraries or Linux libraries.

  1、linux device driver

//s3c6410_leds_hal.c
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/pci.h>
#include <asm/uaccess.h>
#include <mach/map.h>
#include <mach/regs-gpio.h>
#include <mach/gpio-bank-m.h> #define DEVICE_NAME "s3c6410_leds_hal"
#define DEVICE_COUNT 1
#define S3C6410_LEDS_MAJOR 0
#define S3C6410_LEDS_MINOR 234 static unsigned char mem[];
static int major = S3C6410_LEDS_MAJOR;
static int minor = S3C6410_LEDS_MINOR;
static dev_t leds_number;
static struct class *leds_class = NULL; static void write_io(unsigned char buf[])
{
int i;
unsigned int tmp;
tmp = ioread32(S3C64XX_GPMDAT);
for (i = ; i < ; i++) {
if (buf[i] == '') {
tmp &= (~( << i));
} else {
tmp |= ( << i);
}
}
iowrite32(tmp, S3C64XX_GPMDAT);
} static ssize_t s3c6410_leds_hal_write(struct file *filp,
const char __user *buf, size_t count, loff_t *ppos)
{
unsigned int tmp = count; if (count > ) {
tmp = ;
} if (copy_from_user(mem, buf, tmp)) {
return -EFAULT;
} else {
write_io(mem);
}
return count;
} static struct file_operations leds_fops = {
.owner = THIS_MODULE,
.write = s3c6410_leds_hal_write,
};
static struct cdev leds_cdev; static int leds_create_device(void)
{
int ret = ;
int err = ; cdev_init(&leds_cdev, &leds_fops);
leds_cdev.owner = THIS_MODULE;
if (major > ) {
leds_number = MKDEV(major, minor);
err = register_chrdev_region(leds_number, DEVICE_COUNT, DEVICE_NAME);
if (err < ) {
printk(KERN_WARNING "register_chardev_region() failed.\n");
return err;
}
} else {
err = alloc_chrdev_region(&leds_cdev.dev, ,
DEVICE_COUNT, DEVICE_NAME);
if (err < ) {
printk(KERN_WARNING "register_chardev_region() failed.\n");
return err;
}
major = MAJOR(leds_cdev.dev);
minor = MINOR(leds_cdev.dev);
leds_number = leds_cdev.dev;
} ret = cdev_add(&leds_cdev, leds_number, DEVICE_COUNT);
leds_class = class_create(THIS_MODULE, DEVICE_NAME);
device_create(leds_class, NULL, leds_number, NULL, DEVICE_NAME);
return ret; } static int leds_init(void)
{
int ret;
ret = leds_create_device();
printk(DEVICE_NAME "\tinitialized.\n"); return ret;
} static void leds_exit(void) {
device_destroy(leds_class, leds_number);
if (leds_class) {
unregister_chrdev_region(leds_number, DEVICE_COUNT);
return;
}
printk(DEVICE_NAME"\texit.\n");
} module_init(leds_init);
module_exit(leds_exit); MODULE_LICENSE("GPL");

  Yes, this file is the same as the previous driver file, because there aren't any business-related codes in this simple led driver.

  Then we focus more in the HAL libraries and Service libraries coding.

  2、HAL libraries

  HAL modules would be compile to a Linux shared library (*.so), and these *.so files could be automaticlly loaded by android system.

  Each HAL module should provide a variable for android system loading : HAL_MODULE_INFO_SYM (never change it.)  

//Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS) LOCAL_PRELINK_MODULE := false
LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw
LOCAL_SHARED_LIBRARIES := liblog
LOCAL_SRC_FILES := leds_hal.c
LOCAL_MODULE := leds_hal.default
LOCAL_MODULE_TAGS := eng
include $(BUILD_SHARED_LIBRARY) //leds_hal.h
#include <hardware/hardware.h>
#include <fcntl.h>
#include <cutils/log.h> struct leds_module_t {
struct hw_module_t hw_module;
}; struct leds_device_t {
struct hw_device_t hw_device;
int (*set_on)(struct leds_device_t *dev, int32_t led);
int (*set_off)(struct leds_device_t *dev, int32_t led);
}; #define LED_HARDWARE_MODULE_ID "leds_hal"
//leds_hal.c
#include "leds_hal.h" int fd_leds = ; int leds_switch(struct leds_device_t *dev, int32_t led, int32_t on_off)
{
unsigned char buf[]; if (led < && led > ) {
LOGI("Led Stub : no this led.\n");
return -;
} if (on_off == ) {
LOGI("Led Stub : set %d led on", led);
buf[led] = '';
} else {
LOGI("Led Stub : set %d led off", led);
buf[led] = '';
} write(fd_leds, buf, );
return ;
} int leds_on(struct leds_device_t *dev, int32_t led)
{
return leds_switch(dev, led, );
} int leds_off(struct leds_device_t *dev, int32_t led)
{
return leds_switch(dev, led, );
} int leds_device_close(struct hw_device_t *device)
{
struct leds_device_t *ldt = (struct leds_device_t *) device; if (ldt)
free(ldt); close(fd_leds);
return ;
} static int leds_device_open(const struct hw_module_t *module, const char *name,
struct hw_device_t **device)
{
struct leds_device_t *leds_dev;
leds_dev = (struct leds_device_t *) malloc(sizeof(*leds_dev)); memset(leds_dev, , sizeof(*leds_dev)); leds_dev->hw_device.tag = HARDWARE_DEVICE_TAG;
leds_dev->hw_device.version = ;
leds_dev->hw_device.module = (struct hw_module_t *) module;
leds_dev->hw_device.close = leds_device_close;
leds_dev->set_on = leds_on;
leds_dev->set_off = leds_off; *device = (hw_device_t *) leds_dev; fd_leds = open("/dev/s3c6410_leds_hal", O_RDWR); if (fd_leds < ) {
LOGI("Led Stub : open /dev/s3c6410_leds_hal fail.\n");
} else {
LOGI("Led Stub : open /dev/s3c6410_leds_hal success.\n");
} return ;
} static struct hw_module_methods_t leds_module_methods = {
.open = leds_device_open
}; struct leds_module_t HAL_MODULE_INFO_SYM = {
hw_module : {
tag: HARDWARE_MODULE_TAG,
version_major: ,
version_minor: ,
id: LED_HARDWARE_MODULE_ID,
name: "Led HAL Stub",
methods: &leds_module_methods,
}
};

  Acturely, in this simple leds HAL module, we didn't get much messages about "business-related", but we can treat the leds switch functions as.

  And the more important messages we need to know are listing follow :

HAL_MODULE_INFO_SYM
hw_module_t
hw_device_t
hw_module_methods_t

  Ok, let's stop here. I wanna to talk some more about the module both in linux and android.

  In my opnions, there are a lot of design logic share with this two system.

  (1) linux

  In the picture, we can see what we should do to design a device driver :

  Create a entrance function;

  Declare a basic struct;

  Extand the struct with special operations.

  (2) android

  In the picture, we can see the android HAL is the same as linux device driver in the three absractions :

  Entrance, basic struct, expend struct.

  Then I will discuss the different between the two system ;

  [ Entrance ]

// We use functions to build the device driver in linux
module_init(leds_init); // The entrance is a variable HAL_MODULE_INFO_SYM automaticlly loaded by the system
struct leds_module_t HAL_MODULE_INFO_SYM = {
hw_module : {
tag: HARDWARE_MODULE_TAG,
version_major: ,
version_minor: ,
id: LED_HARDWARE_MODULE_ID,
name: "Led HAL Stub",
methods: &leds_module_methods,
}
};

  [ Basic Struct ]

// Basic struct in linux is a structure, we use the "struct" to create our device
static struct cdev leds_cdev; // Basic struct in android is a structure with function open, we use the "function" to create our device
static int leds_device_open(const struct hw_module_t *module, const char *name,
struct hw_device_t **device)
{
struct leds_device_t *leds_dev;
leds_dev = (struct leds_device_t *) malloc(sizeof(*leds_dev)); memset(leds_dev, , sizeof(*leds_dev)); leds_dev->hw_device.tag = HARDWARE_DEVICE_TAG;
leds_dev->hw_device.version = ;
leds_dev->hw_device.module = (struct hw_module_t *) module;
leds_dev->hw_device.close = leds_device_close;
leds_dev->set_on = leds_on;
leds_dev->set_off = leds_off; *device = (hw_device_t *) leds_dev; fd_leds = open("/dev/s3c6410_leds_hal", O_RDWR); if (fd_leds < ) {
LOGI("Led Stub : open /dev/s3c6410_leds_hal fail.\n");
} else {
LOGI("Led Stub : open /dev/s3c6410_leds_hal success.\n");
} return ;
}

  [ Extend Struct ]

// The extend struct means the functions include in file_operations, we have to build the callback functions in linux.
static struct file_operations leds_fops = {
.owner = THIS_MODULE,
.write = s3c6410_leds_hal_write,
}; // Instead of using the prototype, the HAL specification suggest us to create two new struct with the first element hw_module_t/hw_device_t in android.
// We can see that it is useless to create a struct in a prototype to hw_device_t, because there is no callback functions in this struct.
// If we want to extend the hw_device_t, we should create the new struct as the substruct of hw_device_t
struct leds_device_t {
struct hw_device_t hw_device;
int (*set_on)(struct leds_device_t *dev, int32_t led);
int (*set_off)(struct leds_device_t *dev, int32_t led);
};

  After compiling, we should push the leds_hal.default.so to dir /system/lib/hw in ok6410.

  I will discuss the "Service libraries" in next essay.

  

  

  

ok6410 android driver(11)的更多相关文章

  1. ok6410 android driver(5)

    Test the android driver by JNI (Java Native Interface), In the third article, we know how to compile ...

  2. ok6410 android driver(9)

    In this essay, I will write the JNI to test our leds device. If you don't know how to create a jni p ...

  3. ok6410 android driver(8)

    In the past, we know how to create and run a simple character device driver on pc, goldfish and ok64 ...

  4. ok6410 android driver(3)

    This article discusses the Makefile and how to port the module to different platform (localhost and ...

  5. ok6410 android driver(12)

    In this essay, I will talk about how to write the service libraries. TIPS : I won't discuss the name ...

  6. ok6410 android driver(10)

    From this essay, we go to a new discussion "Android Hardware Abstraction Layer". In this e ...

  7. ok6410 android driver(7)

    This article talk about how to test device driver on JNI. There are two ways to test the device driv ...

  8. ok6410 android driver(6)

    This is a short essay about the mistakes in compiling ok6410 android-2.3 source codes. If there is n ...

  9. ok6410 android driver(1)

    target system : Android (OK6410) host system : Debian Wheezy AMD64 1.Set up android system in ok6410 ...

随机推荐

  1. HTTP 错误 500.21 - Internal Server Error 处理程序“ExtensionlessUrlHandler-Integrated-4.0”在其模块列表中有一个错误模块“ManagedPipelineHandler”

    导致这个错误出现的原因是因为.net Framework4.0没有注册 解决方法:打开运行命令行,运行下面的命令: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30 ...

  2. Scala 深入浅出实战经典 第55讲:Scala中Infix Type实战详解

    王家林亲授<DT大数据梦工厂>大数据实战视频 Scala 深入浅出实战经典(1-64讲)完整视频.PPT.代码下载: 百度云盘:http://pan.baidu.com/s/1c0noOt ...

  3. LCLFramework框架之IOC

    我们都知道,在采用面向对象方法设计的软件系统中,它的底层实现都是由N个对象组成的,所有的对象通过彼此的合作,最终实现系统的业务逻辑. 借助于"第三方"实现具有依赖关系的对象之间的解 ...

  4. mysql DB server端,如何让读写更快

    其实,我不是专业的DB管理同学,甚至算不上会了解.只是在最近的工作中,遇到了DB server端优化的契机,所以把这些手段记录下来: 通过调整这个参数的值,可以让DB更给力: 这两个参数的含义: 1. ...

  5. iOS开发中一些常见的并行处理

    本文主要探讨一些常用多任务的最佳实践.包括Core Data的多线程访问,UI的并行绘制,异步网络请求以及一些在运行态内存吃紧的情况下处理大文件的方案等.??其实编写异步处理的程序有很多坑!所以,本文 ...

  6. Android 模拟器 获得 root权限

    启动一个模拟器,开始-运行-输入cmd,打开dos,依次输入 adb shell mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system ...

  7. Android对话框之dismiss和cancel和hide区别

    在我们看来两者效果都是一样的,其实看下源码就知道cancel肯定会去调dismiss的,如果调用的cancel的话就可以监听DialogInterface.OnCancelListener. /** ...

  8. 对android应用一些破解的方法

    因为需要破解一款应用,找了些资料 Android手机中的程序文件夹拷贝到别的Android手机上还能用么? xx.apk Android个人破解应用新思路 安卓手机下xx.apk JAVA破解之旅 s ...

  9. POJ 2887 Big String(块状链表)

    题目大意 给一个字符串,长度不超过 106,有两种操作: 1. 在第 i 个字符的前面添加一个字符 ch 2. 查询第 k 个位置是什么字符 操作的总数不超过 2000 做法分析 好多不同的做法都可以 ...

  10. 玩转MAC OS!实测DIY兼容机装苹果系统

    1打造iMAC:DIY常规兼容机安装MAC OS回顶部 [PConline 评测]最近消息透露苹果下个月即将发布新系统MAC OS X 10.9,这是什么东西?对于苹果,留给我们印象最为深刻的是iPh ...