Skip to content

PENDING: change FROMLIST changes to PENDING tag - #1692

Draft
Wenmeng Liu (wenmliu) wants to merge 53 commits into
qualcomm-linux:tech/mm/camssfrom
wenmliu:tech/mm/camss
Draft

PENDING: change FROMLIST changes to PENDING tag#1692
Wenmeng Liu (wenmliu) wants to merge 53 commits into
qualcomm-linux:tech/mm/camssfrom
wenmliu:tech/mm/camss

Conversation

@wenmliu

Copy link
Copy Markdown
Contributor

No description provided.

Bryan O'Donoghue (0xB0D) and others added 30 commits June 30, 2026 10:38
Add lane_positions to the DPHY configuration struct. This data-field
represents the physical positions of the data-lanes indexed by lane number.

Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-1-c6df5599284a@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Pass an array of data-lane polarities from controller to PHY. A true value
means the lane polarity is inverted.

Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-2-c6df5599284a@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
We need to identify which lane is the clock-lane as many different PHYs
allow for a range of lanes, potentially any of the lanes to be the clock
input lane on a PHY.

Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-3-c6df5599284a@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Specify the polarity of the clock lane in DPHY mode. When true this bool
means the polarity is inverted.

Link: https://lore.kernel.org/all/20260325-dphy-params-extension-v1-4-c6df5599284a@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
PHY devices.

The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
capture those modes as:

- PHY_QCOM_CSI2_MODE_DPHY
- PHY_QCOM_CSI2_MODE_CPHY
- PHY_QCOM_CSI2_MODE_SPLIT_DPHY

The CSIPHY devices have their own pinouts on the SoC as well as their own
individual voltage rails.

The need to model voltage rails on a per-PHY basis leads us to define
CSIPHY devices as individual nodes.

Two nice outcomes in terms of schema and DT arise from this change.

1. The ability to define on a per-PHY basis voltage rails.
2. The ability to require those voltage.

We have had a complete bodge upstream for this where a single set of
voltage rail for all CSIPHYs has been buried inside of CAMSS.

Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
CAMSS parlance, the CSIPHY devices should be individually modelled.

Link: https://lore.kernel.org/all/20260326-x1e-csi2-phy-v5-1-0c0fc7f5c01b@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of
existing CAMSS CSI PHY init sequences are imported in order to save time
and effort in later patches.

The following devices are supported in this drop:
"qcom,x1e80100-csi2-phy"

In-line with other PHY drivers the process node is included in the name.
Data-lane and clock lane positioning and polarity selection via newly
amended struct phy_configure_opts_mipi_dphy{} is supported.

The Qualcomm 3PH class of PHYs can do both DPHY and CPHY mode. For now only
DPHY is supported.

In porting some of the logic over from camss-csiphy*.c to here its also
possible to rationalise some of the code.

In particular use of regulator_bulk and clk_bulk as well as dropping the
seemingly useless and unused interrupt handler.

The PHY sequences and a lot of the logic that goes with them are well
proven in CAMSS and mature so the main thing to watch out for here is how
to get the right sequencing of regulators, clocks and register-writes.

The register init sequence table is imported verbatim from the existing
CAMSS csiphy driver. A follow-up series will rework the table to extract
the repetitive per-lane pattern into a loop.

Link: https://lore.kernel.org/all/20260326-x1e-csi2-phy-v5-2-0c0fc7f5c01b@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…andle definitions

Add optional PHY handle definitions. This will allow for supporting both
legacy PHY definitions as well as supporting the optional new handle based
approach.

Drop the legacy high-level 0p8 and 1p2 supplies as required, each PHY has
its own individual rails. The old binding is still valid but with
individual nodes we define the rails in the CSIPHY sub-nodes.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-1-5b93415be6dd@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…mbo-mode endpoints

Qualcomm CSI2 PHYs support a mode where two sensors may be attached to the
one CSIPHY.

When we have one endpoint we may have
- DPHY 1, 2 or 4 data lanes + 1 clock lane
- CPHY 3 wire data lane

