Increase kernel log ratelimit

在include/linux/ratelimit.h裡面有定義如下: #define DEFAULT_RATELIMIT_INTERVAL (5 * HZ) #define DEFAULT_RATELIMIT_BURST 10 意思是限制每5秒印10行code 所以可以改成100行, 可以看到更多log #define DEFAULT_RATELIMIT_INTERVAL (5 * HZ) #define DEFAULT_RATELIMIT_BURST 100

高通平台Dump Camera RAW Image

這邊是之前在sdm429/msm8937開發的經驗(mm-camera not camx) Android版本是11(R) Qualcomm提供兩種dump RAW image的方式 一個是使用RDI(RAW Dump Interface) adb shell setprop persist.vendor.camera.rdi.mode enable 另外就是Dump preview frame adb shell setprop persist.vendor.camera.raw_yuv 1  adb shell setprop persist.vendor.camera.preview_raw 1  adb shell setprop persist.vendor.camera.dumpimg 16711696  兩種的差別是, 如果使用RDI, 出來的RAW會是MIPI CSI2 Format (Chromatix那邊要選擇MIPI) 但如果使用dump preview frame, 則會是QCOM RAW格式 (Chromatix那邊要選擇Packed) MIPI ------> VFE ----> ... (MIPI CSI2) (QCOM RAW) 會有這樣的差別我的猜測是如果是RDI, 則是MIPI一過來就dump出來 但如果是dump preview frame的話, 則會經過VFE pack成QCOM RAW後才dump Dump出來的RAW圖可能會比原圖更大一些(因為qcom會做align, 會塞padding) 計算方式可以參考hardware/qcom/camera/QCamera2/stack/mm-camera-interface/src/mm_camera_stream.c Function mm_stream_calc_offset_raw

主管Coaching

主管Coaching

說以後有問題不要在會議上講, 我們私底下討論

蝦毀? 案子有問題不就是在會議上提出, 尋求解決方案嗎
回答說提出這些問題會影響團隊士氣

要一群搞BSP壓根沒碰過前後端的人一周內生出第一版可以動的backend service, 完全不同領域的東西
很多人連前後端的概念, database存取, RESTAPI等等都還不太熟悉, 剩至沒聽過的

想想schedule這樣排一定很多問題, 至少要額外給出一些給大家study的時間, 提出來結果說影響團隊士氣

士氣? 大家看到你這schedule就沒士氣了好嗎

然後呢, 他說結果是好的啊, 東西也有在時間內弄出來, 他schedule沒有問題

反而說我之後遇到問題要想如果在時間內達到要求, 不是直接說做不到

拜託, 那也是我額外花一堆時間幫忙處理才生出來的

說是雙贏, 額外花我的時間跟我說雙贏

弄出來就說雙贏, 那如果最後沒弄出來, 我看就是我們的問題, 跟你schedule沒關係喔

新主管sucks