페어폰 6 와이드 카메라, 리눅스 실험적 지원

Background The Fairphone 6 is an interesting target for mainline Linux and postmarketOS for a few reasons: It has relatively modern hardware compared with most other supported postmarketOS devices. Fairphone invests in mainline Linux support, with Luca Weiss driving much of the development. Those efforts have already provided promising initial support for the hardware. Fairphone deliberately allows alternative operating systems. Fairphone aims to support its devices for a long time, so the phone could provide a stable base for future work. There are still two main blockers to making the device generally usable: onboard audio and camera support . I am working on a project that needs QR scanning, so I used that as an opportunity to see whether I could get at least one camera working. Disclaimer: I heavily relied on LLM assistance to make this work. Fairphone 6 cameras The Fairphone 6 has three cameras: Rear: Sony IMX896 Front: Samsung S5KKD1 Wide: OmniVision OV13B10 The Sony and Samsung sensors have no mainline Linux drivers, but the OmniVision OV13B10 has a mainline driver. The ultra-wide camera is sufficient for QR scanning. A phone camera is not a single device. On Qualcomm SoCs, the capture path is a chain: image sensor → CSI-2 D-PHY → CSIPHY → CSID → ISP (VFE/TFE) → memory (I2C) (MIPI lanes) (decode) (demux) (write engine) (DMA) There are also several supporting components, including a camera clock controller (camcc), the CCI (Qualcomm's dedicated camera I2C controller), power rails, and a VCM (voice-coil motor) for autofocus. The downstream vendor Android kernel drives all of this with Qualcomm's substantial, proprietary CAMX/cam-kernel stack. On mainline, the equivalent is the much smaller qcom-camss driver, with libcamera providing userspace integration and image processing. To get the OmniVision camera working, I had to teach qcom-camss about the SoC's specific blocks, describe the hardware in the device tree, enable the sensor driver, and configure libcamera to turn raw Bayer frames into images that applications could use. Initial exploration Before starting the implementation, I wanted to find out how much of the work was new and how much could be ported from hardware that mainline already supported. That would show whether the project was feasible without manufacturer support. The initial research was encouraging: The FP6's SoC is Qualcomm milos (SM7635). The downstream board is codenamed volcano, and postmarketOS already boots it with a mainline-based kernel fork. The camera hardware blocks are TFE665 (a thin-front-end ISP), CSID665 , and CSIPHY v2.2.1 . The camcc clock controller and CCI are already present in the kernel fork. The three cameras are: Main: Sony IMX896, with no mainline driver. Ultra-wide: OmniVision OV13B10 , with a mainline driver that supports ACPI/x86 only. Front: Samsung S5KKD1, with no mainline driver. That made the target obvious: the OV13B10 ultra-wide . It is a 13 MP sensor with an existing mainline driver, and its wide field of view is suitable for QR scanning. When I compared the downstream register headers ( cam_tfe665.h , cam_csiphy_2_2_1_hwreg.h , and cam_tfe_bus.c ) with mainline qcom-camss , I found that TFE665 is essentially the same IP as TFE530, which mainline already supports. The register layouts are identical. Only the base offsets of the internal blocks differ, because the write bus lives at a different address. Similarly, the CSID665 RDI registers match the supported CSID, and CSIPHY v2.2.1 belongs to the same three-phase PHY family. This meant that I could port existing drivers instead of writing everything from scratch . Step 1: Port the capture subsystem into the kernel qcom-camss was not yet available on milos, so I had to connect the existing pieces. TFE665 ISP driver I added a new camss-vfe-665.c , modelled directly on the mainline TFE530 driver ( camss-vfe-340.c ). Because the register contents are identical, the driver logic is the same. The main difference is that milos places the ISP control block and write-bus block at different offsets. The bus register base moved from 0xa00 to 0x1800 , and encapsulating that offset shift accounted for most of the work. CSID665 and CSIPHY v2.2.1 CSID665 reused the existing gen-2 CSID operations because its RDI register offsets were identical. CSIPHY v2.2.1 needed a new lane-configuration table and D-PHY tuning values for this revision. I transcribed the lane register sequence and the approximately 1.1 Gbps/lane ("500 Msps") data-rate and AFE settings from the downstream cam_csiphy_2_2_1_hwreg.h . The PHY's register window was at offset 0x1000 . Resources, compatible, and device tree In camss.c , I described milos's capture complex: four CSIPHYs, three CSIDs, three TFEs, their clocks, interconnects, and power domains. I also registered a new qcom,milos-camss compatible. In the device tree, I added the camss@ac13000 node with its registers, IRQs, clocks, interconnects, IOMMUs, GDSC, and CSI input ports, along with the MCLK and reset pinctrl states. Missing register-bus clock I ran into a problem at this point. The driver bound, but reading the TFE hardware-version register returned 0x0 , and reset timed out as if the block were not powered. The fix was a clock that was not obviously an ISP clock: CAM_CC_SOC_AHB_CLK . It gated the AHB register bus used by the whole camera complex, including the CCI. Without it, register accesses silently returned zero. I added that clock and the CAMNOC AXI clocks, then set the CAMNOC data-path clock rate. The ISP came alive with hw_version = 0x30000000 . This suggests that, on Qualcomm hardware, a block that reads as zero may be missing a clock or power domain on its access path. Step 2: Bring up the OV13B10 sensor The mainline ov13b10 driver exists, but it is written for x86/ACPI laptops and only matches through ACPI. I made changes in two places. Making the driver usable on ARM and device tree I added an OpenFirmware match table ( ovti,ov13b10 ) so the driver could probe from the device tree. I described the sensor in milos-fairphone-fp6.dts . It lives on the CCI I2C bus at address 0x36 , needs MCLK1 at 19.2 MHz , a reset GPIO, and power rails. For this experimental bring-up, I simply forced the regulators on instead of fully sequencing them. 2 small details Lane numbering. The downstream device tree used data-lanes = <1 2 3 4> , while mainline's convention is zero-indexed : <0 1 2 3> . With the wrong numbering, CSIPHY programmed a lane mask with lane 0 missing, and the PHY never locked. Which CSIPHY? The FP6 wiring routed the ultra-wide camera to CSIPHY1 . Getting this from the downstream device tree instead of guessing saved a lot of trial and error. At this point, the sensor probed successfully, the chip ID was read correctly over I2C, CSIPHY reported lane activity, and the ISP produced frames that were completely black . Step 3: The all-zero frames mystery This was the main bug. Frames arrived at the right rate and size, and buf_done fired, but every pixel was zero. That was also true when I enabled the sensor's internal colour-bar test pattern, which was generated inside the sensor and should have appeared regardless of the scene. The data path delivered frame timing, but not pixel data. The kernel log provided a clue: VFE0: Bad config violation . The ISP's write engine reported a consumer/config violation once per frame because the write master's configuration did not match the incoming data. When I dug into the downstream cam_tfe_bus.c , the difference became clear. The RDI write-master's packer format depends on the ISP bus width: TFE530 (qcm2290, the target of the mainline driver) has a 64-bit RDI bus, so it uses packer 0xa . TFE665 (milos) has a 128-bit RDI bus, so it needs packer 0x0 . The mainline driver hard-coded the 64-bit value. On milos, that was wrong, and the write engine refused to write the pixels. Changing the register value from PLAIN64 (0xa) to 0x0 turned the all-zero frames into real images : the