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@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@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
+ - 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@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";
+
+ 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>;
+ };
+ };
--
2.52.0Hi 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@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@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.
> + - 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@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.
> +
> + 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?
> + };
> + };
>
Thanks,
Vijay.
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@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@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.
>> + - 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@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.
>> +
>> + 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.
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@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@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@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.
On 3/17/26 9:25 PM, Vijay Kumar Tumati wrote:
>
>
> 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@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@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@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.
I'll admit I haven't yet read up on all of the background discussions that you
guys had on LKML, but *if* we're going to put the PHY under camss, the GDSC and
CPAS_AHB/CAMNOC_AXI_RT references should be unnecessary, given they're not
related strictly to this PHY itself, rather it sitting in a specific corner of
the subsystem that needs them to be active (see related:
https://lore.kernel.org/linux-arm-msm/cb2430f2-8601-4c72-af6b-10f1ff16c188@oss.qualcomm.com/
)
For the other names, I *think* we won't need to rely on them (i.e. only operate
the resources through PHY APIs from the V4L2 driver) and can come up with new
ones. And hence I think we can turn "csiphy" to "core" and "csiphy_timer" to
"timer" (because we really don't need to repeat the csiphy_ prefix)
Konrad
On 23/03/2026 14:22, Konrad Dybcio wrote: >> Sure, FYI: Dmitry, Konrad. > I'll admit I haven't yet read up on all of the background discussions that you > guys had on LKML, but*if* we're going to put the PHY under camss, the GDSC and > CPAS_AHB/CAMNOC_AXI_RT references should be unnecessary, given they're not > related strictly to this PHY itself, rather it sitting in a specific corner of > the subsystem that needs them to be active (see related: > https://lore.kernel.org/linux-arm-msm/cb2430f2-8601-4c72- > af6b-10f1ff16c188@oss.qualcomm.com/ > ) That's fair comment with the PHYs inside of the CAMSS block. Obviously if its outside of the block we need the full gamut of clocks defined. .. Yeah I think I'm happy enough to drop these predicated on sub-nodes. > For the other names, I*think* we won't need to rely on them (i.e. only operate > the resources through PHY APIs from the V4L2 driver) and can come up with new > ones. And hence I think we can turn "csiphy" to "core" and "csiphy_timer" to > "timer" (because we really don't need to repeat the csiphy_ prefix) Works for me. --- bod
On Sun, Mar 15, 2026 at 11:52:06PM +0000, 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@linaro.org> > --- > .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++ > 1 file changed, 133 insertions(+) > <form letter> This is a friendly reminder during the review process. It seems my or other reviewer's previous comments were not fully addressed. Maybe the feedback got lost between the quotes, maybe you just forgot to apply it. Please go back to the previous discussion and either implement all requested changes or keep discussing them. Thank you. </form letter> Best regards, Krzysztof
On 3/16/26 01:52, 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@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@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
Hence there should be a description of phy-type property, or it could be
specified in a cell on the client's side.
> + modes.
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
The description is missing.
> +
> + 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
> + - 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.
On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8.
> +
> + 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>
Please sort the list of headers alphanumerically.
> +
> + csiphy@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";
> +
> + 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>;
> + };
> + };
>
--
Best wishes,
Vladimir
On Mon, Mar 16, 2026 at 03:58:14AM +0200, Vladimir Zapolskiy wrote: > On 3/16/26 01:52, 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@linaro.org> > > --- > > .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++ > > 1 file changed, 133 insertions(+) > > > > + > > + vdda-0p8-supply: > > + description: Phandle to a 0.8V regulator supply to a PHY. > > On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8. What is its name in the schematics or in the datasheet? > > > + > > + vdda-1p2-supply: > > + description: Phandle to 1.2V regulator supply to a PHY. > > + -- With best wishes Dmitry
On 3/16/26 3:45 AM, Dmitry Baryshkov wrote: > On Mon, Mar 16, 2026 at 03:58:14AM +0200, Vladimir Zapolskiy wrote: >> On 3/16/26 01:52, 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@linaro.org> >>> --- >>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++ >>> 1 file changed, 133 insertions(+) >>> >>> + >>> + vdda-0p8-supply: >>> + description: Phandle to a 0.8V regulator supply to a PHY. >> >> On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8. > > What is its name in the schematics or in the datasheet? VDD_A_CSI_n_0P9 so vdda-0p9 seems fitting Konrad
On 16/03/2026 10:49, Konrad Dybcio wrote: >>> On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8. >> What is its name in the schematics or in the datasheet? > VDD_A_CSI_n_0P9 > > so vdda-0p9 seems fitting > > Konrad (0.88+0.92) / 2 == 0.9 I'm happy with the average. --- bod
© 2016 - 2026 Red Hat, Inc.