Porting cmos sensor to mainline next

Generally speaking this porting is very limited and soc/board dependent.

A very detail how-to is written by Yassine Oudjana, https://emainline.gitlab.io/2022/08/24/camera.html

The devlopment flow is as below:

1. get camss sybsys on and dump test pattern from csid
2. Get camcc and CCI up and running, for cmos sensor communication
3. Enable debug info in vendor kernel, best is to switch on debug options like
   1. /dev/mem
   2. debugfs
   3. Add pr_info in cam_sensor_module/cam_cci, dump all req that written to CCI
4. Find relevant cmos driver on other soc especially good source from MTK SOCs.
   1. Find/Search from github.com repo for example, search s5k5e9/ov16a1q/ov16a1x/gc8034
5. Determine topoligy of component connection about cmos_sensor and csiphy
   1. Lane number, and lane assigment (some case might use abnormal lane assigment instead of incremental e.g. [0 1] and [0 1 2], [0, 1 2 3])
6. Lane clk determination, according to various source, it is 240000000 as usual both in MTK and qcom soc, and 36000000 is also found a case.
7. Usual case there are cmos product family, so found a similar driver from mainline/mail-list is a good start. Quite funny example, s5k5e9 cmos have very similar reg pattern (almost identical) with imx214. So lets use it as code base.

It is hightly believe that cmos init reg write also depend on d-phy lane number. So lets make use of those value like dummy.

On some platform using libcamera, there are some important v4l control to present. Implement a dummy control to pass the libcamera check is a good choice too.

The debug information of sensor config is at below, it is a s5k5e9 cmos connected to sm7125 soc, aka miatoll phone. https://github.com/99degree/linux/wiki/developing-qcom-camss#get-more-info-from-los-kernel

and the debug procedure is at: https://github.com/99degree/linux/wiki/developing-qcom-camss#debugging-with-vendor-kernel