?? readme
字號:
What part have I changed :1. Completely seperate the data struct and handlers of isoc transfer from the main struct. About data struct : I used list head to arrange all isoc data get from hc_interrupt and put the data packet onto a specific list head. These data will be processed within tasklet (shrink the interrupt handler cause the time is precious). Inanother sense, the isoc data is put in a huge FIFO. About handlers: seperate them from ATL. Just for the convenience of coding.Why I did these: I found out that in the situation system is under severe load (eg: we are doing H.261 encoding and decoding while capturing image from usb camera), sometimes the sof interrupt cannot be handled in time and even we met with the situation of miss sof interrupt. This will invoke quirk in the original driver. To recover from this quirk, we made up our mind to completely recoding the isoc transfer part.About chip bug: There are something Philips didn't tell us: 1. On the point of sof, if the driver is still reading or writing data from or into ITL buffer, chances are that oneof the Ping-pang Ram will "die", that is ITLxBufferFull is always set to logical "1" and we can no longer use that ITL buffer. To handle this we have to check HcFmRemaining to see if we have free time to do the work : ( 2. The situation is the same with ATL Buffer. We have to limit the ATL transfer within 1ms, otherwise we may meet with ATLBufferFull : (To do: On my platform (Intel Sitsang Evaluation Board with PXA255) sometimes we may meet with chip reset, all internal registers are set to default value. Currently my solution is rmmod & insmod -_-b . Hope someone who also meet with the problem can solve this.My Environment: arm-linux-2.4.19-rmk7
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -