Skip to content

media: qcom: add X1E80100 C-PHY camera receive support - #86

Closed
ooaklee wants to merge 729 commits into
jglathe:jg/ubuntu-qcom-x1e-7.2.yfrom
ooaklee:x/sp11-camera-cphy
Closed

ooaklee wants to merge 729 commits into
jglathe:jg/ubuntu-qcom-x1e-7.2.yfrom
ooaklee:x/sp11-camera-cphy

Conversation

@ooaklee

@ooaklee ooaklee commented Aug 31, 2026

Copy link
Copy Markdown

Summary

  • add an explicit MIPI C-PHY mode to the generic PHY API and the Qualcomm X1E80100 combo PHY
  • program the bounded X1E80100 one-trio receive, interrupt-clear, and shutdown sequences at 2.406 Gsymbol/s
  • propagate the endpoint bus type through Qualcomm CAMSS CSIPHY and CSID
  • route the validated one-trio C-PHY path through the X1E80100 CAMSS clocks and CSID receiver fields

Dependency and status

This PR is intended to target jg/ubuntu-qcom-x1e-7.2.y directly. Review it after #82, #83, and the preceding IMX681 sensor topic:

The head is stacked on x/sp11-camera-imx681, so its GitHub diff is cumulative until the sensor topic is merged into the release branch. The C-PHY-specific portion is the two commits after ddc5bc6c2804. It does not merge the broad -sp11 staging branch or replay the correction already merged through #81.

This PR is a draft. The Denali OLED camera graph follows separately, and both the exact cumulative SP11 stack and an existing non-SP11 X1E D-PHY camera need hardware testing before this shared-driver topic is ready.

Containment

  • C-PHY endpoint acceptance is limited to the qcom,x1e80100-camss compatible
  • the Qualcomm combo-PHY sequence is selected only for the X1E80100 capability data, PHY_MODE_MIPI_CPHY, trio 0, one data lane/trio, and the exact 2.406 Gsymbol/s rate
  • CAMSS accepts only the matching 1.203 GHz V4L2 link frequency for this C-PHY path
  • the existing D-PHY endpoint parsing, clock selection, lane programming, receiver programming, and shutdown paths remain the default for existing devices
  • the generic PHY_MODE_MIPI_CPHY enum addition is inert until a consumer explicitly requests that mode
  • this topic adds no board device tree and no sensor driver beyond the cumulative prerequisite
  • the staging source's VFE write-mode, CSID crop/drop-engine, status-logging, CCS, and sensor-format experiments are excluded

Provenance

The two C-PHY commits are authored by Leon Silcott, carry the authorized Signed-off-by: Leon Silcott <leon@boasi.io>, and preserve source links to the final integration state in d915d679423e.

The receiver work builds on @turbineBMW's public camera review patch at immutable revision 05e5335bc724 and credits @geocausa's Windows/QTI parity analysis in the commit messages. These are source and analysis credits; no contributor Signed-off-by or Co-authored-by trailer has been invented for the rewritten commits.

Validation

  • git diff --check ddc5bc6c2804..HEAD for the incremental C-PHY topic
  • strict checkpatch: no errors or checks; only the generic new-file/MAINTAINERS prompt for the X1E80100 register-table header, which is covered by the existing QUALCOMM MIPI CSI2 PHY DRIVER entry
  • ARM64 ubuntu_x1e_defconfig W=1 builds of the two Qualcomm MIPI CSI-2 PHY objects and the four affected CAMSS/CSIPHY/CSID objects
  • source audit confirms C-PHY acceptance is limited to X1E80100 and the validated topology/rate
  • source audit confirms existing D-PHY endpoints continue through the pre-existing configuration paths
  • the cumulative series builds without the excluded VFE, crop/drop, CCS, logging, or sensor-format experiments

Hardware checks still required

  • boot the exact cumulative camera stack on an X1E Surface Pro 11 OLED and verify CSIPHY2/CSID0 C-PHY stream setup
  • verify repeated and continuous raw capture without CSIPHY, CSID ECC/CRC, or VFE transport errors
  • verify repeated stream start/stop and suspend/resume exercise the C-PHY shutdown and reconfiguration paths
  • run a camera stream smoke test on a non-SP11 X1E device that uses the existing D-PHY path
  • confirm that non-X1E CAMSS devices continue rejecting C-PHY endpoints and retain their existing D-PHY behavior

harrisonvanderbyl and others added 30 commits August 30, 2026 10:33
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
This is required to distinguish these models easier on the boot loader level
for dtb selection.

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
remove the delete-node statement, no longer needed