When we have two endpoints this indicates the special fixed combo-mode.
- DPHY endpoint0 => 2+1 and endpoint1 => 1+1 data-lane/clock-lane combination.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-2-5b93415be6dd@linaro.org/
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
…ries

The original iommus list included entries for ICP and BPS/IPE S1
contexts. Only the five S1 HLOS stream IDs are required by the CAMSS
ISP hardware: IFE/IFE_LITE read and write, SFE read and write, and
CDM IFE. The remaining entries serve other hardware blocks which will
be described in their own nodes as support is added.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-3-5b93415be6dd@linaro.org/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Use devm_of_platform_populate() to populate subs in the tree.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-4-5b93415be6dd@linaro.org/
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
…tructures

Flag which SoCs have legacy - builtin PHY code. This will be useful in
subsequent patches to inform PHY bringup logic if legacy bindings are
available.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-5-5b93415be6dd@linaro.org/
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Add the ability to use a PHY pointer which interacts with the standard PHY
API.

In the first instance the code will try to use the new PHY interface. If no
PHYs are present in the DT then the legacy method will be attempted.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-6-5b93415be6dd@linaro.org/
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
x1e is the first CAMSS SoC to use the new PHY interface. Drop the redundant
legacy CSIPHY descriptions.

Link: https://lore.kernel.org/all/20260326-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v11-7-5b93415be6dd@linaro.org/
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm Kaanapali
platform.

The Kaanapali platform provides:
- 6 x CSIPHY (CSI Physical Layer)
- 3 x TPG (Test Pattern Generator)
- 3 x CSID (CSI Decoder)
- 2 x CSID Lite
- 3 x VFE (Video Front End), 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite

Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-1-2541d8e55651@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add support for Kaanapali in the camss driver. Add high level resource
information along with the bus bandwidth votes. Module level detailed
resource information will be enumerated in the following patches of the
series.

Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-2-2541d8e55651@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
…e CSIPHY

Add more detailed resource information for CSIPHY devices in the camss
driver along with the support for v2.4.0 in the 2 phase CSIPHY driver
that is responsible for the PHY lane register configuration, module
reset and interrupt handling.

Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-3-2541d8e55651@oss.qualcomm.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add more detailed resource information for CSID devices along with the
driver for CSID gen4 that is responsible for CSID register configuration,
module reset and IRQ handling for BUF_DONE events. And aggregate a common
definition 'CSI2_RX_CFG0_PHY_SEL_BASE_IDX' into csid header file.

In this CSID version, RUP and AUP update values are split into two
registers along with a SET register. Accordingly, enhance the CSID
interface to accommodate both the legacy combined reg_update and the
split RUP and AUP updates.

Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-4-2541d8e55651@oss.qualcomm.com/
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add Video Front End (VFE) version gen4 as found on the Kaanapali SoC.

The FULL front end modules in Kaanapali camera subsystem are called TFEs
(Thin Front End), however, retaining the name VFE at places to maintain
consistency and avoid unnecessary code changes.

This change limits the VFE output lines to 3 for now as constrained by
the CAMSS driver framework.

Kaanapali architecture requires for the REG_UPDATE and AUP_UPDATE to be
issued after all of the CSID configuration has been done. Additionally,
the number of AUP_UPDATEs should match the number of buffers enqueued to
the write master while it's being enabled.

Although the real time data from TFE goes through the RT_CAMNOC, we are
required to enable both the camnoc_rt_axi and camnoc_nrt_axi clocks for
the PDX_NOC, that follows both the RT and NRT NOCs in this architecture,
to ensure that both of the latter are idle after reset.

Link: https://lore.kernel.org/all/20260508-kaanapali-camss-v13-5-2541d8e55651@oss.qualcomm.com/
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Add bindings for the Camera Subsystem for X1P42100.

The X1P42100 platform provides:
- 2 x CSIPHY
- 3 x TPG
- 3 x CSID
- 2 x CSID Lite
- 1 x IFE
- 2 x IFE Lite

