Skip to content

media: apple: isp: report frame gain and exposure on qualified hardware - #349

Draft
satchlj wants to merge 1 commit into
omacom:integration/aurorafrom
satchlj:port/isp-frame-gain
Draft

satchlj wants to merge 1 commit into
omacom:integration/aurorafrom
satchlj:port/isp-frame-gain

Conversation

@satchlj

@satchlj satchlj commented Nov 4, 2026

Copy link
Copy Markdown

Port Ryan Murray's merged Aurora change #689
(3c5441114af9).
Read bounded per-frame metadata and expose read-only, volatile V4L2_CID_GAIN
and V4L2_CID_EXPOSURE_ABSOLUTE on qualified match data. Gain uses the original
1/256 scale (256 is unity); exposure is presented in V4L2's 100 microsecond units.

This branch is independent of #344. Enable only T8140, which exists on this
base; do not import the newer T6040/P010 support. Also bound the section-table
entry read and test short headers and control admission.

J613/T8122 on 26.6.2 remains safely gated: its metadata layout/units have not
been established, so the driver exposes no gain control there. This therefore
does not yet enable J613 camera-denoise low-light tuning. A future enablement
needs returned-metadata qualification and an owner-approved dim/bright streaming
test. Combining with #344 requires preserving its validated ownership path.

Validation: arm64 module compile/MODPOST/link with Clang 18 and W=1,
KUnit object compilation, and 1,094 source-extracted host metadata checks pass
under ASan/UBSan; the six existing IPC-layout test bodies also pass in a host
shim. Kernel KUnit runtime is not run (module-only build scope). Authorship and cherry-pick provenance are
retained. No hardware, DMA/firmware ABI or image-quality qualification is claimed.

Camera-denoise can use qualified gain reporting: omacom/omarchy-pkgs#2084 and omacom/omarchy#17487. J613 gain stays gated off until the 26.6.2 metadata layout and units are verified. C13l-r2 streamed 1080p at about 30 fps without the preview opt-in and correctly exposed no gain control; this does not qualify the gain layout.

Userspace has no way to tell how hard the sensor is working. Gain is the
signal a camera pipeline needs to decide when the picture is noisy enough
to denoise, and the firmware already writes it into every frame's
metadata buffer, which the driver maps but never reads.

The metadata buffer opens with a table of section offsets. On H17
firmware the fourth section starts with the frame's exposure: the
integration time in microseconds, then the total sensor gain in 1/256
steps with 256 as unity. This was established on T6040 and T8140 by
watching auto exposure converge on a fixed scene, where the gain climbed
from 260 to its final value once the integration time hit the frame
period, and by stepping the frame rate, which capped the integration
time at the frame period.

Read the section when a metadata buffer comes back, through the table and
bounded by the buffer size, and report the last values as read-only,
volatile V4L2_CID_GAIN and V4L2_CID_EXPOSURE_ABSOLUTE controls. Only
hardware whose match data says its metadata carries the report gets the
controls.

(cherry picked from commit 3c54411)

Port to integration/aurora: only T8140 exists on this base; omit the
T6040/P010 dependencies. Keep T8122 metadata reporting disabled because
the 26.6.2 layout and units are unqualified. Bound the table-entry read
as well as its target and test short headers and control admission.

Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Signed-off-by: Satya Benson <satya@benson.earth>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants