-
Notifications
You must be signed in to change notification settings - Fork 1
developing qcom camss
Since v4l-utils 1.26 and above switched to meson build and cross-compile static build depends on aarch64-linux-gnu-pkg-config and is not found in Ubuntu 22.04 but 20.04 only, so there is no idea how to achieve this latest release on arm64 platform. To make it simple, older version is used.
Below is a workaround to have v4l-utils 1.24 arm64 static build as below:
LDFLAGS="--static -static" ./configure --disable-shared --enable-static
Together with a los20 recovery image, put media-ctl v4l2-ctl into ramdisk is possible.
Generally speaking camss depends on isp version, aka, msm8x19 is of early generation, 89x4, 660, 8998 845 are generation 17x, and 8250 is generation 47x. So for example sm7125 soc is similar to sdm845 and easily port from it. Refer to vendor devicetree for exact vfe/csid/csiphy version. By grab of vendor devicetree, it is clear that sm7125 and sm7150 shared virtually same camss IP block except the csiphy version differ
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_csiphy sdmmagpie-camera.dtsi
cam_csiphy0: qcom,csiphy@ace0000 {
cam_csiphy1: qcom,csiphy@ace2000{
cam_csiphy2: qcom,csiphy@ace4000 {
cam_csiphy3: qcom,csiphy@ace6000 {
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_csid sdmmagpie-camera.dtsi
cam_csid0: qcom,csid0@acb3000 {
cam_csid1: qcom,csid1@acba000 {
cam_csid_lite0: qcom,csid-lite0@acc8000 {
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_vfe sdmmagpie-camera.dtsi
cam_vfe0: qcom,vfe0@acaf000 {
cam_vfe1: qcom,vfe1@acb6000 {
cam_vfe_lite0: qcom,vfe-lite0@acc4000 {
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_vfe atoll-camera.dtsi
cam_vfe0: qcom,vfe0@acaf000 {
cam_vfe1: qcom,vfe1@acb6000 {
cam_vfe_lite: qcom,vfe-lite@acc4000 {
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_csid atoll-camera.dtsi
cam_csid0: qcom,csid0@acb3000 {
cam_csid1: qcom,csid1@acba000 {
cam_csid_lite: qcom,csid-lite@acc8000 {
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep cam_csip atoll-camera.dtsi
cam_csiphy0: qcom,csiphy@ac65000 {
cam_csiphy1: qcom,csiphy@ac66000{
cam_csiphy2: qcom,csiphy@ac67000 {
cam_csiphy3: qcom,csiphy@ac68000 {
sm7125 is v1.2.2, the init reg can get from location:
drivers/media/platform/msm/camera/cam_sensor_module/cam_csiphy/include/cam_csiphy_1_2_2_hwreg.h
Difference between sm7150 and sm7125:
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep "qcom,csiphy-v1" atoll-camera*
atoll-camera.dtsi: compatible = "qcom,csiphy-v1.2.2", "qcom,csiphy";
atoll-camera.dtsi: compatible = "qcom,csiphy-v1.2.2", "qcom,csiphy";
atoll-camera.dtsi: compatible = "qcom,csiphy-v1.2.2", "qcom,csiphy";
atoll-camera.dtsi: compatible = "qcom,csiphy-v1.2.2", "qcom,csiphy";
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom# grep "qcom,csiphy-v1" sdmmagpie-camera*
sdmmagpie-camera.dtsi: compatible = "qcom,csiphy-v1.2", "qcom,csiphy";
sdmmagpie-camera.dtsi: compatible = "qcom,csiphy-v1.2", "qcom,csiphy";
sdmmagpie-camera.dtsi: compatible = "qcom,csiphy-v1.2", "qcom,csiphy";
sdmmagpie-camera.dtsi: compatible = "qcom,csiphy-v1.2", "qcom,csiphy";
root@DESKTOP-JU1IHIS:~/source/android_kernel_xiaomi_sm6250/qcom#
sm7125 share same IP block with sdm845 so it is purely a vfe-170, namely csid-170; where csid is not lived inside vfe and have its own iomem(reg_addr), not need to share with vfe iomem. sm8250 csid iomem is lived inside vfe iomem. so camss-csid.c have special handling for csid reg_addr. Some vfe-16x vfe-17x also share this design behavior.
refer to https://github.com/99degree/linux/wiki/dump-clk-value-by-debugcc to get running clk rates. refer to drivers/clk/qcom/camcc-atoll.c to get all needed clk rates. Generally speaking, camcc_xxx_src clks are not needed and camcc driver should taking care of them by SET_PARENT_RATE flag. but for new soc bringup, the clk parent relationship might not setup correctly so best to check with camcc clk driver too.
Put all needed clk rates into camss.c struct copied from sdm845.
V4L topology is dump through
https://github.com/99degree/linux/wiki/Media-dump-of-v4l-device
and
https://github.com/99degree/linux/wiki/v4l2%E2%80%90util-dump
The method is provided by https://patches.linaro.org/project/linux-media/patch/20230814141007.3721197-10-bryan.odonoghue@linaro.org/
the result is put here https://github.com/99degree/linux/wiki/v4l2%E2%80%90util-dump#dump-with-test-pattern-generator
To run the capture, here is an example to capture 3 frame from cmos. media-ctl and v4l2-ctl belongs to v4l-util and yavta source is available at https://github.com/99degree/yavta/
media-ctl --reset
media-ctl -V '"msm_csid0":0[fmt:SRGGB10/2592x1940 field:none]'
media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/2592x1940 field:none]'
media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
v4l2-ctl -d /dev/v4l-subdev4 -c test_pattern=0
v4l2-ctl -d /dev/v4l-subdev5 -c test_pattern=0
v4l2-ctl -d /dev/v4l-subdev6 -c test_pattern=0
media-ctl -V '"s5k5e9 13-002d":0[fmt:SRGGB10/2592x1940 field:none]'
media-ctl -V '"msm_csiphy2":0[fmt:SRGGB10P/2592x1940 field:none]'
media-ctl -l '"msm_csiphy2":1->"msm_csid0":0[1]'
yavta -B capture-mplane --capture=3 -n 3 -f SRGGB10P -s 2592x1940 /dev/video0 -F
Generally soc vendor kernel is keep changing for each release. in kernel 4.14 based soc, the camss is lived inside drivers/media/platform/msm/camera and kernel 4.19 onward, this is split into independent module outside kernel.
With is writing, is concentrated on v4.14 case. There are many debug way, cases like compile custom kernel and bring up with solo camera, disable all other by devicetree, etc. Something happened to do "#define pr_debug pr_info" in codes. One easy way to get some available dbg msg is as below. But still not enough to do development. At least cmos init value is not available.
debug_mdl from /sys/modules/cam_debug_util/parameters/debug_mdl
To log all modules, do "echo 0xffffffff > debug_mdl " To log particular module, change 0xffffffff to those values found in cam_debug_util.h
csiphy_dump from /sys/module/cam_csiphy_core/parameters/csiphy_dump
To dump registers of device open, do "echo 1 > csiphy_dump"
In this case "echo 0x800C > debug_mdl" is a good choice, that enable [CAM_ISP|CAM_CAPS|CAM_CSIPHY]
After enabling above kernel param, more dbg log archived. Below is some of useful extracts.
Here is the procedure.
- At Android LOS20 launcher,
- open camera app,
- Found that shows [0.7|0.9|1] focal as denoted back camera and front camera.
- Switch to the one desired.
- Press power button to lock the phone.
- adb shell dmesg -C && adb shell dmesg -w | tee log.07.camera.txt|grep CAM_
- Unlock phone screen and back to camera app, camera capture on
[ 2497.937484] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 826 CAM_ACQUIRE_DEV Success, sensor_id:0x559b,sensor_slave_addr:0x5a
...
[ 2497.969731] CAM_DBG: CAM-ISP: cam_ife_csid_cid_reserve: 612: CSID:1 res_sel:0x4003 Lane type:0 lane_num:2 dt:43 vc:0
...
[ 2497.978255] CAM_INFO: CAM-CPAS: cam_cpas_hw_start: 1021 AXI client=[2][csiphy][2] comp[1024], comp_ab[1024], uncomp[1024]
Above shows cmos_id[0x559b], i2c_addr[0x5a], is connected to [csiphy][2], csiphy_lane_number[2], lane_type[D-phy].
A rough writing of cmos driver development is at below for reference. https://github.com/99degree/linux/wiki/Porting-cmos-sensor-to-mainline-next
A debug driver code is port from 0xBOD source tree that show csiphy, csid and vfe reg/irq status https://github.com/99degree/linux/commits/working-20240527/
more to come