gk7205v500: build the V4 sensor drivers from their one source - #230
Conversation
PR Summary by QodoBuild gk7205v500 V4 sensor drivers from shared sources
AI Description
Diagram
High-Level Assessment
Files changed (6)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR |
#229 added libraries/sensor/gk7205v500/imagedesign_mis2008, a copy of the hi3516ev200 MIS2008 driver with GK_* renamed to XMEDIA_*. That is the same driver twice: the XMedia SPC020 sensor interface is the V4 one rebranded, the same relationship HiSilicon's and Goke's already have and that include/hicompat.h bridges for the V4 drivers. So the copy goes, and CHIPARCH=gk7205v500 builds sensor/hi3516ev200 like the other V4 targets. sensor/compat/xmedia maps the drivers' Goke names onto the SDK: - xm_gk_compat.h: GK_*/gk_* types and constants onto XMEDIA_*. Force- included: the drivers often get the Goke types only through the SDK headers, and those include their own type.h relative to themselves, so shadowing type.h on the include path cannot reach them; - gk_api_{isp,ae,awb}.h, hicompat.h: GK_API_* onto XMEDIA_API_*, with the SDK's own prototypes. libraries/Makefile puts these and the SDK headers imported under kernel/ ahead of the V4 include/ the per-sensor Makefiles add; no driver or per-sensor Makefile changes. All 30 V4 sensor drivers now build for gk7205v500 (before: only MIS2008, as the copy), with no warning the gk7205v200 build of the same sources does not already have; gk7205v200 still builds all 30. On the GK7201V200 / MIS2008 camera the shared-source libsns_mis2008.so initialises the sensor and majestic streams 1080p25 H.264 with a correct image.
c1f5344 to
83a3f48
Compare
cmos_dgain_calc_table() used a hard-coded size of 255 for Dgain_table[], which has 240 entries, so its saturation check read Dgain_table[254] -- whatever the linker put after the table -- and returned that as the sensor digital gain. What that is depends on the build: an -O0 build happened to get a large value and behaved, the optimised firmware build of the same source gets 0. With a Dgain of 0 the AE's system gain is 0, so it holds exposure short and makes the picture up with ~4x ISP digital gain -- a noisy, yellow-cast image (seen on GK7201V200: Line 64, Again 1x, Dgain 0, IspDg 4176, ISO 0). The size now comes from the table. Same camera, same scene, firmware build: Line 2694, Again 8x, Dgain 1024, IspDg ~1x, ISO 843, clean image. The bug is in the shared V4 driver, so hi3516ev200/gk7205v200 builds had it too.
|
Added b1f1711: the shared V4 MIS2008 driver read |
#229 added libraries/sensor/gk7205v500/imagedesign_mis2008, a copy of the
hi3516ev200 MIS2008 driver with GK_* renamed to XMEDIA_*. That is the same
driver twice: the XMedia SPC020 sensor interface is the V4 one rebranded,
the same relationship HiSilicon's and Goke's already have and that
include/hicompat.h bridges for the V4 drivers.
So the copy goes, and CHIPARCH=gk7205v500 builds sensor/hi3516ev200 like
the other V4 targets. sensor/compat/xmedia maps the drivers' Goke names
onto the SDK:
included: the drivers often get the Goke types only through the SDK
headers, and those include their own type.h relative to themselves, so
shadowing type.h on the include path cannot reach them;
SDK's own prototypes.
libraries/Makefile puts these and the SDK headers imported under kernel/
ahead of the V4 include/ the per-sensor Makefiles add; no driver or
per-sensor Makefile changes.
All 30 V4 sensor drivers now build for gk7205v500 (before: only MIS2008,
as the copy), with no warning the gk7205v200 build of the same sources
does not already have; gk7205v200 still builds all 30. On the GK7201V200 /
MIS2008 camera the shared-source libsns_mis2008.so initialises the sensor
and majestic streams 1080p25 H.264 with a correct image.