Link: https://lore.kernel.org/all/20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com/
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
The Purwa camera subsystem is a cut-down variant of the Hamoa CAMSS.
Compared to Hamoa, Purwa provides only two CSIPHY instances and does
not include the VFE1.

Link: https://lore.kernel.org/all/20260410-purwa_camss-v1-2-eedcf6d9d8ee@oss.qualcomm.com/
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Add bindings for Camera Subsystem (CAMSS) on the Qualcomm SM8750 platform.

The SM8750 platform provides:
- 6 x CSIPHY (CSI Physical Layer)
- 3 x TPG (Test Pattern Generator)
- 3 x CSID (CSI Decoder)
- 2 x CSID Lite
- 3 x VFE (Video Front End), 5 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE Lite

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-1-fc6861a65c67@oss.qualcomm.com/
Add SM8750 platform support to the CAMSS driver with ICC bandwidth
resources and device tree match entry.

Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-2-fc6861a65c67@oss.qualcomm.com/
…e CSIPHY

Add more detailed resource information for CSIPHY devices in the camss
driver along with the support for v2.3.0 in the 2 phase CSIPHY driver
that is responsible for the PHY lane register configuration, module
reset and interrupt handling.

Additionally, generalize the struct name for the lane configuration that
had been added for Kaanapali and use it for SM8750 as well as they share
the settings.

Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-3-fc6861a65c67@oss.qualcomm.com/
Add more detailed resource information for CSID devices along with the
driver for CSID 980 that is responsible for CSID register
configuration, module reset and IRQ handling for BUF_DONE events.

In SM8750, RUP and AUP updates for the CSID Full modules are split into
two registers along with a SET register. However, CSID Lite modules
still use a single register to update RUP and AUP without the additional
SET register. Handled such differences in the driver.

Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-4-fc6861a65c67@oss.qualcomm.com/
Add support for Video Front End (VFE) that is on the SM8750 SoCs. VFE
gen4 has support for VFE 980. This change limits SM8750 VFE output lines
to 3 for now as constrained by the CAMSS driver framework.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Co-developed-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Atiya Kailany <atiya.kailany@oss.qualcomm.com>
Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260508-add-support-for-camss-on-sm8750-v3-5-fc6861a65c67@oss.qualcomm.com/
Add device tree bindings for the Camera Subsystem (CAMSS) on the
Qualcomm Glymur platform.

The Glymur platform provides:
- 3 x CSIPHY (CSI Physical Layer)
- 3 x CSID (CSI Decoder), 2 x CSID Lite
- 3 x TPG (Test Pattern Generator)
- 2 x VFE (Video Front End), 2 x VFE Lite

Signed-off-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-1-bee535396d22@oss.qualcomm.com/
Add CAMSS_GLYMUR enum, Glymur compatible and Glymur camss driver
private data, the private data just include some basic information
for now, later changes will enumerate with csiphy, tpg, csid and
vfe resources.

Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com>
Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-3-bee535396d22@oss.qualcomm.com/
Glymur uses the same CSIPHY hardware version as x1e80100. The only
difference between the two platforms is the number of CSIPHY instances.
x1e80100 has four, while Glymur has three.

Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com>
Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-4-bee535396d22@oss.qualcomm.com/
Extend vfe_src_pad_code() and vfe_bpl_align() for Glymur.

Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com>
Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-5-bee535396d22@oss.qualcomm.com/
Enumerate csiphy, csid and vfe resources for Glymur.

Signed-off-by: Prashant Shrotriya <pshrotri@qti.qualcomm.com>
Link: https://lore.kernel.org/all/20260529-glymur_camss-v1-6-bee535396d22@oss.qualcomm.com/
David Heidelberg (okias) and others added 19 commits August 6, 2026 14:39
…g C-PHY lanes

So far, only D-PHY mode was supported, which uses even bits when enabling
or masking lanes. For C-PHY configuration, the hardware instead requires
using the odd bits.

Since there can be unrecognized configuration allow returning failure.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-3-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Inherit C-PHY information from CSIPHY, so we can configure CSID
properly.

