Skip to content

media: re-lift guarded SP11 IMX681 C-PHY camera - #35

Merged
ooaklee merged 5 commits into
sp11/ubuntu-qcom-x1e-7.2.y-betafrom
sp11/beta-camera-imx681
Sep 2, 2026
Merged

media: re-lift guarded SP11 IMX681 C-PHY camera#35
ooaklee merged 5 commits into
sp11/ubuntu-qcom-x1e-7.2.y-betafrom
sp11/beta-camera-imx681

Conversation

@ooaklee

@ooaklee ooaklee commented Sep 2, 2026

Copy link
Copy Markdown
Owner

Summary

Combine the three ordered camera review topics (jglathe#85jglathe#87) into one beta integration PR: the standalone Sony IMX681 sensor, X1E80100 C-PHY receive routing, and the Denali OLED front-camera graph.

Containment

  • the sensor driver is device-local and selected by its own compatible
  • C-PHY mode is selected from endpoint bus type; existing D-PHY routes remain unchanged
  • the complete camera graph and power/reset wiring live only in the Denali OLED device tree
  • no non-SP11 camera graph is retargeted

Provenance and validation

All five focused commits retain Leon Silcott as author and link through the upstream-review histories in jglathe#85, jglathe#86, and jglathe#87.

  • beta integration validator: pass
  • strict checkpatch: 0 errors
  • git diff --check: pass
  • predecessor branches completed sensor/CAMSS object builds, binding checks, and Denali/non-SP11 DT builds

Probe, RAW10 capture, gain/exposure, libcamera, PipeWire, browser use, privacy LED, and suspend/resume require testing from the complete beta build.

Document the Sony IMX681 image sensor and its currently validated
3840x2640 RAW10 profile. The profile uses a single CSI-2 C-PHY trio at
2406 Msymbol/s and an external 19.2 MHz clock.

List turbinebmw as maintainer, following the original public camera
review series from which the sensor work was developed.

Link: https://github.com/turbineBMW/surface-pro-11-linux/blob/05e5335bc72476d44390336701cf03efa5fd0165/kernel/sp11-camera-review.patch
Link: d915d67
Signed-off-by: Leon Silcott <leon@boasi.io>
Add a standalone V4L2 driver for the IMX681 front-camera mode validated
on the Surface Pro 11. The driver programs 3840x2640 RAW10 at about
30 frames per second and supports frame length, 24-bit exposure, analog
gain, and digital gain controls.

Reject firmware descriptions other than the validated one-trio C-PHY
topology, 1.203 GHz V4L2 link frequency, and 19.2 MHz input clock before
powering the sensor. This keeps the observed register sequence scoped to
the hardware profile on which it was tested.

The register tables and initial driver were developed from turbinebmw's
public camera review series, then corrected and runtime-validated in the
SP11 integration branch.

Link: https://github.com/turbineBMW/surface-pro-11-linux/blob/05e5335bc72476d44390336701cf03efa5fd0165/kernel/sp11-camera-review.patch
Link: d915d67
Signed-off-by: Leon Silcott <leon@boasi.io>
Add an explicit MIPI C-PHY mode and teach the X1E80100 combo PHY to
accept only the validated one-trio, 2.406-Gsymbol/s receiver profile.
Program the bounded X1E register sequence, clear its interrupt state,
and apply its shutdown sequence while the PHY clocks remain available.

Keep the existing D-PHY configuration and shutdown paths unchanged.
The C-PHY clock vote, interrupt, programming, and shutdown paths are
selected only after the consumer requests C-PHY and the X1E capability
data accepts trio 0 and the exact symbol rate.

The register observations were independently transcribed from runtime
MMIO activity on the Surface Pro 11. This port builds on turbineBMW's
public CAMSS review series and geocausa's Windows/QTI parity analysis.

Link: https://github.com/turbineBMW/surface-pro-11-linux/blob/05e5335bc72476d44390336701cf03efa5fd0165/kernel/sp11-camera-review.patch
Link: d915d67
Signed-off-by: Leon Silcott <leon@boasi.io>
Accept C-PHY endpoints only for X1E80100 CAMSS and only for the
validated one-trio topology at the 1.203-GHz V4L2 link frequency.
Propagate the bus type through CSIPHY and CSID, select the X1E receive
clocks, and program the CSID C-PHY receiver fields.

Leave the existing D-PHY clock, lane, and receiver programming paths
unchanged. This re-lift excludes the source integration's VFE write-mode,
CSID crop and drop-engine changes, status logging, and sensor-specific
format handling. Non-SP11 D-PHY hardware testing remains required.

The receiver routing builds on turbineBMW's public CAMSS review series
and geocausa's Windows/QTI parity analysis.

Link: https://github.com/turbineBMW/surface-pro-11-linux/blob/05e5335bc72476d44390336701cf03efa5fd0165/kernel/sp11-camera-review.patch
Link: d915d67
Signed-off-by: Leon Silcott <leon@boasi.io>
Describe the OLED Surface Pro 11 front camera as a Sony IMX681 on CCI1
with its MCLK4, reset, analog and I/O supplies, and privacy indicator.
Route the one-trio C-PHY endpoint through CSIPHY2 at the validated
1.203 GHz V4L2 link frequency.

Keep the graph and all board wiring in the Denali OLED DTS. This commit
depends on the standalone IMX681 driver and the separately reviewed
X1E80100 C-PHY receiver support; it does not change shared drivers.

Link: https://github.com/turbineBMW/surface-pro-11-linux/blob/05e5335bc72476d44390336701cf03efa5fd0165/kernel/sp11-camera-review.patch
Link: d915d67
Signed-off-by: Leon Silcott <leon@boasi.io>
@ooaklee
ooaklee merged commit eca65c1 into sp11/ubuntu-qcom-x1e-7.2.y-beta Sep 2, 2026
1 check passed
@ooaklee

ooaklee commented Sep 2, 2026

Copy link
Copy Markdown
Owner Author

Post-merge parity correction

A final-tree comparison against the hardware-qualified
sp11/integration-7.2.x branch confirmed that the exclusions documented in
this PR removed active camera behavior, not only experimental scaffolding.

The withdrawn sp11beta1 aggregate omitted VFE680 MIPI RAW mode, CSID680
crop/drop and explicit keep-all programming, partial stream-start unwind, and
the active X1E/IMX681 stop diagnostics. Draft repair PR #40 restores those
behaviors with preserved author identity and strict per-commit review.

Do not use candidate 80ecee88b749d7324e1274c0a1cf6dfd752fddfa or package
7.2.2-sp11beta1 for hardware qualification. A new package will be produced
only after #40 completes software validation; #40 and the aggregate remain held
for hardware testing rather than automatic merge.

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.

1 participant