task-46: the front pair was already wired; the rear IMX363 was the gap

docs/tasks/46-camera-imx363.md

@@ -1,56 +1,76 @@
-# TASK 46 — Camera: everything is in the kernel except the DT
+# TASK 46 — Camera
 
-**Status:** open, raised 2026-07-28. **Size:** one session to first frame,
-plausibly. **Repo:** `Pixel3Arch` (DT only, to start).
+**Status:** rear sensor **written and building 2026-07-28**; the front pair was
+already wired. **Repo:** `Pixel3Arch` (kernel DT).
 
-## The gap is one file, and it is smaller than the roadmap says
+## What was actually missing
 
-`docs/ROADMAP.md` calls camera "research / pre-implementation." That is stale.
-Measured 2026-07-28 against our own tree:
+A first pass at this said blueline's DT declared no camera at all. Wrong — that
+grep only looked at `sdm845-google-blueline.dts`, and the camera lives in the
+`sdm845-google-common.dtsi` it includes. The real state:
 
 | Piece | State |
 |---|---|
-| CAMSS driver (Titan 170 ISP, CSIPHY/CSID/VFE) | present, `CONFIG_VIDEO_QCOM_CAMSS=m` |
-| `imx363.c` (main sensor) | present, `CONFIG_VIDEO_IMX363=m` |
-| `imx355.c` (wide) | present, `CONFIG_VIDEO_IMX355=m` |
-| `camss@acb3000` + camcc in `sdm845.dtsi` | present |
-| **camera nodes in `sdm845-google-blueline.dts`** | **none. Zero.** |
+| CAMSS driver (Titan 170 ISP) | present, `CONFIG_VIDEO_QCOM_CAMSS=m` |
+| `imx363.c` / `imx355.c` | present, both `=m` |
+| Front IMX355 ×2 (CCI1, CSIPHY1+2, ports 1/2) | **already declared**, with regulators, reset pins and shared MCLK2 |
+| **Rear IMX363 (CCI0, CSIPHY0, port 0)** | **was absent** — added `c7784b716` |
 
-Our kernel is the Mobian sdm845 series, which carries the camera/imx patches.
-Nobody ever wired blueline's board half.
+So the front half had been done and the rear was never finished. CSIPHY0 and
+CCI master 0 sat unused with the driver built and enabled.
 
-## The reference is in our own tree
+## What was added (kernel `c7784b716`, branch `mic-race-fix`)
 
-`sdm845-xiaomi-beryllium-common.dtsi` — Pocophone F1, **same IMX363** — wires
-the whole thing: `cci_i2c0`, `camera@10` with reset-gpio/mclk/vif/vana/vdig
-supplies, orientation, and a CSI endpoint with 4 data lanes at 636 MHz linking
-to `csiphy0_ep`. Copy its shape; replace the board-specific parts (GPIOs,
-regulators, lane mapping, orientation) from blueline's own downstream extracts,
-already decompiled at `~/pixel3-work/dtb_0.dts` and `dtbo_9.dts`.
+Read off the downstream DTBO's `cam-sensor@0` (`~/pixel3-work/dtbo_9.dts`),
+which is the same source the front pair's numbers came from — every front value
+in the tree matches its downstream node exactly, which is what made the rear
+ones trustworthy:
 
-This is the answer to "Dylan already solved it, but it might not be in our
-line" — it is in our line. The sdm845-mainline crowd (whose libssc we already
-patch, TASK-13) landed the sensor and CAMSS work upstream years ago, and we
-have been shipping the drivers without ever declaring the hardware.
+- MCLK0 gpio13, RESET0 gpio80, VANA0 gpio16 (a GPIO switch off BOB, same shape
+  as both front avdd regulators)
+- `vdig` → `vreg_s3a_1p35`, `vif` → `vreg_lvs1_1p8`, `vana` → new
+  `camera_rear_avdd`
+- 24 MHz MCLK and a 636 MHz link frequency — what the driver's 24 MHz table
+  expects; the front pair runs 19.2 MHz because the imx355 driver wants that
+- `camss` port@0 → `csiphy0`, 4 lanes
+
+Verified by compiling the DTB: 117,471 bytes, no new warnings, every phandle
+and lane value correct in the decompiled output.
+
+## The one guess in it
+
+**The slave address.** 0x10, which is what Xiaomi beryllium uses for the same
+IMX363. If it NACKs, try **0x1a** — the front pair on CCI1 sits at 0x10/0x1a,
+and the rear is alone on its bus so the default is likely. The vendor's own
+`com.qti.sensor.imx363.so` was extracted from `vendor.img` looking for the
+authoritative value; the address is not in it (10 KB wrapper) and the
+`sensormodule` bin holds only a name table. Not worth more archaeology — dmesg
+answers it in one boot.
 
 ## Acceptance
 
-- `media-ctl -p` enumerates a pipeline; `v4l2-ctl` streams a frame off the
-  rear IMX363.
-- Then the wide IMX355 on its own CCI bus.
-- A still lands on disk. Colour and tuning are a later fight — libcamera needs
-  a tuning file and there is none for this unit. **First frame is the goal;
-  good pictures are TASK-46's sequel, not its acceptance.**
+- `media-ctl -p` enumerates a pipeline and the rear sensor probes.
+- `v4l2-ctl` streams a frame off it.
+- A still lands on disk. **Colour and tuning are not acceptance** — libcamera
+  needs a tuning file and there is none for this unit.
 
-## Do not
+## The driver is a WIP snapshot, and that is the next lever
 
-- Do not start from the downstream camera stack. The mainline path is already
-  90% here; a vendor port would throw that away.
-- Do not scope tuning, HDR, or an app into this. Acceptance is a frame.
+`imx363.c` in our tree carries commented-out register writes, a commented-out
+19.2 MHz link-frequency table, and a literal `// NOT SURE HOW TO FIND THIS
+VALUE` against the 636 MHz entry. Two modes only (4032×3024, 1920×1080), no
+lens/actuator support — so no autofocus, though the downstream node has an
+actuator and an eeprom on the same bus.
+
+Casey has a Matrix conversation with Dylan Van Assche pointing at a newer
+commit with "all the possible fixes, focus and more". It is **not in mainline
+or linux-next** (both checked directly, 404), not in linux-media patchwork, and
+not on the branches of his GitLab fork or the sdm845-mainline group repo. Get
+the link from that conversation rather than re-searching — it is the difference
+between two modes and a working camera.
 
 ## Connects to
 
-TASK-12 (face auth needs the *front* camera — this is its bring-up
-prerequisite, and the reason to do the IMX355 half), TASK-40 (a camera stream
-is the sharpest inference-tiering case on the device), TASK-20 (the player is
-where captured media would land).
+TASK-12 (face auth wants the front sensors, already wired), TASK-40 (a camera
+stream is the sharpest inference-tiering case on the device), TASK-20 (where
+captured media would land).