CSI2_RX_CFG0_PHY_TYPE_SEL must be set to 1, when C-PHY mode is used.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-4-83da8a8e4e44@ixit.cz
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…on is available

The lanes must not be initialized before the driver has access to
the lane configuration, as it depends on whether D-PHY or C-PHY mode
is in use. Move the lane initialization to csiphy_lanes_enable which is
called when the configuration structures are available.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-5-83da8a8e4e44@ixit.cz
Co-developed-by: Petr Hodina <phodina@protonmail.com>
Signed-off-by: Petr Hodina <phodina@protonmail.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…PHY init

Add a PHY configuration sequence for the sdm845 which uses a Qualcomm
Gen 2 version 1.1 CSI-2 PHY.

The PHY can be configured as two phase or three phase in C-PHY or D-PHY
mode. This configuration supports three-phase C-PHY mode.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-6-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
… C-PHY init

These values should improve C-PHY behaviour. Should match most recent
Qualcomm code.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-7-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
… frequency

Ensure that the link frequency divider correctly accounts for C-PHY
operation. The divider differs between D-PHY and C-PHY, as described
in the MIPI CSI-2 specification.

For more details, see:
https://docs.kernel.org/driver-api/media/tx-rx.html#pixel-rate

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-8-83da8a8e4e44@ixit.cz
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://docs.kernel.org/driver-api/media/tx-rx.html#pixel-rate
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
After all the changes done we can now safely enable C-PHY for a SoC
where it's available.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-9-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Program the CSIPHY common-control registers during lane enable so
SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
both C-PHY and D-PHY. Keep the existing reset-release value for the
other CAMSS variants.

Link: https://lore.kernel.org/r/20260717231331.1229693-2-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Program the gen3 CSID CSI2 RX PHY type field from the configured PHY
type. The RX path needs this value to distinguish C-PHY from D-PHY
input, so leaving it at the default makes C-PHY configuration
incomplete.

Link: https://lore.kernel.org/r/20260717231331.1229693-3-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Add the lane_regs_sa8775p_3ph[] register table for the
sa8775p Gen3 CSIPHY at 1.5 Gsps, and select it in csiphy_lanes_enable() for
CAMSS_8775P when the endpoint is configured for C-PHY, falling back to the
existing sa8775p D-PHY table otherwise.

Link: https://lore.kernel.org/r/20260717231331.1229693-4-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Share the C-PHY/D-PHY lane_regs selection for CAMSS_8300 so
the sa8300 platform uses the same 3ph handling as CAMSS_8775P. Also drop
CAMSS_8300 from the missing-C-PHY-table guard now that a C-PHY table is
provided.

Link: https://lore.kernel.org/r/20260717231331.1229693-5-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…er settings

The C-PHY PHY register configuration needs to vary with the link
(symbol) data rate. Until now only a single base lane_regs table was
applied per platform, regardless of the negotiated rate.

Introduce a data-rate selection mechanism for C-PHY:

 - Add struct data_rate_reg_info describing a per-bandwidth register
   override table.
 - Add csiphy_cphy_data_rate_config(), which selects the first table
   entry whose bandwidth satisfies the required PHY data rate (derived
   from the resolved link frequency) and writes those overrides on top
   of the base lane_regs configuration. The settle-count parameter
   types are handled specially. When the link frequency cannot be
   resolved, it falls back to the lowest supported rate.

 - Add per-data-rate register tables and data_rate_settings tables for
   sa8775p and 8300(1.5/1.7/2.5/3.5/4.5 GSpS)
   and sm8250 (2.5/3.5/4.5 GSpS).

 - Select the appropriate data-rate settings table in
   csiphy_lanes_enable() for both platforms when the endpoint is
   configured for C-PHY.

Link: https://lore.kernel.org/r/20260717231331.1229693-6-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
A link is invalid if the local CSIPHY endpoint and the remote sensor
endpoint describe different bus types. Such a mismatch can otherwise go
undetected until later probe or streaming failures.

Parse the remote endpoint in camss_parse_endpoint_node() and compare its
bus-type with the local endpoint. Reject the link with -EINVAL if the two
ends disagree, so C-PHY/D-PHY mismatches are caught early during probe.

Link: https://lore.kernel.org/r/20260717231331.1229693-7-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Add device tree bindings for the Samsung S5KJN5, a 50 MP GBRG 10-bit RAW
MIPI CSI-2 image sensor controlled over CCI.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260724-sk5jn5-v2-1-871d3b9a2e47@oss.qualcomm.com/
Add a V4L2 sub-device driver for the Samsung S5KJN5, a 50 MP GBRG 10-bit
RAW MIPI CSI-2 image sensor. The driver supports the 4096x3072 mode and
exposes the standard controls (exposure, gain, vblank/hblank, test
pattern).

Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260724-sk5jn5-v2-1-871d3b9a2e47@oss.qualcomm.com/
Add bindings for the Camera Subsystem for X1P42100.

The X1P42100 platform provides:
- 2 x CSIPHY
- 3 x TPG
- 3 x CSID
- 2 x CSID Lite
- 1 x IFE
- 2 x IFE Lite

Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
The Purwa camera subsystem is a cut-down variant of the Hamoa CAMSS.
Compared to Hamoa, Purwa provides only two CSIPHY instances and does
not include the VFE1.

Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
@wenmliu
Wenmeng Liu (wenmliu) marked this pull request as draft August 14, 2026 03:48
@qcomlnxci
qcomlnxci requested review from a team, quic-vikramsa and svankada and removed request for a team August 14, 2026 03:50
@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1692

PR: #1692
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31767997656

# Error File:Line PR-introduced? Root Cause
1 Merge conflict during automerge drivers/media/platform/qcom/camss/camss.c Yes PR reverts and re-adds X1P42100 CAMSS support, causing conflict when merging with topic branch topic/tech/mm/camss

Verdict

The build failed during the automerge/integration phase with a merge conflict in drivers/media/platform/qcom/camss/camss.c. This is a PR-introduced integration issue, not a compilation error. The build never reached the compilation stage.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1692

PR: #1692
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31767997656

# Error File:Line PR-introduced? Root Cause
1 Merge conflict during automerge drivers/media/platform/qcom/camss/camss.c No Pre-existing conflict between PR changes and topic/tech/mm/camss branch during integration workflow

Verdict

This is not a compilation failure. The build failed during the automerge/integration step with a merge conflict in camss.c. No compilation errors were introduced by this PR.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

PR #1692 — validate-patch

PR: #1692

Verdict Issues Detailed Report
⚠️ 2 Full report

Final Summary

  1. Lore link present: No — PENDING prefix (commits 3/4, 4/4) and Revert commits (1/4, 2/4); no lore.kernel.org links expected or required for PENDING. Revert commits reference internal commit SHAs.

  2. Lore link matches PR commits: N/A — no lore links to compare against. PENDING commits are vendor work-in-progress. Revert commits reference internal tree commits.

  3. Upstream patch status: N/A — PENDING commits are not posted upstream by design. The reverted FROMLIST commits were presumably posted but are being replaced.

  4. PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

Verdict: ⚠️ — click to expand

🔍 Patch Validation

PR: #1692 - Revert FROMLIST X1P42100 camss patches and replace with PENDING versions
Upstream commit: N/A (no lore links present)
Verdict: ⚠️ PARTIAL

Summary by Commit

Commit 1/4: Revert "FROMLIST: dt-bindings: media: Add bindings for qcom,x1p42100-camss"

Verdict: ❌ FAIL

Commit Message

Check Status Note
Subject matches upstream N/A Revert commit - no upstream to compare
Body preserves rationale Missing rationale for why the revert is needed
Fixes tag present/correct N/A Not applicable for revert
Authorship preserved Author is the reverter
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml Deletes 424 lines - revert appears complete

