【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：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里面就配置好了，不再修改了。
