OMAP3 DSS 初始化过程（2）总线关系

    这篇文章是对前面一片文章的补充。在文章（1）中遗漏了一些重要信息，而这些信息也是在随后的调试和修改过程中发现的。这里再做一次总结。还是那句老话，如有不足，请指出文章中错误的观点。

    文章（1）中提到了omap_dss_register_device和omap_dss_register_driver这两个函数，这两个函数正是通过dss_bus总线进行配对的。在这两个函数配对之还有一个linux提供的总线配对函数，platform_device和platform_driver。通过以下：

static struct platform_device *omap3_stalker_devices[] __initdata = {
        &omap3_stalker_dss_device,
        &omap3stalker_camkit_device,
};
platform_add_devices(omap3_stalker_devices, ARRAY_SIZE(omap3_stalker_devices));

    一个设备描述和一个device注册函数完成了platform_device的注册，然后通过name字段比较omapdss完成了platform_driver：找到了static struct platform_driver omap_dss_driver。随后调用probe函数，这个probe函数是：static int omap_dss_probe(struct platform_device *pdev)。注意函数的参数是struct platform_device *pdev。也就是说这个函数的调用使用的是linux自带的总线上设备和驱动的匹配方式，成功后导致probe的调用。那么如何总linux总线过度到omap的dss总线？文章（1）中也有交代但是没有交代清楚，随后在自己的调试过程中再次发现和总结了一下。

    在函数omap_dss_probe，中出现了r = omap_dss_register_device(dssdev);，这里才开始omap_dss_device的注册，到了这里从一个for循环一次对应num_devices分别注册了lcd070，lcd043，venc，dvi。dss_bus上出现了设备，那么随后的驱动注册再回调用dss_bus提供的match函数，从而最后找到相应的probe函数，比如：omap_dss_register_driver(&at070tn13_panel)。注意omap_dss_register_driver函数中dssdriver->driver.probe = dss_driver_probe;这个probe才是通过dss_bus匹配后调用的probe函数。随后在这个函数中分别又对自己的lcd070做了probe函数。

static struct omap_dss_driver at070tn13_panel = { 结构体中有一个.name   = "panel-at070tn13",字段。这个字段是platform_driver的类型。

    逻辑关系就说道这里，只是稍微介绍了一下，随后的软件分析和设计分析中在细细说来。希望有相同兴趣爱好的omap或者Davinci系列的爱好者交流。

    有人问我：为什么要去研究软件架构？我也很无奈，因为买来的开发板还有Demo都是好的，我当然不会去分析和阅读，就是应为不能工作，总是在修修补补，索性一下沉下心来，搞搞透。