Issues

  • Missing revert rationale: The commit message only states "This reverts commit 2c06f1f" without explaining why the revert is necessary. Kernel convention requires a clear explanation of the reason for reverting.
  • Integration presence: According to integration_presence_report.md, this commit is missing from both qcom-next and topics - this is a validation failure.

Commit 2/4: Revert "FROMLIST: media: qcom: camss: add support for X1P42100 camss"

Verdict: ⚠️ PARTIAL

Commit Message

Check Status Note
Subject matches upstream N/A Revert commit - no upstream to compare
Body preserves rationale Missing rationale for why the revert is needed
Fixes tag present/correct N/A Not applicable for revert
Authorship preserved Author is the reverter
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c Revert changes appear consistent
drivers/media/platform/qcom/camss/camss-vfe.c Revert changes appear consistent
drivers/media/platform/qcom/camss/camss.c Revert changes appear consistent
drivers/media/platform/qcom/camss/camss.h Revert changes appear consistent

Issues

  • Missing revert rationale: The commit message only states "This reverts commit ca32238" without explaining why the revert is necessary.
  • Integration presence: According to integration_presence_report.md, this commit is present in qcom-next - revert is valid.

Commit 3/4: PENDING: dt-bindings: media: Add bindings for qcom,x1p42100-camss

Verdict: ✅ PASS (for PENDING prefix)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING prefix - no upstream yet
Body preserves rationale Clear description of hardware capabilities
Fixes tag present/correct N/A Not a fix
Authorship preserved Original author
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml Adds 424 lines - appears to be the inverse of commit 1/4

Issues

  • None for PENDING prefix validation

Commit 4/4: PENDING: media: qcom: camss: add support for X1P42100 camss

Verdict: ✅ PASS (for PENDING prefix)

Commit Message

Check Status Note
Subject matches upstream N/A PENDING prefix - no upstream yet
Body preserves rationale Clear description: "Purwa camera subsystem is a cut-down variant of the Hamoa CAMSS"
Fixes tag present/correct N/A Not a fix
Authorship preserved Original author
Backport note (if applicable) N/A Not a backport

Diff

File Status Notes
drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c Adds support - appears to be the inverse of commit 2/4
drivers/media/platform/qcom/camss/camss-vfe.c Adds support
drivers/media/platform/qcom/camss/camss.c Adds support
drivers/media/platform/qcom/camss/camss.h Adds support

Issues

  • None for PENDING prefix validation

Overall Issues

  1. Commit 1/4 - Missing revert rationale: Revert commits must explain why the revert is needed, not just what is being reverted. The commit message should include a paragraph explaining the reason (e.g., "The original FROMLIST patches were posted but need significant rework based on upstream feedback" or similar).

  2. Commit 1/4 - Integration presence failure: This commit is missing from both qcom-next and topics branches, which is a validation failure per the integration_presence_report.md.

  3. Commit 2/4 - Missing revert rationale: Same issue as commit 1/4 - needs explanation of why the revert is necessary.

  4. Pattern observation: The PR appears to be reverting two FROMLIST commits (1/4, 2/4) and replacing them with nearly identical PENDING commits (3/4, 4/4). This suggests the patches may have been rejected upstream or need rework, but this context is not documented in the revert commit messages.

Verdict

⚠️ PARTIAL - The PENDING commits (3/4, 4/4) are correctly formatted for vendor-only work-in-progress patches. However, the revert commits (1/4, 2/4) lack required rationale, and commit 1/4 has an integration presence failure.

Recommendation

Request changes before merging:

  1. Amend commit 1/4 and 2/4 to add a paragraph explaining why the FROMLIST patches are being reverted. Example:

    This reverts commit 2c06f1f8c80404a40a96e283559935b1042d5799.
    
    The original FROMLIST patches were posted to the mailing list but require
    significant rework based on upstream review feedback. Reverting to replace
    with PENDING versions while the upstream discussion continues.
    
  2. Investigate commit 1/4 integration presence failure: The integration_presence_report.md shows this commit is missing from both qcom-next and topics. This needs to be resolved - either the commit needs to be present in one of these branches, or there's a mismatch in the revert target.

  3. Consider squashing: If the intent is to replace FROMLIST with PENDING versions, consider whether reverting and re-adding in separate commits is necessary, or if the commits could be amended directly with updated prefixes and commit messages.