refers-to: d68d93c

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
fix typo

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Follow the example of other DP controllers and also eDP controller on
SC7280 and move mdss_dp3_out endpoint declaration to the SoC
DTSI. This slightly reduces the boilerplate in the platform DT files and
also reduces the difference between DP and eDP controllers.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
… lanes on type-c

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:

 [drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 [drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
 ...

Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.

Fixes: 6516961 ("arm64: dts: qcom: Add support for X1-based Asus Zenbook A14")
Tested-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>    # FHD OLED
Reviewed-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
…for eDP HPD

At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:

 [drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
 [drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
 [drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
 ...

Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.

Fixes: 7d1cbe2 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6")
Tested-by: Christopher Obbard <christopher.obbard@linaro.org>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14s OLED
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
amend the following files for the new mdss_dp3_out definition:

arch/arm64/boot/dts/qcom/x1-acer-swift-14.dtsi
arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi
arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
arch/arm64/boot/dts/qcom/x1p42100-lenovo-ideapad-5-2in1.dts
arch/arm64/boot/dts/qcom/x1p42100-lenovo-ideapad-slim5x.dts

refers-to: 24f44be

also add the edp0_hpd_default pinctrl on dp3.

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
slim5x: i2c0: correct pinctrl-0
5-2in1: add commented- out dedicated driver atna40ct01

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
… 3 15Q8X10

add x126100 chip designation and compatible
add initial device tree

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
…ncept ISO

needs to boot and have efivars - use Thinkpad T14s as compatible
also added Vivobook 15 x1p42100
also added HP Omnibook X 14-fe1
also added Thinkbook 16
also added Acer Swift Go 14
also added Surface Pro 12"

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
fix typos in tlmm definition

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
since calculating tlmmgpio was unsuccessfful, use the common known one: tlmm 3

remove all possible touchpads except for the actual detected one, @38
disable all sophisticated pinctrl, only on the i2c devices

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
shared with keyboard, f yeah

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
since its apparently shared with the keyboard, disable it for now
there needs to be a mux driver which does the handling for it

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
required for 6.17

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
add dependency for python3-libfdt
add stubble-script hwids/finddtbs.py as debian/scripts/misc/find-dtbs.py

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
… T14s

T14s is powerful, but the fan doesn't cool it enough for full load.
Tone it down to the experimentally determined limits
QMP Combo PHYs default to USB3DP lane routing, which can break static setups like
DP-to-HDMI bridges by misallocating lanes to USB3.
Revive the optional "qcom,combo-initial-mode" DT property [1] to explicitly
set the initial mode ("usb3dp", "dp", "usb3"). In static configs (no mode-switch
or orientation-switch props), honor it and skip lane inference to avoid overrides.
This simplifies HDMI enablement on undocumented Snapdragon X laptops while
preserving dynamic Type-C behavior.

[1]: https://lore.kernel.org/r/20250821-topic-x1e80100-hdmi-v1-2-f14ad9430e88@linaro.org

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Microsoft Surface Pro 12 is using this (well, my definition of it), changed to
Stephan Gerhold's one.

Remove the edp0_hpd_default reference from Thinkbook 16 as TLMM 119 is used by the HDMI bridge
as enable pin.

Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-1-6310176239a6@linaro.org

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
jglathe and others added 19 commits August 30, 2026 10:33
- new pcie node structure
- add gpi dma nodes
- add iris node, remove venus
- add mode-switch to qmpphy nodes (should be in sc8280xp.dtsi, but it is what it is)
- correct camera gpio definition

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
- new pcie node structure
- add gpi dma nodes
- add iris node, remove venus
- add mode-switch to qmpphy nodes (should be in sc8280xp.dtsi, but it is what it is)
- bluetooth: correct vddrfa1p7-supply description

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
- specifically iris vs. venus
- keep the arm-smmu-v3 improvements we have

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Commit a53b4f9 ("usb: typec: mux: avoid duplicated orientation
switches") started using the orientation switch result array as state for
duplicate detection, but left the array uninitialized.

The first match therefore scans indeterminate stack contents before any
result has been stored. A valid orientation switch may be incorrectly
discarded as a duplicate, causing fwnode_typec_switch_get() to return no
switch.

Zero-initialize the array before collecting matches.

Fixes: a53b4f9 ("usb: typec: mux: avoid duplicated orientation switches")
Signed-off-by: Haobo Cheng <i@4t.pw>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
…es, enable DisplayPort audio

The Windows Dev Kit 2023 has no built-in speakers, microphones or
headphone jack. Likewise the device with the same mainboard, Surface
Pro 9 5G [1]. The previous WCD938x / WSA / VA sound card definition
was therefore non-functional.

Replace the unused codec nodes, SoundWire controllers, LPASS macros
and related pinctrl with DisplayPort DAI links (DP0/DP1/DP2) so that
audio is available over the DP connectors. Add the required
sound-name-prefix properties and update the card model name to the
conventional SC8280XP-MICROSOFT-BLACKROCK form.

[1]: https://support.microsoft.com/en-us/surface/models/surface-pro-9-features-and-specs

Fixes: 16a7fed ("arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023")
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Allow up to 4 lanes for the DisplayPort links on the USB-C ports and
the mini-DP connector. Add the standard link-frequencies and move
data-lanes to the out endpoints where required by the current bindings.

Also enable mode-switch on the QMP combo PHYs so that altmode events
can reach them.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Add the dp0/dp1 DAI links for sound via displayport.

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Some devices use combo PHYs (i.e. USB3 + DisplayPort), which also
handle the lane muxing. These PHYs are referenced twice from
the USB-C connector (USB super-speed lines and SBU/AUX lines)
resulting in the mux being configured twice. Avoid this by
dropping duplicates.

This is a re-application of b145c3f ("usb: typec: mux: avoid
duplicated mux switches"), with fix derived from usb: typec: mux:
Fix typec_switch_match() .

Fixes: f576c75 ("Revert "usb: typec: mux: avoid duplicated mux switches"")
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Co-developed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
The fwnode_typec_switch_get() sporadically returns NULL instead of an
-EPROBE_DEFER for orientation-switch described in DT. This makes it
impossible to discern whether the DT does describe an orientation-switch
which did not probe yet, or whether the DT does not describe the switch.
This happens with gpio-sbu-mux connected to an I2C GPIO expander.

The class_find_device() on typec_switch_match() may return NULL in case
the mux did not probe just yet early on boot. The sw_devs[] array can be
empty on boot as well. If these two conditions occur, then the conditional
if (to_typec_switch_dev(dev) == sw_devs[i]) evaluates to true and the match
function returns NULL, which propagates to fwnode_typec_switch_get() which
makes it look as if the orientation-switch was not described in DT.

This is incorrect, because the mux driver will probe a bit later on, but
at that point, the caller of fwnode_typec_switch_get() already got the
NULL return value. The NULL return value also does not trigger IS_ERR(),
therefore the caller driver interprets this as if the orientation-switch
is not described in DT, and does not return -EPROBE_DEFER to try again,
even if it should.

Fix this by checking the class_find_device() return value, and return
-EPROBE_DEFER if it is NULL right away. If the return value is not NULL,
perform the deduplication test, and if that test passes, consider the
return value to be already non-NULL.

Fixes: a53b4f9 ("usb: typec: mux: avoid duplicated orientation switches")
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
base purwa and hamoa variants on a common dtsi

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
…patible strings

required to boot via stubble to identify the dtb

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Rewrite of the OmniBook 5 devicetree that is independent of the X14
dtsi.

Additional changes:
- Corrected the display-adjacent type-c port configuration by replacing
  the PS8830 redriver with a TB16-derived usb_1_ss0 setup
- Adjusted eUSB2 repeaters following the TB16 configuration
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>
ooaklee added a commit to ooaklee/linux_ms_dev_kit-sp11 that referenced this pull request Sep 1, 2026
Integrate jglathe#86 for combined SP11 testing.
@jglathe
jglathe force-pushed the jg/ubuntu-qcom-x1e-7.2.y branch 2 times, most recently from 4943ee7 to 6407d62 Compare September 9, 2026 20:39
@jglathe
jglathe force-pushed the jg/ubuntu-qcom-x1e-7.2.y branch 3 times, most recently from 68e1550 to e57ec29 Compare September 18, 2026 05:08
@ooaklee

ooaklee commented Oct 4, 2026

Copy link
Copy Markdown
Author

Withdrawing this older 7.2.2-era submission version without merging while we continue qualification of the repaired 7.2.5 source on the fork. Current source/dependency review is tracked in ooaklee/linux_ms_dev_kit-sp11#51, ooaklee/linux_ms_dev_kit-sp11#56 and the combined candidate ooaklee/linux_ms_dev_kit-sp11#68. These are review vehicles, not an upstream-ready replacement or proof of equivalence to this old PR head.

The current combined source is 8ba2b75713feb5c72bbc11dd8cce4048e23cdeea, ABI 7.2.5-jg-0sp11v8-qcom-x1e; see the experimental v8 release. Ordinary-use results on one X1E/OLED unit are recorded, but the release remains experimental and the detailed hardware, lifecycle, deviation, CI and provenance gates in ooaklee/linux_ms_dev_kit-sp11#68 remain open.

This PR's branch and exact head f8ef631fcdd4, authored history, discussion and test evidence are retained unchanged. Closing is administrative supersession, not a merge, an acceptance decision, or a claim that the old and current trees are identical. Beta and the repository default are unchanged.

Sensor, C-PHY and Denali graph prerequisites are inherited in ooaklee/linux_ms_dev_kit-sp11#51. ooaklee/linux_ms_dev_kit-sp11#56 is additional CAMSS parity/containment work, not a standalone replacement for the sensor or board graph. X1P/LCD camera qualification is not inferred.

Fresh focused upstream submissions will preserve the contributing authors, source links and dependencies after exact combined acceptance and the appropriate shared-driver checks. Fork-only integration scripts/workflows and repository policy will be excluded. PR #79 remains open as the maintainer's coordination/provenance thread.

@ooaklee ooaklee closed this Oct 4, 2026
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.