自從 2.6.27 發布以來，我就沒有再 post 新的 patch 了。當然不是因為熱情消失了，主要是因為最近這幾個月工作上的事情比較繁忙，下班回到家就有些懶了；再加上上個禮拜個人家中開發用的 PC 主機板出了問題，開不了機，拿去送修又折騰了一段時日，是故這個月沒什麼產出。
不過好在主機板送修回來了，如果測試後確定沒問題，那麼等到工作告一段落，計畫應該就可以繼續進行下去。
2008年10月11日 星期六
加入 Frame buffer 支援
上個月底，我上傳了另一個 patch，主要為加入開發板的 LCD 支援。由於 S3C2440 的 LCD 控制器已有完整的驅動程式支援，是故在設定上也相當容易。你需要根據面板的 datasheet 來設定如解析度、pixel clock、bpp (bits per pixel)和其他相關的 timing 參數，剩下的 LCDCON5 的內容可直接參考其他開發板的設定。
和面板有關的參數設定在 struct s3c2410fb_display 這個結構中，其宣告為
struct s3c2410fb_display {
/* LCD type */
unsigned type;
/* Screen size */
unsigned short width;
unsigned short height;
/* Screen info */
unsigned short xres;
unsigned short yres;
unsigned short bpp;
unsigned pixclock; /* pixclock in picoseconds */
unsigned short left_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short hsync_len; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short upper_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short lower_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short vsync_len; /* value in lines (TFT) or 0 (STN) */
/* lcd configuration registers */
unsigned long lcdcon5;
};
以我的面板為例，這塊面板是 HITACHI 的七吋面板，型號為 TX18D16VM1CAA，根據手冊所記載，其可接受的 pixel clock 的最大週期為 33ns (相當於 30KHz)；Hsync 訊號寬度為 128 個 pclk，螢幕左方邊界寬度為 88 個 pclk，右方為 40 pclk；Vsync 訊號寬度為 2 個 Hsync 週期，上方邊界寬度為 32 個 Hsync，下方為 11 個 Hsync。解析度為 800x480。
程式碼加入後，在 make config 中開啟 S3C24xx 之 frame buffer 支援，重新編譯後下載至開發板即可。
另外，你也可以在核心啟動參數中加上 fbcon=rotate:<n> 來設定螢幕的方向。0 為不旋轉，1 為旋轉 90 度，2 為旋轉 180 度，3 為旋轉 270 度，方向皆為逆時針方向。
和面板有關的參數設定在 struct s3c2410fb_display 這個結構中，其宣告為
struct s3c2410fb_display {
/* LCD type */
unsigned type;
/* Screen size */
unsigned short width;
unsigned short height;
/* Screen info */
unsigned short xres;
unsigned short yres;
unsigned short bpp;
unsigned pixclock; /* pixclock in picoseconds */
unsigned short left_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short right_margin; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short hsync_len; /* value in pixels (TFT) or HCLKs (STN) */
unsigned short upper_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short lower_margin; /* value in lines (TFT) or 0 (STN) */
unsigned short vsync_len; /* value in lines (TFT) or 0 (STN) */
/* lcd configuration registers */
unsigned long lcdcon5;
};
以我的面板為例，這塊面板是 HITACHI 的七吋面板，型號為 TX18D16VM1CAA，根據手冊所記載，其可接受的 pixel clock 的最大週期為 33ns (相當於 30KHz)；Hsync 訊號寬度為 128 個 pclk，螢幕左方邊界寬度為 88 個 pclk，右方為 40 pclk；Vsync 訊號寬度為 2 個 Hsync 週期，上方邊界寬度為 32 個 Hsync，下方為 11 個 Hsync。解析度為 800x480。
程式碼加入後，在 make config 中開啟 S3C24xx 之 frame buffer 支援，重新編譯後下載至開發板即可。
另外，你也可以在核心啟動參數中加上 fbcon=rotate:<n>
2008年9月12日 星期五
[好文] 如何加入 Linux 開發社群
How to participate in the Linux Community
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
http://ldn.linuxfoundation.org/book/how-participate-linux-community
就在幾個月前，動心起念想要貢獻一些程式碼時，還真是不知該如何入門；深怕一個不小心，也許是程式的錯誤，或是英文不好引起誤會，或不了解某些規矩，而被 list 上的開發者給打槍，並回以鄙夷的指責。不過在 post 了幾個 patch 之後，事實證明了我是多慮了。當然還是有些規矩要遵守，只是犯了錯也沒那麼嚴重，通常開發者會好心提醒你該作什麼事，改回來就好，社群仍然會歡迎你的加入。
當然如果可以有一些文件教導我們這些新人，豈不更好？幸好有這本小書的出現，替我們指點迷津。24 頁的內容包含新進開發者該有的心態，以及該如何和社群互動、修改程式、準備及上傳 patch、撰寫信件的注意事項、開發者常犯的錯誤等等，足夠菜鳥們在正式踏入前有個心理準備，而我也從中受惠許多，發現了一些自己不曾注意到的小細節，或許可以再做得更好。
總之，強烈推薦新進開發者一定要讀讀這本書。
2008年9月1日 星期一
The fix for the SD controller driver
前一陣子在測試新加入的 SD 驅動程式時，發現了一個怪異的問題：某些卡可以正確偵測，某些卻不行。目前我所可以拿來測試的 SD 卡有兩塊；一塊是 512MB，SD 1.1 標準的卡，另一塊則是 256MB，SD 2.0 的卡。第一張卡沒有問題，但第二張卡卻出現以下的錯誤訊息：
雖然我並不非常熟悉 SD 的 protocol，但我覺得應該不是上層 protocol stack 的問題，畢竟第一張卡是可以正確運作的；由於 S3C2440 的使用手冊上載明這個控制器只有符合 SD 1.0 的規範，是故猜想可能是控制器的問題，所以我送了一個 patch，主要是在重設控制器以後，重新打開 SD 的時脈輸出，以便使後續的命令可以繼續運作。
即使手上有晶片使用手冊，並仔細研讀，但在面對這種在文件上毫無著墨的怪異行為時，仍是不免讓人感到挫折。
PS.
MMC protocol stack 的維護者 Pierre Ossman 提醒我，不要在 SD 卡的電源關閉時開啟 SD 時脈訊號，此舉有可能會導致 SD 卡的損壞。不過我認為應該不會發生這種情況；會執行到這段程式碼時，表示 SD 卡的電源已被開啟，並且已經開始接受命令了。又控制器重設時並沒有動到對應於 SD 時脈的 GPIO 針腳的狀態，是故應該不會有損壞的問題。
倒數第四行出現了 command timeout 的訊息，再仔細查看，發生錯誤的命令是 CMD6 (switch card function)，而之前的命令是 ACMD51 (read SCR)，該命令需要設定資料傳輸來讀取 SCR 的值。怪就怪在，當資料已傳輸完成，下個指令 (CMD6) 要重新設定資料傳輸時，卻發現狀態暫存器中的旗標仍然指示資料在傳輸中，因而驅動程式強迫終止資料傳輸，並重設 (reset) 控制器。重設的結果，便是所有暫存器中的內容回復為初始化前的預設值，同時關閉了控制器送給 SD 卡的時脈輸出。當然緊接在後的命令也都跟著錯誤。s3c2440-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: CMDSTAT: error CMDTIMEOUT
s3c2440-sdi s3c2440-sdi: CMDSTAT: error CMDTIMEOUT
s3c2440-sdi s3c2440-sdi: CMDSTAT: error CMDTIMEOUT
s3c2440-sdi s3c2440-sdi: CMDSTAT: error CMDTIMEOUT
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: running at 265kHz (requested: 264kHz).
s3c2440-sdi s3c2440-sdi: mci_setup_data() transfer stillin progress.
s3c2440-sdi s3c2440-sdi: CMDSTAT: error CMDTIMEOUT
s3c2440-sdi s3c2440-sdi: powered down.
mmc0: error -110 whilst initialising SD card
s3c2440-sdi s3c2440-sdi: powered down.
雖然我並不非常熟悉 SD 的 protocol，但我覺得應該不是上層 protocol stack 的問題，畢竟第一張卡是可以正確運作的；由於 S3C2440 的使用手冊上載明這個控制器只有符合 SD 1.0 的規範，是故猜想可能是控制器的問題，所以我送了一個 patch，主要是在重設控制器以後，重新打開 SD 的時脈輸出，以便使後續的命令可以繼續運作。
即使手上有晶片使用手冊，並仔細研讀，但在面對這種在文件上毫無著墨的怪異行為時，仍是不免讓人感到挫折。
PS.
MMC protocol stack 的維護者 Pierre Ossman 提醒我，不要在 SD 卡的電源關閉時開啟 SD 時脈訊號，此舉有可能會導致 SD 卡的損壞。不過我認為應該不會發生這種情況；會執行到這段程式碼時，表示 SD 卡的電源已被開啟，並且已經開始接受命令了。又控制器重設時並沒有動到對應於 SD 時脈的 GPIO 針腳的狀態，是故應該不會有損壞的問題。
2008年7月29日 星期二
加入 SD/MMC 支援
昨天送了一個 patch，主要為加入 SD/MMC 的支援到這塊開發板上。由於在最近幾個月，git kernel 終於加入了 S3C24xx 系列 SD/MMC 驅動程式的支援，是故我的修正就只是將這塊板子的設定照著填入對應的資料結構內即可。
另外稍微需要做些修改的地方在於，s3cmci.c 中對於 S3C2410 及 S3C2440 的初始化有一點不同，而 Ben Dooks 在 /arch/arm/plat-s3c24xx/devs.c 所定義的 s3c_device_sdi 名稱為 "s3c2410-sdi"，這部分要改為使用 "s3c2440-sdi"。此外，在 card detection 上，這塊開發板使用的是 GPIO G10，也要額外設定其 s3c24xx_mci_pdata 結構。
另外稍微需要做些修改的地方在於，s3cmci.c 中對於 S3C2410 及 S3C2440 的初始化有一點不同，而 Ben Dooks 在 /arch/arm/plat-s3c24xx/devs.c 所定義的 s3c_device_sdi 名稱為 "s3c2410-sdi"，這部分要改為使用 "s3c2440-sdi"。此外，在 card detection 上，這塊開發板使用的是 GPIO G10，也要額外設定其 s3c24xx_mci_pdata 結構。
2008年7月11日 星期五
ARM Linux source tree freeze
2008年7月1日 星期二
發送第一個 patch
大約在上星期的時候，我發送了第一個針對開發板修改的 patch 後，Ben Dooks 隨後不久便回覆我，除了指出我一個未察覺到的錯誤外，還希望我針對一些他不明瞭的部分再多做說明。當我回答後，他似乎覺得沒什麼大問題，便要我針對之前的 review comment 再做修改，並且先將這些修正修補到一份乾淨的核心原始碼樹中做編譯測試，確定沒問題後，再把修改過的 patch 送上來。
經過了幾天，在上星期六，我再發送了第二個版本的 patch，這次就沒什麼問題了，Ben 也會將這份修正加入到他的合併清單之中。
當然對於嫻熟於開放原始碼社群運作模式的人，送 patch 是家常便飯，沒什麼值得大書特書的；不過對於像我這種新手來說卻是一種很奇妙的體驗，藉由送修正、審查修正、再送修正…這樣多次往返的流程，讓程式碼更臻完美，得以一種簡潔的樣貌合併進入主流核心之中。正如 Thomas Gleixner 所言，和核心團隊一同運作，除了增進程式碼的品質，開發者自身的能力也會在這樣互動的過程中逐步提升，這是一個多贏的局面。
我想，我未來應該還會再繼續送 patch 吧。
經過了幾天，在上星期六，我再發送了第二個版本的 patch，這次就沒什麼問題了，Ben 也會將這份修正加入到他的合併清單之中。
當然對於嫻熟於開放原始碼社群運作模式的人，送 patch 是家常便飯，沒什麼值得大書特書的；不過對於像我這種新手來說卻是一種很奇妙的體驗，藉由送修正、審查修正、再送修正…這樣多次往返的流程，讓程式碼更臻完美，得以一種簡潔的樣貌合併進入主流核心之中。正如 Thomas Gleixner 所言，和核心團隊一同運作，除了增進程式碼的品質，開發者自身的能力也會在這樣互動的過程中逐步提升，這是一個多贏的局面。
我想，我未來應該還會再繼續送 patch 吧。
訂閱：
文章 (Atom)