hisilicon-osdrv-hi3516cv200: fix OV2735 .ini for MIPI (4 fields)

[moontwister]

Summary

Four wrong fields in cv200's ov2735_i2c_1080p.ini that prevent it from working as MIPI on real hardware:

Field	Was	Now	Why
[mode] input_mode	4	0 (INPUT_MODE_MIPI)	The same file's header comment lists INPUT_MODE_MIPI = 0; 4 is the unused successor of LVDS=2 / DC=3. With input_mode=4 the ISP driver never configures the MIPI RX block.
[mipi] data_type	3 (RAW_DATA_12BIT)	2 (RAW_DATA_10BIT)	OV2735 outputs RAW10, not RAW12. With data_type=3, majestic faithfully sends raw_data_type=3 to HI_MIPI_SET_DEV_ATTR and /proc/driver/hi_mipi ends up in RAW12 mode → garbled / no frames.
[mipi] lane_id	0|1|2|3|... (4-lane)	0|1|-1|-1|... (2-lane)	OV2735 on cv200 uses 2 lanes. Asking for 4 confuses the lane-mapper.
[vi_dev] Input_mod	2 (VI_INPUT_MODE_DIGITAL_CAMERA)	5 (MIPI)	cv200's [vi_dev] Input_mod and [mode] input_mode must agree. Master majestic (OpenIPC/majestic#278) now enforces this with a fail-fast: [mode] input_mode (0) and [vi_dev] Input_mod (2) disagree; expected Input_mod=5 for this input_mode.

cv300's already-correct ov2735_i2c_1080p.ini has the same MIPI fields (input_mode, data_type, lane_id) as this patch.

Test plan — verified end-to-end

On a TP-Link Kasa KC110 (Hi3518EV200 + OV2735 2-lane MIPI RAW10) against majestic master+bcf6700 (which adds the SET_DEV_ATTR: … diagnostic log):

Step	.ini state	Result
1	All four fields wrong (upstream original)	[mode] input_mode (4) doesn't even reach majestic — load_hisilicon never enters the MIPI case.
2	input_mode=0, others still wrong	majestic fail-fast: Input_mod (2) disagree; expected 5
3	+ Input_mod=5	majestic loads, SET_DEV_ATTR: input_mode=0 raw_data_type=3 lanes=[0,-1,-1,-1], /proc/driver/hi_mipi → LaneNum=1 RAW12 MIPI. Pipeline up but wrong RAW depth & lane count.
4	+ data_type=2 + lane_id="0|1|-1|..." (this PR)	SET_DEV_ATTR: input_mode=0 raw_data_type=2 lanes=[0,1,-1,-1], /proc/driver/hi_mipi → LaneNum=2 RAW10 MIPI (matches vendor diagnostic snapshot). ISP IRQs climb, VENC produces frames, RTSP delivers H.264 1080p — no LD_PRELOAD shim required.

Context

Companion to #2154 (cv200 load_hisilicon OV2735 case). Originally split out from closed #2151 (KC110 board package, re-filed as OpenIPC/builder#99). Replaces my earlier shim-package #2152 entirely once this lands and majestic master is released — see OpenIPC/majestic#278 for the full diagnostic trail.

🤖 Generated with Claude Code

[flyrouter]

Good afternoon
Thank you, we will review your proposals.

[moontwister]

Pushed a second commit adding a fifth field fix: [vi_dev] Mask_0 = 0x3FF0000 → 0xFFF00000 (matches cv300's ov2735 ini and the vendor firmware's VI DEV ATTR on the same hardware).

This turned out to be the root cause of the colour cast discussed in OpenIPC/majestic#281 — majestic applies the .ini faithfully, so the majestic binary was innocent (@widgetii's code audit was right). Same-scene A/B on the KC110 with majestic master+e9ff50d: with 0x3FF0000 the VI reads the wrong bit window (/proc/umap/vi ComMsk0=0x3FF0000, AE converges ~28x under at Line 86/2431, severe cast with highlight wrap); changing only this field on the same binary restores ComMsk0=0xFFF00000, correct AE, and a clean image.

With this PR's five fields plus the #279 pool fix already in master, OV2735 on cv200 runs correctly with stock majestic — no shim, no workarounds.