Final Summary

  1. Lore link present: No — PENDING prefix (commits 3/4, 4/4) and Revert commits (1/4, 2/4); no lore.kernel.org links expected or required for PENDING. Revert commits reference internal commit SHAs.

  2. Lore link matches PR commits: N/A — no lore links to compare against. PENDING commits are vendor work-in-progress. Revert commits reference internal tree commits.

  3. Upstream patch status: N/A — PENDING commits are not posted upstream by design. The reverted FROMLIST commits were presumably posted but are being replaced.

  4. PR present in qcom-next/topics: Fail - 1/4 commit (commit 1/4) is missing from both qcom-next and topics per integration_presence_report.md. Commits 2/4, 3/4, and 4/4 are present in qcom-next.

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: 49dbe0dae5cfb7a1eb3434cde6fc7ba37924fe94
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/4 [PATCH 1/4] Revert "FROMLIST: dt-bindings: media: Add bindings for missing - no subject, patch-id, or full tree-content match found missing - no subject, patch-id, or full tree-content match found missing
2/4 [PATCH 2/4] Revert "FROMLIST: media: qcom: camss: add support for present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
3/4 [PATCH 3/4] PENDING: dt-bindings: media: Add bindings for present - exact patch-id match at f872d65 skipped - not checked because qcom-next already contains the change present
4/4 [PATCH 4/4] PENDING: media: qcom: camss: add support for X1P42100 present - all checked added lines are present skipped - not checked because qcom-next already contains the change present

Final Status

overall_status: FAIL
present_commits: 3/4
partial_commits: 0/4
missing_commits: 1/4
topics_checked_for_commits: 1/4
final_summary: PR present in qcom-next/topics: Fail - 1/4 commit(s) are missing from both qcom-next and topics

@qlijarvis

Copy link
Copy Markdown

PR #1692 — checker-log-analyzer

PR: #1692
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/31767996973

Checker Result Summary
Checker Result Summary
checkpatch ⏭️ Not executed - automerge failed
dt-binding-check ⏭️ Not executed - automerge failed
dtb-check ⏭️ Not executed - automerge failed
sparse-check ⏭️ Not executed - automerge failed
check-uapi-headers ⏭️ Not executed - automerge failed
check-patch-compliance ⏭️ Not executed - automerge failed
tag-check Subject prefix violations detected
qcom-next-check N/A Target is qcom-next (prefix check skipped)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1692 - Revert and re-add X1P42100 CAMSS support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/31767996973
Target branch: qcom-next

Checker Result Summary
checkpatch ⏭️ Not executed - automerge failed
dt-binding-check ⏭️ Not executed - automerge failed
dtb-check ⏭️ Not executed - automerge failed
sparse-check ⏭️ Not executed - automerge failed
check-uapi-headers ⏭️ Not executed - automerge failed
check-patch-compliance ⏭️ Not executed - automerge failed
tag-check Subject prefix violations detected
qcom-next-check N/A Target is qcom-next (prefix check skipped)

❌ Automerge Failure (Pre-Checker Stage)

Root cause: Merge conflict in drivers/media/platform/qcom/camss/camss.c when integrating with topic branch topic/tech/mm/camss.

Failure details:

** Merging topic branch: topic/tech/mm/camss
Auto-merging MAINTAINERS
Auto-merging drivers/media/platform/qcom/camss/camss.c
CONFLICT (content): Merge conflict in drivers/media/platform/qcom/camss/camss.c
Automatic merge failed; fix conflicts and then commit the result.
Merge failed, manual merge

Analysis:

The CI workflow failed during the automerge phase, before any checkers could run. The kernel-checkers CI workflow follows this sequence:

  1. Automerge phase: Merge all topic branches from the integration config into the baseline (qcom-next)
  2. Merge PR: Apply the PR commits on top of the integrated tree
  3. Run checkers: Execute checkpatch, dtb-check, sparse, etc.

