[PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
Vijay Kumar Tumati
vijay.tumati at oss.qualcomm.com
Tue Mar 17 13:25:07 PDT 2026
On 3/16/2026 10:26 PM, Bryan O'Donoghue wrote:
> On 16/03/2026 21:31, Vijay Kumar Tumati wrote:
>> Hi Bryan,
>>
>> On 3/15/2026 4:52 PM, Bryan O'Donoghue wrote:
>>> Add a base schema initially compatible with x1e80100 to describe MIPI
>>> CSI2
>>> PHY devices.
>>>
>>> The hardware can support both C-PHY and D-PHY modes. 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.
>>>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
>>> ---
>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++
>>> ++++++++++++
>>> 1 file changed, 133 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-
>>> csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-
>>> csi2-phy.yaml
>>> new file mode 100644
>>> index 0000000000000..b83c2d65ebc6e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>> @@ -0,0 +1,133 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm CSI2 PHY
>>> +
>>> +maintainers:
>>> + - Bryan O'Donoghue <bod at kernel.org>
>>> +
>>> +description:
>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2
>>> sensors
>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and
>>> D-PHY
>>> + modes.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: qcom,x1e80100-csi2-phy
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + "#phy-cells":
>>> + const: 1
>>> +
>>> + clocks:
>>> + maxItems: 4
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: csiphy
>>> + - const: csiphy_timer
>>> + - const: camnoc_axi
>>> + - const: cpas_ahb
>>> +
>>> + interrupts:
>>> + maxItems: 1
>>> +
>>> + operating-points-v2:
>>> + maxItems: 1
>>> +
>>> + power-domains:
>>> + items:
>>> + - description: TITAN TOP GDSC
>>> + - description: MXC or MXA voltage rail
>> Would it be better to provision MXA or MXC as an additional optional
>> power domain? I see 'cam_cc_cphy_rx_clk_src', the parent of all CSIPHYx
>> clocks, need all three power domains on this chipset.
>
> I don't think this should be optional. Have the dts point to an "mx"
> power-domain and then select which one is right for a PHY MX/MXA or MXC.
>
> Your worst case here is some future PHY which has more or fewer PDs
> which is then either a special case in this file or a whole new file for
> that compat.
>
I think it is the case on x1e* as well, Bryan.
>>> + - description: MMCX voltage rail
>>> +
>>> + power-domain-names:
>>> + items:
>>> + - const: top
>>> + - const: mx
>>> + - const: mmcx
>>> +
>>> + vdda-0p8-supply:
>>> + description: Phandle to a 0.8V regulator supply to a PHY.
>>> +
>>> + vdda-1p2-supply:
>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - "#phy-cells"
>>> + - clocks
>>> + - clock-names
>>> + - interrupts
>>> + - operating-points-v2
>>> + - power-domains
>>> + - power-domain-names
>>> + - vdda-0p8-supply
>>> + - vdda-1p2-supply
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>> + #include <dt-bindings/phy/phy.h>
>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>> +
>>> + csiphy at ace4000 {
>>> + compatible = "qcom,x1e80100-csi2-phy";
>>> + reg = <0x0ace4000 0x2000>;
>>> + #phy-cells = <1>;
>>> +
>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>>> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
>>> + <&camcc CAM_CC_CPAS_AHB_CLK>;
>>> + clock-names = "csiphy",
>>> + "csiphy_timer",
>>> + "camnoc_axi",
>>> + "cpas_ahb";
>> Although it's not a concern from my side, just want to be explicitly
>> sure that everyone is happy with the clock names, just to avoid any
>> changes later on when other modules are separated out.
>
> These are the names we already use in CAMSS so ... they're good enough
> to start from.
>
Sure, FYI: Dmitry, Konrad.
>>> +
>>> + operating-points-v2 = <&csiphy_opp_table>;
>>> +
>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>> +
>>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
>>> + <&rpmhpd RPMHPD_MX>,
>>> + <&rpmhpd RPMHPD_MMCX>;
>>> + power-domain-names = "top",
>>> + "mx",
>>> + "mmcx";
>>> +
>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>> + };
>>> +
>>> + csiphy_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-300000000 {
>>> + opp-hz = /bits/ 64 <300000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>>> + <&rpmhpd_opp_low_svs_d1>;
>>> + };
>>> +
>>> + opp-400000000 {
>>> + opp-hz = /bits/ 64 <400000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>> + <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-480000000 {
>>> + opp-hz = /bits/ 64 <480000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>> + <&rpmhpd_opp_low_svs>;
>> 480mhz should be svs?
>
> Yes you're right thanks for spotting.
>
>>> + };
>>> + };
>>>
>> Thanks,
>> Vijay.
>
Thanks,
Vijay.
More information about the linux-phy
mailing list