[PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
Bryan O'Donoghue
bod at kernel.org
Tue Jun 2 15:51:38 PDT 2026
On 02/06/2026 22:59, Vladimir Zapolskiy wrote:
> On 5/23/26 05:48, Bryan O'Donoghue wrote:
>> 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.
>>
>> The schema here defines three ports:
>>
>> port at 0:
>> The first input port where a sensor is always required.
>>
>> port at 1:
>> A second optional input port which if present implies DPHY split-mode.
>>
>> port at 2:
>> A third always required output port which connects to the controller.
>>
>
> This port numeration is imperfect, because port at 0 and port at 2 are required,
> while middle port at 1 is optional.
>
> Like it was stated before a number of times, it seems natural to operate
> with two ports, where input port may have two endpoints rather than 3 ports,
> also that approach solves the problem of a hole in the port numeration.
Can you confirm this is what you are after ?
port at 0 {
#address-cells = <1>;
#size-cells = <0>;
endpoint at 0 { /* primary sensor */
reg = <0>;
data-lanes = <0 1 2 3>;
remote-endpoint = <&sensor0_out>;
};
endpoint at 1 { /* split-mode second sensor, optional */
reg = <1>;
data-lanes = <0>;
remote-endpoint = <&sensor1_out>;
};
};
port at 1 { /* output to CAMSS, was port at 2 */
endpoint { remote-endpoint = <&controller_in>; };
};
This works for me BTW.
>> 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 | 209 +++++++++++++++++++++
>> 1 file changed, 209 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..270375f949880
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> @@ -0,0 +1,209 @@
>> +# 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
>> + description:
>> + The single cell specifies the PHY operating mode.
>
> #phy-cells should be 0, because the PHY operating mode is well defined
> by 'bus-type' property of an endpoint on the sensor side, the opposite
> side of CAMSS/CSID as a CSIPHY "consumer" should not dictate the PHY type.
Rob said consumer but, I'm also not very bothered about that. bus-type
is perfectly acceptable to me.
>> +
>> + clocks:
>> + maxItems: 2
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: timer
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + operating-points-v2:
>> + maxItems: 1
>> +
>> + power-domains:
>> + items:
>> + - description: MMCX voltage rail
>> + - description: MXC or MXA voltage rail
>
> Only "qcom,x1e80100-csi2-phy" device is supported so far, unlikely it's
> the case that "MXC or MXA voltage rail" should be specified, it'd be
> just one of two or both.
Hmm. I'm not being clear here if this is your take, I will reword it to
make it clearer this generation of PHY _must_ have either
- MMCX and MXC
or
- MMCX and MXA
>> +
>> + power-domain-names:
>> + items:
>> + - const: mmcx
>> + - const: mx
>> +
>> + vdda-0p9-supply:
>> + description: Phandle to a 0.9V regulator supply to a PHY.
>> +
>> + vdda-1p2-supply:
>> + description: Phandle to 1.2V regulator supply to a PHY.
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + properties:
>> + port at 0:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Sensor input. Always present.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>> + properties:
>> + data-lanes:
>> + minItems: 1
>> + maxItems: 4
>> + clock-lanes:
>> + maxItems: 1
>> + remote-endpoint: true
>> + required:
>> + - data-lanes
>> + - remote-endpoint
>> +
>> + port at 1:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description:
>> + Second sensor input. When present, indicates DPHY split mode.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>> + properties:
>> + data-lanes:
>> + maxItems: 1
>> + clock-lanes:
>> + maxItems: 1
>> + remote-endpoint: true
>> + required:
>> + - data-lanes
>> + - clock-lanes
>> + - remote-endpoint
>
> As it's stated above, it should be converted to a single port with two
> endpoints, it'd be done in accordance to video-interfaces.yaml.
>
>> +
>> + port at 2:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Output to CAMSS controller.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
>> + unevaluatedProperties: false
>> + properties:
>> + remote-endpoint: true
>> + required:
>> + - remote-endpoint
>> +
>> + required:
>> + - port at 0
>> + - port at 2
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> + - interrupts
>> + - operating-points-v2
>> + - power-domains
>> + - power-domain-names
>> + - vdda-0p9-supply
>> + - vdda-1p2-supply
>> + - ports
>> +
>> +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/power/qcom,rpmhpd.h>
>> +
>> + csiphy4: 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>;
>> + clock-names = "core",
>> + "timer";
>> +
>> + operating-points-v2 = <&csiphy_opp_table>;
>> +
>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>> +
>> + power-domains = <&rpmhpd RPMHPD_MMCX>,
>> + <&rpmhpd RPMHPD_MX>;
>> + power-domain-names = "mmcx",
>> + "mx";
>> +
>> + vdda-0p9-supply = <&vreg_l2c_0p8>;
>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + reg = <0>;
>> + csiphy0_in_ep: endpoint {
>> + data-lanes = <0 1>;
>> + clock-lanes = <2>;
>> + remote-endpoint = <&sensor_out>;
>> + };
>> + };
>> +
>> + port at 2 {
>> + reg = <2>;
>> + csiphy0_out_ep: endpoint {
>> + remote-endpoint = <&controller_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + 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_d1>;
>> + };
>> +
>> + opp-480000000 {
>> + opp-hz = /bits/ 64 <480000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>,
>> + <&rpmhpd_opp_low_svs_d1>;
>> + };
>> + };
>>
>
> --
> Best wishes,
> Vladimir
More information about the linux-phy
mailing list