做过51单片机或者ARM开发的人都知道，单片机内部都有自己的“片内外设”，比如UART，比如I2C，比如SPI等等。。。
写单片机程序的时候，比如对于UART的驱动，我们都是在程序中直接写一套函数，来操作相关的UART寄存器，在程序中的其它地方调用这些函数，完成串口的收发。 在小规模的单片机程序中，这样做是再正常不过的。
但是，在规模庞大的LINUX内核中，要处理各种各样的CPU，各种各样的UART收发器，上述办法就有心无力了：没有灵活性，无法移植，接口不一致，很难想象有一个UART驱动程序能够完成这个工作。
OK，有了上面的理解，我们再来看LINUX中的platform device和platform driver。 platform device 其实就是相当于“片内外设”，比如UART，内核刚开始启动时，并不知道它所运行的CPU上面有哪些片内外设。有没有UART? 有没有I2C？等等这些问题，内核都是一无所知。而platform device的作用就是全面定义描述该CPU的所有片内外设，并注册到系统中，每一个platform device都有一个唯一的名字name。
更进一步，将“片内外设”扩展到“板载外设”，一块电路板上不止有CPU，还有很多其它设备通过GPIO，I2C/SPI等总线来连接，比如led灯，就需要一个GPIO来控制它的亮灭；比如继电器，也需要一个GPIO来控制它的开合。 GPIO控制的开关设备是最简单的，对应的驱动也是非常简单的。
RK30SDK使用了ROCKCHIP的CPU，型号是RK3066。在RK30SDK中，我们以led驱动为例，首先查找它的platform device定义，在arch/arm/mach-rk30/board-rk30-box.c文件中，有如下的定义：
static struct platform_device rk29_device_gpio_leds = {
.name = "leds-gpio",
.id = -1,
.dev = {
.platform_data = &rk29_leds_pdata,
},
};
这个设备的名称是"leds-gpio"，这个platform_data里面包含了各个不同led的名称/GPIO资源占用情况，它的定义如下：
static struct gpio_led_platform_data rk29_leds_pdata = {
.leds = rk29_leds,
.num_leds = ARRAY_SIZE(rk29_leds),
};
似乎有很多led，定义成了一个数组？带着疑问，我们找到rk29_leds的定义：
#ifdef CONFIG_LEDS_GPIO_PLATFORM
static struct gpio_led rk29_leds[] = {
#ifdef CONFIG_DISPLAY_KEY_LED_CONTROL
#ifdef CONFIG_HDMI_RK30
{
.name = "hdmi-soc",
.gpio = RK30_PIN4_PD7,
// .default_trigger = "timer",
.active_low = 0,
.retain_state_suspended = 0,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
#endif
#ifdef CONFIG_HDMI_ITV
{
.name = "hdmi-transmitter",
.gpio = RK30_PIN4_PD2,
.active_low = 0,
.retain_state_suspended = 0,
.default_state = LEDS_GPIO_DEFSTATE_OFF,
},
#endif
没错，这就是一个数组，只是有很多ifdef。不用管它，他们的意思是这里的源码支持在make menuconfig里面进行配置，如果将来你设计的电路板上有hdmi发送的指示灯，就可以把CONFIG_HDMI_ITV打开，这样led驱动里面就包含HDMI的发送指示灯了。gpio = RK30_PIN4_PD2这句话表示这个led灯是通过RK30_PIN4_PD2这个管脚进行控制的，如果你去看电路原理图，这个管脚一定是连着一个led灯，如果在你设计的电路板上是另外的管脚，那么这里改成你自己的管脚名称就行了。
至此，我们看完了RK上led的platform device定义了，一句话，它描述了RK开发板上led的所有控制IO口管脚，led名称等信息。实际上，这些配置代码是通过电路原理图写出来的，如果你能看懂原理图，那你也能写出这样的代码。
那么，platform device是如何告知内核自己的存在呢？我们继续在board-rk30-box.c中寻找rk29_device_gpio_leds出现的地方：
static struct platform_device *devices[] __initdata = {
#ifdef CONFIG_BACKLIGHT_RK29_BL
&rk29_device_backlight,
#endif
#ifdef CONFIG_FB_ROCKCHIP
&device_fb,
#endif
#ifdef CONFIG_ION
&device_ion,
#endif
#ifdef CONFIG_ANDROID_TIMED_GPIO
&rk29_device_vibrator,
#endif
#ifdef CONFIG_LEDS_GPIO_PLATFORM
&rk29_device_gpio_leds,
#endif
OK，看来我们的rk29_device_gpio_leds被包含在了devices数组中，而且是支持make menuconfig配置的，这是多么的合情合理啊！我们可以在menuconfig中打开或者关闭led，非常好。其它地方没有再用到rk29_device_gpio_leds这个device了，我们需要继续寻找devices数组是怎么被使用的：
static void __init machine_rk30_board_init(void)
{
avs_init();
gpio_request(POWER_ON_PIN, "poweronpin");
gpio_direction_output(POWER_ON_PIN, GPIO_HIGH);
pm_power_off = rk30_pm_power_off;
rk30_i2c_register_board_info();
spi_register_board_info(board_spi_devices, ARRAY_SIZE(board_spi_devices));
platform_add_devices(devices, ARRAY_SIZE(devices));
board_usb_detect_init(RK30_PIN6_PA3);
#ifdef CONFIG_WIFI_CONTROL_FUNC
rk29sdk_wifi_bt_gpio_control_init();
#endif
}
哈哈，终于找到它了，看名字也知道这里是向内核注册platform device了，关于platform_add_devices的工作原理这里就不说了，网上一大把，无非就是调用另外一个函数将devices数组中的每一个device分别注册到系统中。这里上面的代码，这里先打个埋伏：platform_add_devices是注册所有的"platform"总线上的设备，"platform"是一个虚拟的总线，因为实际上这些外设并没有挂在总线上，只是通过GPIO简单的连接起来。而上面的rk30_i2c_register_board_info和spi_register_board_info则是分别注册I2C总线和SPI总线上的设备了，逻辑上来说，他们和platform总线的概念是对等的。I2C是广泛使用的，用来连接CPU和其它外部IC的总线，你所看到的各种sensor，EEPROM等都是通过I2C和CPU进行通信的。
在文件的末尾，有这样的代码：
MACHINE_START(RK30, "RK30board")
.boot_params = PLAT_PHYS_OFFSET + 0x800,
.fixup = rk30_fixup,
.reserve = &rk30_reserve,
.map_io = rk30_map_io,
.init_irq = rk30_init_irq,
.timer = &rk30_timer,
.init_machine = machine_rk30_board_init,
MACHINE_END
看样子，一起都是从machine_rk30_board_init函数开始的，如果我们倒回来看，就知道这个led device是如何被注册到内核里面的。
至于led device对应的platform driver，我们在下一篇分析。
