以下內容源於朱有鵬嵌入式課程的學習,如有侵權,請告知刪除。

四、platform平臺匯流排工作原理1

1、何為平臺匯流排?

(1)屬於匯流排中的一種,相對於usb、pci、i2c等物理匯流排來說,platform匯流排是虛擬的、抽象出來的。

(2)CPU與外部通訊的2種方式:地址匯流排式連線和專用介面式連線(比如nand和cpu的連線)

  • 平臺匯流排對應地址匯流排式連線裝置(也就是SoC內部整合的各種內部外設)。

(3)思考:為什麼要有平臺匯流排?

  • 為了管理上的方便和統一。

2、平臺匯流排下管理的2員大將

(1)platform工作體系都定義在drivers/base/platform.c中。

(2)兩個結構體:platform_device和platform_driver。

struct platform_device
{
	const char * name; // 平臺匯流排下裝置的名字
	int id;
	struct device dev; // 所有裝置通用的屬性部分
	u32 num_resources;// 裝置使用到的resource(IO或者中斷號等)的個數
	struct resource* resource;// 裝置使用到的資源陣列的首地址
	
	const struct platform_device_id* id_entry;// 裝置ID表,很多個類似的同系列的產品,可以用同一個驅動
	/* arch specific additions */
	struct pdev_archdata archdata;// 自留地,用來提供擴充套件性的,表示裝置的一些屬性
};
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;// 所有裝置共用的一些屬性
	const struct platform_device_id *id_table;// 裝置ID表,表示支援哪些裝置
};

(3)兩個介面函式

  • platform_device_register(一般不使用這個,而是使用platform_driver_register中的probe函式?有待深入研究),在系統啟動時(見五1(2)),用來註冊裝置。
  • platform_driver_register,用來註冊驅動。

五、platform平臺匯流排工作原理2

1、平臺匯流排體系的工作流程

(1)第一步:系統啟動時,在bus系統中註冊platform(使得在/sys/bus/目錄有platform)。

(2)第二步:核心移植(把硬體的資訊寫到軟體裡)的人負責提供platform_device;(即提供板檔案,檔案裡有裝置資訊。比如Mach-x210.c)


(3)第三步:寫驅動的人負責提供platform_driver;(主要是填充結構體並register)



(4)第四步:platform的match函式發現driver和device匹配後(通過name來匹配),呼叫driver的probe函式來完成驅動的初始化和安裝,然後裝置就工作起來了。(這個是自動的)

2、程式碼分析:platform匯流排本身註冊

     



(1)每種匯流排(不光是platform,usb、i2c那些也是)都會帶一個match方法,用來對匯流排下的device和driver進行匹配。

  • 理論上每種匯流排的匹配演算法是不同的,但是實際上一般都是看name的。

(2)platform_match函式就是平臺匯流排的匹配方法。

  • 如果有id_table,則說明驅動可能支援多個裝置;
  • 這時候要去對比id_table中所有的name,只要找到一個相同的就匹配上了不再找了,如果找完id_table都還沒找到就說明沒有匹配上。
  • 如果沒有id_table或者沒有匹配上,那就直接對比device和driver的name,如果還沒匹配上那就匹配失敗。

(3)上面完成了第一步。下面完成第二第三步。(見六)

六、platform平臺匯流排工作原理3

1、platform裝置和驅動的註冊過程(參考leds-s3c24xx.c檔案)

(1)platform_driver_register,驅動部分:


(2)platform_device_register,裝置部分

  • 如何找裝置部分?即在板檔案定義的裝置資訊?
  • 通過名字,即搜尋名字。舉個例子如下(某個裝置的資訊):


  • 眾多裝置組成一個數組,然後逐個註冊。(不能有一個出錯!)
  • 對於linux2.6 arm平臺而言,對platform_device的定義通常在bsp的板檔案中實現。
  • 板檔案將裝置歸納為一個數組,最終通過platform_add_devices()函式統一註冊

2、platform_data怎麼玩



    


  • platform_data其實就是設備註冊時提供的、與裝置有關的一些資料(譬如裝置對應的gpio、使用到的中斷號、裝置名稱……);
  • 這些資料在裝置和驅動match之後,會由裝置方轉給驅動方(probe的第一句程式碼)
  • 驅動拿到這些資料後,通過這些資料得知裝置的具體資訊,然後來操作裝置。
  • 這樣做的好處是:驅動原始碼中不攜帶資料,只負責演算法(對硬體的操作方法)。
  • 現代驅動設計理念就是演算法和資料分離,這樣最大程度保持驅動的獨立性和適應性。
  • 注意:leds-s3c24xx是驅動檔案,是不會有裝置資訊的,裝置資訊在板檔案中定義。

3、match函式的呼叫軌跡

4、probe函式的功能和意義