PENDING: change FROMLIST changes to PENDING tag - #1692
PENDING: change FROMLIST changes to PENDING tag#1692Wenmeng Liu (wenmliu) wants to merge 53 commits into
Conversation
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/
…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/
…camss" This reverts commit 2c06f1f.
This reverts commit ca32238.
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>
🔨 Build Failure Analysis — PR #1692PR: #1692
VerdictThe build failed during the automerge/integration phase with a merge conflict in 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1692PR: #1692
VerdictThis is not a compilation failure. The build failed during the automerge/integration step with a merge conflict in 📎 Detailed analysis: Full report |
PR #1692 — validate-patchPR: #1692
Final Summary
|
PR #1692 — checker-log-analyzerPR: #1692
Detailed report: Full report
|
99be92a to
94954b3
Compare
No description provided.