一.前言

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

二.DWC_ether_qos的軟復位

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

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

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

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

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

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

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

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

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

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

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

四.總結

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