This PR failed at step 1 — the automerge of topic/tech/mm/camss into qcom-next produced a merge conflict in drivers/media/platform/qcom/camss/camss.c.

Why this happened:

This PR contains:

  • Patch 1/4: Revert of a FROMLIST commit adding X1P42100 CAMSS bindings
  • Patch 2/4: Revert of a FROMLIST commit adding X1P42100 CAMSS driver support
  • Patch 3/4: PENDING version of X1P42100 CAMSS bindings
  • Patch 4/4: PENDING version of X1P42100 CAMSS driver support

The topic branch topic/tech/mm/camss likely contains overlapping changes to the same CAMSS driver file (camss.c), causing a conflict when the CI attempts to integrate all topic branches before applying this PR.

Fix:

This is not a patch defect — it's an integration conflict between this PR and another topic branch in the tree.

Option 1 (Recommended): Rebase this PR on top of the latest qcom-next + automerged topics:

# Locally reproduce the automerge
git clone https://github.com/qualcomm-linux/kernel.git
cd kernel
git checkout qcom-next
# Run automerge with the integration config (requires kernel-config repo)
# Then rebase your PR branch on top of the automerged result
git rebase <automerged-integration-branch>
# Resolve conflicts in drivers/media/platform/qcom/camss/camss.c
# Force-push the rebased PR branch

Option 2: Coordinate with the owner of topic/tech/mm/camss to resolve the conflict at the topic-branch level.

Option 3: If this PR is intended to replace the changes in topic/tech/mm/camss, remove that topic from the integration config before merging this PR.

Reproduce locally:

# Clone kernel-config repo to get automerge tooling
git clone https://github.com/qualcomm-linux/kernel-config.git
cd kernel-config
# Run automerge with the qcom-next integration config
./automerge.sh <path-to-integration-config>
# The conflict will appear during topic/tech/mm/camss merge

❌ tag-check

Root cause: Two commits have subject lines that do not start with a valid prefix tag.

Failure details:

The following commits are missing the required subject-line prefix:

  1. Commit 1/4: Revert "FROMLIST: dt-bindings: media: Add bindings for qcom,x1p42100-camss"
  2. Commit 2/4: Revert "FROMLIST: media: qcom: camss: add support for X1P42100 camss"

Analysis:

Per the checker-log-analyzer skill, all branches except qcom-next and qcom-next-staging require every commit subject to start with a valid prefix tag:

  • FROMLIST: / FROMGIT: / UPSTREAM: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

However, this PR targets qcom-next, which is explicitly exempted from the subject-prefix requirement.

Verdict:PASS (exempted)

The tag-check does not apply to this PR because the target branch is qcom-next. Commits 1/4 and 2/4 (the Revert commits) do not need a prefix tag when targeting qcom-next.

Note: If this PR were targeting any other branch (e.g., a stable branch, a vendor branch, or a feature branch), the Revert commits would need to be prefixed:

UPSTREAM: Revert "FROMLIST: dt-bindings: media: ..."
FROMLIST: Revert "FROMLIST: media: qcom: camss: ..."

Verdict

Blocker: Automerge conflict in drivers/media/platform/qcom/camss/camss.c must be resolved before checkers can run.

Action required:

  1. Rebase this PR on top of the latest automerged qcom-next integration tree (including topic/tech/mm/camss)
  2. Resolve the merge conflict in drivers/media/platform/qcom/camss/camss.c
  3. Force-push the rebased branch to re-trigger CI

No patch-level defects detected — the PR commits themselves are correctly formatted (subject prefixes are valid for qcom-next target). The failure is purely an integration conflict with another topic branch.

@wenmliu
Wenmeng Liu (wenmliu) force-pushed the tech/mm/camss branch 2 times, most recently from 99be92a to 94954b3 Compare August 24, 2026 08:25
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.

8 participants