【 声明:版权所有,欢迎转载,请勿用于商业用途。 联系信箱:feixiaoxing @】
对于linux驱动来说,一般的架构还是按照bus-host-device的形式来进行的。比如就拿usb来说,通常如果是新的soc,只需要适配一下host就可以了。但是如果要适配其他的usb外接设备,那么需要自己编写device driver。同样,目前pc用到最多的还是pcie,所以你会发现pc上编写的driver大多数都是适配不同功能类型的device driver。然而,对于soc来说,它应该怎么处理?其实,linux已经为我们想出了办法,那就是platform bus。platform是一个虚拟总线,要使用它,只需要两步就可以。这里,不妨以mini2440常用的dm9000网卡举例说明。
1、注册dm9000设备
对于bus设备,一般如果device上线了,那么driver会自动加载。但是platform bus是一个假的总线,所以不可能自动加载。这个时候,系统就需要我们手动添加设备,这样后续也可以实现自动加载driver了。因此在arch/arm/mach-s3c24xx/mach-mini2440.c就存在这么一段代码,
static struct platform_device mini2440_device_eth = {.name= "dm9000",.id= -1,.num_resources= ARRAY_SIZE(mini2440_dm9k_resource),.resource= mini2440_dm9k_resource,.dev= {.platform_data= &mini2440_dm9k_pdata,},};
2、编写dm9000驱动,这段代码位于drivers/net/ethernet/davicom/dm9000.c
只要dm9000被注册,那么这里的驱动就会被加载。
static struct platform_driver dm9000_driver = {.driver= {.name = "dm9000",.pm = &dm9000_drv_pm_ops,.of_match_table = of_match_ptr(dm9000_of_matches),},.probe = dm9000_probe,.remove = dm9000_drv_remove,};
由于之前dm9000设备已经注册,那么在insmod dm9000.ko的时候,代码会一直执行下去。因为linux会在注册dm9000驱动之时,发现当前正好有一个dm9000的设备,所以会直接调用probe函数。当然在probe函数里面,它还会注册dm9000_netdev_ops结构、通过request_irq注册中断,基本的驱动结构基本上就是这样的。
3、mini2440的其他设备驱动
有了dm9000的范例,你会发现soc上的大部分驱动默不是用这种方法完成的,这大概也是soc特有的一种的驱动方式吧。
比如gpio驱动,
static struct platform_device mini2440_button_device = {.name= "gpio-keys",.id= -1,.dev= {.platform_data= &mini2440_button_data,}};
比如led驱动,
static struct platform_device mini2440_led1 = {.name= "s3c24xx_led",.id= 1,.dev= {.platform_data= &mini2440_led1_pdata,},};static struct platform_device mini2440_led2 = {.name= "s3c24xx_led",.id= 2,.dev= {.platform_data= &mini2440_led2_pdata,},};static struct platform_device mini2440_led3 = {.name= "s3c24xx_led",.id= 3,.dev= {.platform_data= &mini2440_led3_pdata,},};static struct platform_device mini2440_led4 = {.name= "s3c24xx_led",.id= 4,.dev= {.platform_data= &mini2440_led4_pdata,},};static struct platform_device mini2440_led_backlight = {.name= "s3c24xx_led",.id= 5,.dev= {.platform_data= &mini2440_led_backlight_pdata,},};
比如声卡驱动,
static struct platform_device mini2440_audio = {.name= "s3c24xx_uda134x",.id= 0,.dev= {.platform_data= &mini2440_audio_pins,},};
如果需要看所有的platform设备注册情况,只需要看这个结构体就可以了。
static struct platform_device *mini2440_devices[] __initdata = {&s3c_device_ohci,&s3c_device_wdt,&s3c_device_i2c0,&s3c_device_rtc,&s3c_device_usbgadget,&mini2440_device_eth,&mini2440_led1,&mini2440_led2,&mini2440_led3,&mini2440_led4,&mini2440_button_device,&s3c_device_nand,&s3c_device_sdi,&s3c2440_device_dma,&s3c_device_iis,&uda1340_codec,&mini2440_audio,};
soc的驱动流程远没有大家想象的那么复杂,建议大家循着这个脉络慢慢学,总能找到适合自己的学习方法。
ps:
有同学可能好奇,这么多驱动都在,怎么没有dram和pll呢?其实这两个呢,一般在uboot里面就配置好了,不再修改了。