版權所有,轉載請說明轉自 http://my.csdn.net/weiqing1981127
原創作者:南京郵電大學 通信與資訊系統專業 研二 魏清
一.Platform裝置驅動概念
主要講解平台裝置驅動的模型和基本概念,同時因為驅動加載的方式有動态加載和靜态加載兩種方式,這裡我們分别對動态加載和靜态加載兩種情況下,如何使用平台裝置和驅動加以叙述。最後使用mini2440開發闆,運用Platform和device_attribute機制,編寫按鍵驅動代碼和測試代碼。
我們知道linux核心中常見的的總線有I2C總線,PCI總線,序列槽總線,SPI總線,PCI總線,CAN總線,單總線等,是以有些裝置和驅動就可以挂在這些總線上,然後通過總線上的match進行裝置和驅動的比對。但是有的裝置并不屬于這些常見總線,是以我們引入了一種虛拟總線,也就是platform總線的概念,對應的裝置叫做platform裝置,對應的驅動叫做platform驅動。當然引入platform的概念,可以做的與闆子相關的代碼和驅動的代碼分離,使得驅動有更好的可擴充性和跨平台性。
1.Platform總線
struct bus_type platform_bus_type = {
.name = "platform", //名
.dev_attrs = platform_dev_attrs, //屬性
.match = platform_match, //裝置和驅動的比對函數
.uevent = platform_uevent, //解除安裝處理
.pm = &platform_dev_pm_ops, //電源管理
};
我們看看裝置和驅動的比對函數match
static int platform_match(struct device *dev, struct device_driver *drv)
{
struct platform_device *pdev = to_platform_device(dev); //獲得平台裝置
struct platform_driver *pdrv = to_platform_driver(drv); //獲得平台驅動
if (pdrv->id_table) //如果平台驅動有支援項,進入platform_match_id
return platform_match_id(pdrv->id_table, pdev) != NULL;
return (strcmp(pdev->name, drv->name) == 0); //沒有支援項,則老實比對名字
}
通過上面這個match函數我們知道,如果驅動中定義了驅動支援項,那麼在總線執行match函數中,就會将驅動支援項中每一個名字和裝置名字比對,看看是否比對成功。如果驅動沒有設定支援項,就會把驅動的名字和裝置的名字比對,如果一樣,則比對成功。
2.Platform裝置
struct platform_device {
const char * name; //名
int id;
struct device dev; //内嵌裝置
u32 num_resources; //資源個數
struct resource * resource; //資源結構體
struct platform_device_id *id_entry;
struct pdev_archdata archdata;
};
我們重點來看看platform_device中資源結構體的定義
struct resource {
resource_size_t start; //起始位址
resource_size_t end; //結束位址
const char *name; //名
unsigned long flags; //标号
struct resource *parent, *sibling, *child;
};
對于這個資源結構體中的flags标号可以有IORESOURCE_IO、IORESOURCE_MEM、IORESOURCE_IRQ、IORESOURCE_DMA四種選擇,重點是申請記憶體(IORESOURCE_MEM)和申請中斷号(IORESOURCE_IRQ)用的比較多。
2.1Platform裝置的靜态加載
所謂的靜态加載,就是把platform裝置編譯進核心,對于platform_device的定義常常在BSP中實作,我們這裡拿Mini2440舉例,看看對于的BSP檔案mach-smdk2440.c
struct platform_device s3c_device_lcd = {
.name = "s3c2410-lcd",
.id = -1,
.num_resources = ARRAY_SIZE(s3c_lcd_resource),
.resource = s3c_lcd_resource,
.dev = {
.dma_mask = &s3c_device_lcd_dmamask,
.coherent_dma_mask = 0xffffffffUL
}
};
這是基于Mini2440的LCD平台裝置在BSP檔案中的定義,那麼我們怎麼把它加入核心呢?
static struct platform_device *smdk2440_devices[] __initdata = {
&s3c_device_usb,
&s3c_device_lcd, //添加LCD平台裝置
&s3c_device_wdt,
&s3c_device_i2c0,
&s3c_device_iis,
};
嗯,原來我們建立了一個platform_device數組,然後把LCD的platform_device添加到這個數組中,那麼這個platform_device數組怎麼注冊到核心的呢?
static void __init smdk2440_machine_init(void)
{
s3c24xx_fb_set_platdata(&smdk2440_fb_info);
s3c_i2c0_set_platdata(NULL);
platform_add_devices(smdk2440_devices, ARRAY_SIZE(smdk2440_devices));//加到核心
smdk_machine_init();
}
看到了吧,在smdk2440_machine_init中,我們調用了platform_add_devices函數來把platform_device注冊到核心,再繼續跟蹤下platform_add_devices
int platform_add_devices(struct platform_device **devs, int num)
{
int i, ret = 0;
for (i = 0; i < num; i++) {
ret = platform_device_register(devs[i]);
if (ret) {
while (--i >= 0)
platform_device_unregister(devs[i]); //注冊裝置
break;
}
}
return ret;
}
好了,到此為止,我們已經看到了如果添加platform_device,以及這個platform_device又是如何被注冊到核心的全過程。
除了BSP中定義的資源外,有的裝置可能還會有一些配置資訊,而這些配置資訊依賴于闆子,不适合放到驅動中,為此,我們的platform提供了平台資料platform_data的支援。在核心中添加平台資料有兩種方式,仍然以LCD為例
static struct s3c2410fb_mach_info smdk2440_fb_info __initdata = { //平台資料
.displays = &smdk2440_lcd_cfg,
.num_displays = 1,
.default_display = 0,
.lpcsel = ((0xCE6) & ~7) | 1<<4,
};
上面的smdk2440_fb_info就是LCD的平台資料,我們怎麼把這個LCD的平台資料告訴LCD的platform_device呢?
static void __init smdk2440_machine_init(void)
{
s3c24xx_fb_set_platdata(&smdk2440_fb_info); //添加平台資料
s3c_i2c0_set_platdata(NULL);
platform_add_devices(smdk2440_devices, ARRAY_SIZE(smdk2440_devices));
smdk_machine_init();
}
看到沒?上面的s3c24xx_fb_set_platdata函數就完成了平台資料的添加,繼續跟蹤這個s3c24xx_fb_set_platdata函數
void __init s3c24xx_fb_set_platdata(struct s3c2410fb_mach_info *pd)
{
struct s3c2410fb_mach_info *npd;
npd = kmalloc(sizeof(*npd), GFP_KERNEL);
if (npd) {
memcpy(npd, pd, sizeof(*npd));
s3c_device_lcd.dev.platform_data = npd; //平台資料添加的實作
} else {
printk(KERN_ERR "no memory for LCD platform data\n");
}
}
好了,我們可以看到其實把這個平台資料儲存在了平台裝置中内嵌的裝置結構體的platform_data中。剛才說了添加平台資料有兩種方式,根據上面的原理,其實我們可以直接把平台資料儲存在了平台裝置中内嵌的裝置結構體的platform_data中,具體代碼如下
struct platform_device s3c_device_lcd = {
.name = "s3c2410-lcd",
.id = -1,
.num_resources = ARRAY_SIZE(s3c_lcd_resource),
.resource = s3c_lcd_resource,
.dev = {
.dma_mask = &s3c_device_lcd_dmamask,
.coherent_dma_mask = 0xffffffffUL
.platform_data=&smdk2440_fb_info //添加平台資料
}
};
到此為止,我們已經明白了platform_device的靜态添加全過程。
2.2 Platform裝置的動态加載
由于靜态添加platform_device需要最後編譯核心,這個不利于修改,是以在開發階段,我們可以采用platform裝置的動态加載方法。具體操作是:先配置設定platform_device,然後向platform_device中添加資源結構體,最後把platform_device注冊到核心,對應三個函數如下
struct platform_device my_device = platform_device_alloc("s3c2410-buttons", -1);
platform_device_add_resources(my_device, s3c_buttons_resource, 3);
ret = platform_device_add(my_device);
當然,上面三個函數還是封裝在子產品加載函數中,也就是把平台裝置的加載寫成一個子產品的形式。
3. 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; //内嵌裝置驅動
struct platform_device_id *id_table; //驅動支援項
};
根據上面的platform_driver結構體的定義,我們需要思考下platform驅動名字在哪裡呢?實際上在内嵌的裝置驅動中定義的。
3.1 Platform驅動的靜态加載
寫一個驅動,測試驅動階段我們一般采用動态加載的方式,當驅動已經成型,我們就會采用靜态加載的方式,把驅動編譯入核心。把驅動靜态編譯入核心的方式主要是根據Makefile和Kconfig兩張地圖,在Makefile中添加驅動檔案名,在Kconfig中添加對應的驅動菜單選項,當我面make zImage時就會自動編譯我們的驅動檔案。
3.2 Platform驅動的動态加載
拿一個基于平台裝置的按鍵驅動例子看看
static struct platform_driver my_driver = {
.probe = my_probe, //探測函數
.remove = my_remove,
.driver = {
.owner = THIS_MODULE,
.name = "s3c2410-buttons",
},
};
上面是按鍵驅動中定義了的一個platform_driver,然後我們隻需要在驅動子產品加載函數中執行platform_driver_register(&my_driver)就可以把platform驅動加入核心了。在我們進行insmod加載時就會調用這個子產品加載函數,進而注冊platform驅動。
二.平台裝置的資源
1.平台資料和私有資料的差別
前面在講平台裝置的靜态加載的時候,我們提到平台資料的概念,在核心驅動代碼中還會出現私有資料這一名詞。那麼平台資料和私有資料有什麼差別呢?首先平台資料是由于引入平台裝置而産生的,平台資料主要儲存的是一些依賴的闆子的配置資訊,平台資料的定義是定義在平台裝置所在的BSP中的,我們在平台驅動中可以進行讀取到在BSP中定義的平台資料。而私有資料是作為一個驅動中儲存裝置資訊的一個結構體,它定義在平台驅動中,而不是BSP中,我們在平台驅動中可以把一個裝置結構體設定為這個平台驅動的私有資料,也可以根據這個平台裝置,讀取這個平台裝置的私有資料。
好了,下面我們先看看怎麼在平台驅動中讀取在BSP中定義的平台資料,仍然以LCD為例,隻需要在裝置驅動需要擷取平台資料的地方執行如下代碼
struct s3c2410fb_mach_info *pdata=pdev->dev.platform_data;
接下來,我們研究下私有資料。私有資料的定義各種各樣,總之是一個結構體。那麼怎麼将一個裝置結構體設定為平台裝置的私有資料呢?
struct buttons *key;
platform_set_drvdata(pdev, key);
同樣怎麼根據這個平台裝置,讀取這個平台裝置的私有資料呢?
Struct buttons *keyt=platform_get_drvdata(pdev);
最後補充兩個點:第一,根據經驗發現平台資料是為私有資料服務的,也就是平台資料可能成為私有資料的一部分。第二,對于由裝置獲得平台裝置的情況,我們可以通過*pdev=to_platform_device(dev)代碼獲得。
2. Platform裝置資源的讀取
我們在BSP中定義了平台裝置的資源,那麼怎麼擷取這些資源呢?首先我們要明白,裝置和驅動的第一次比對是發生在總線上的match函數中,這次比對成功後所做的操作隻是把裝置和驅動相連。當我們執行平台驅動中的probe時,會發生第二次裝置和驅動的比對,也就是所謂的探測。是以,我們對在BSP中定義的平台裝置的資源會在平台驅動的probe函數中讀取到,下面我們就看看如何讀取這些資源了。
對于資源中的存儲空間的資源讀取,首先讀取資源,然後申請空間,最後完成由虛拟位址到實體位址的映射。具體函數如下
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct resource *buttons_mem = request_mem_region(res->start,
res->end-res->start+1, pdev->name);
void __iomem *buttons_base = ioremap(res->start, res->end - res->start + 1);
對于中斷資源的讀取,隻要一步如下操作即可。
struct resource *buttons_irq1 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);