一.前言

一般模塊都會有軟復位的功能,軟復位在驅動編寫中很重要。一般初始化時執行軟復位使得模塊進入確定的初始狀態以提高可靠性，異常時也可以重新初始化來恢復，所以軟復位在驅動中一般是必須要做的動作。對應復雜的IP其復位過程其實是很復雜的，有很多前提和依賴，對于驅動編寫來說也有一些需要注意的地方甚至是有一些坑，所以本篇單獨來講講DWC_ether_qos的軟復位。如果你有遇到DWC_ether_qos軟復位的問題，建議可以看看本文章，說不定就有你的問題的答案!

二.DWC_ether_qos的軟復位

軟復位的作用簡單的可以總結為復位控制邏輯(比如狀態機等)，和相關的資源(比如寄存器值恢復到默認狀態等)。

DWC_ether_qos的軟復位參考手冊P1013，偏移0x1000的寄存器DMA_Mode寄存器的位0,SWR的解釋。

從以上描述可以看出其實信息量是很多的，換句話說需要注意的地方是很多的，以下做一個總結

1.觸發軟復位,MAC和DMA控制器會復位DMA，MTL，MAC這幾個子系統的內部邏輯和相關寄存器。

2.該位是自清零的，即軟件寫1觸發軟復位，硬件復位完成清零。

3.必須等到DWC_ether_qos所有的時鐘域都完成復位才會完成，才會清零該位。

4.該位為0之前，即為1時不能寫DWC_ether_qos的任何寄存器。

5. 該位置位后，不能立馬去回讀該位，需要等待4個CSR周期后才能讀 ，因為狀態更新需要時間(具體的原因就涉及具體的總線協議了)。這里是驅動編寫的一個容易掉坑的地方需要注意。立即讀可能讀出0認為復位完成了(實際復位還未完成)馬上去操作其他寄存器會導致不可預知結果，這種結果是隨機的導致的現象更可能是隨機加隨機。
6. 復位需要PHY的所有input時鐘比如RXC有效 ，這一點也是驅動編寫容易掉坑的地方，如果RXC引腳映射錯誤，PHY未就緒，都可以導致沒有RXC時鐘而不能完成復位。如果你遇到不能軟復位的問題第一步就查這里吧!
7. 復位完成時間是不確定的 ，需要等到所有時鐘域完成復位才算，所以要等最慢的那個完成才算。底層接口最好只提供set_rst和get_rst兩個接口，由上層去調用該兩個接口實現等待查詢操作。因為時間不定，所以調用者可以使用線程等待，超時重試等處理，而如果底層接口使用指令死等則效率太低，會占用CPU，并且也不知道設置死等多長時間合適(指令死等時間受主頻等影響，使用定時器則需要占用硬件外設且不具備可移植性)。

三.軟復位不能完成的案例

我驅動開發時就遇到過不能軟復位的案例，后面調試發現一個是RXC引腳映射錯誤導致的，另外一個就是PHY沒有輸出RXC的時鐘導致的，所以如果你遇到類似問題先查上述原因吧。

另外觸發復位后等待4個CSR時鐘以上再去查詢這點也很重要，因為這個很可能導致隨機問題，也就是你可能立馬回讀讀到的是1，那么繼續等待為0復位完成，沒問題。也可能是立馬讀到0，沒有復位你認為復位了繼續去操作寄存器，此時操作寄存器操作行為不可預料。所以很可能導致隨機異常，并且很難定位。這個時候你可能會遇到白天有問題，晚上沒問題(因為溫度導致讀寫時序細微差異可能導致立馬回讀的狀態不一樣)，重新編譯一下運行有問題，再重新編譯一下運行沒問題，加個打印有問題，去掉又沒問題等各種詭異的問題，此時你可能會覺得這是神學了，只能燒香拜佛了。實際上任何問題都有確定的原因的只是你不知道而已，所以驅動開發者遇到問題從來不說神學，也從來不瞎試，而是從原理分析，看手冊，梳理原理，梳理路徑，反推，測信號，逐步推進等方式去定位根本原因。這就是驅動開發與一般開發的區別。如果還找不到原因，上廁所時翻翻手冊吧，你可能會有所發現。隨手翻手冊，手冊當小說看，是驅動開發的必備素養，基本上我每開發一個IP驅動，至少手冊的所有文字都要看一遍以上，尤其是標注*號的，note的，其他就是各個模塊調試時詳讀具體章節加翻閱，寄存器至少是每一個寄存器的每一個bit都要看一遍的。當然開發階段熟讀手冊，勘誤手冊，積累，多調試不通配置的效果等很重要，這樣才可能遇到問題知道查哪，才有可能上廁所時靈感迸發。

四.總結

驅動開發需要注重細節，了解原理很重要，手冊一定要熟讀，經驗積累也很重要，一定要充分調試各個功能，多去嘗試不同配置對應的不同效果。