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 | 114 +++++++++++++++++++++
1 file changed, 114 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..c937d26ccbda9
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
@@ -0,0 +1,114 @@
+# 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:
+ maxItems: 1
+
+ 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
+ - 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>
+
+ 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>;
+
+ vdda-0p8-supply = <&vreg_l2c_0p8>;
+ vdda-1p2-supply = <&vreg_l1c_1p2>;
+ };
+
+ csiphy_opp_table: opp-table-csiphy {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+ };
--
2.52.0Hi Bryan,
On 2/26/2026 4:34 AM, 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 | 114 +++++++++++++++++++++
> 1 file changed, 114 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..c937d26ccbda9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,114 @@
> +# 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:
> + maxItems: 1
> +
> + 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
> + - 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>
> +
> + 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>;
As we are cleaning up the PHY device nodes, we should consider fixing
the power domains as well. Although TOP GDSC is defined as a power
domain, it is not the power source for the PHY devices. Rather, it is
the MMCX, MXC and optionally MXA based on the architecture (Refer to
'Voltage rail' column for PHY clocks in IPCAT). There is no
parent-child relationship between the TOP GDSC and these in the clock
driver and it was just working as the required power rails are getting
enabled by/for other MM devices.
> +
> + vdda-0p8-supply = <&vreg_l2c_0p8>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> + };
> +
> + csiphy_opp_table: opp-table-csiphy {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>;
> + };
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-480000000 {
> + opp-hz = /bits/ 64 <480000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> + };
>
Thanks,
Vijay.
On Mon, Mar 02, 2026 at 05:51:24PM -0800, Vijay Kumar Tumati wrote: > Hi Bryan, > > On 2/26/2026 4:34 AM, Bryan O'Donoghue wrote: > > + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>; > As we are cleaning up the PHY device nodes, we should consider fixing the > power domains as well. Although TOP GDSC is defined as a power domain, it is > not the power source for the PHY devices. Rather, it is the MMCX, MXC and > optionally MXA based on the architecture (Refer to 'Voltage rail' column for > PHY clocks in IPCAT). There is no > parent-child relationship between the TOP GDSC and these in the clock driver > and it was just working as the required power rails are getting enabled > by/for other MM devices. Which domains are required to access CSI PHY registers? > > + > > + vdda-0p8-supply = <&vreg_l2c_0p8>; > > + vdda-1p2-supply = <&vreg_l1c_1p2>; > > + }; > > + -- With best wishes Dmitry
On 3/3/2026 2:31 PM, Dmitry Baryshkov wrote: > On Mon, Mar 02, 2026 at 05:51:24PM -0800, Vijay Kumar Tumati wrote: >> Hi Bryan, >> >> On 2/26/2026 4:34 AM, Bryan O'Donoghue wrote: >>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>; >> As we are cleaning up the PHY device nodes, we should consider fixing the >> power domains as well. Although TOP GDSC is defined as a power domain, it is >> not the power source for the PHY devices. Rather, it is the MMCX, MXC and >> optionally MXA based on the architecture (Refer to 'Voltage rail' column for >> PHY clocks in IPCAT). There is no >> parent-child relationship between the TOP GDSC and these in the clock driver >> and it was just working as the required power rails are getting enabled >> by/for other MM devices. > > Which domains are required to access CSI PHY registers? PHY register access requires the PHY core clock, cam_top_ahb clock. So in my understanding, we need to trace these clocks in the topology backwards up until at least the RCG, and all the voltage rails powering these clocks will be the required power domains. Having said that, just register access works even if the voltage rails are configured to the min level, which camcc does already. > >>> + >>> + vdda-0p8-supply = <&vreg_l2c_0p8>; >>> + vdda-1p2-supply = <&vreg_l1c_1p2>; >>> + }; >>> + > Thanks, Vijay.
On Tue, Mar 03, 2026 at 03:24:16PM -0800, Vijay Kumar Tumati wrote: > > > On 3/3/2026 2:31 PM, Dmitry Baryshkov wrote: > > On Mon, Mar 02, 2026 at 05:51:24PM -0800, Vijay Kumar Tumati wrote: > > > Hi Bryan, > > > > > > On 2/26/2026 4:34 AM, Bryan O'Donoghue wrote: > > > > + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>; > > > As we are cleaning up the PHY device nodes, we should consider fixing the > > > power domains as well. Although TOP GDSC is defined as a power domain, it is > > > not the power source for the PHY devices. Rather, it is the MMCX, MXC and > > > optionally MXA based on the architecture (Refer to 'Voltage rail' column for > > > PHY clocks in IPCAT). There is no > > > parent-child relationship between the TOP GDSC and these in the clock driver > > > and it was just working as the required power rails are getting enabled > > > by/for other MM devices. > > > > Which domains are required to access CSI PHY registers? > PHY register access requires the PHY core clock, cam_top_ahb clock. So in my > understanding, we need to trace these clocks in the topology backwards up > until at least the RCG, and all the voltage rails powering these clocks will > be the required power domains. Having said that, just register access works > even if the voltage rails are configured to the min level, which camcc does > already. Are they not gated by the GDSC? > > > > > > + > > > > + vdda-0p8-supply = <&vreg_l2c_0p8>; > > > > + vdda-1p2-supply = <&vreg_l1c_1p2>; > > > > + }; > > > > + > > > Thanks, > Vijay. -- With best wishes Dmitry
On 3/3/2026 3:49 PM, Dmitry Baryshkov wrote: > On Tue, Mar 03, 2026 at 03:24:16PM -0800, Vijay Kumar Tumati wrote: >> >> >> On 3/3/2026 2:31 PM, Dmitry Baryshkov wrote: >>> On Mon, Mar 02, 2026 at 05:51:24PM -0800, Vijay Kumar Tumati wrote: >>>> Hi Bryan, >>>> >>>> On 2/26/2026 4:34 AM, Bryan O'Donoghue wrote: >>>>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>; >>>> As we are cleaning up the PHY device nodes, we should consider fixing the >>>> power domains as well. Although TOP GDSC is defined as a power domain, it is >>>> not the power source for the PHY devices. Rather, it is the MMCX, MXC and >>>> optionally MXA based on the architecture (Refer to 'Voltage rail' column for >>>> PHY clocks in IPCAT). There is no >>>> parent-child relationship between the TOP GDSC and these in the clock driver >>>> and it was just working as the required power rails are getting enabled >>>> by/for other MM devices. >>> >>> Which domains are required to access CSI PHY registers? >> PHY register access requires the PHY core clock, cam_top_ahb clock. So in my >> understanding, we need to trace these clocks in the topology backwards up >> until at least the RCG, and all the voltage rails powering these clocks will >> be the required power domains. Having said that, just register access works >> even if the voltage rails are configured to the min level, which camcc does >> already. > > Are they not gated by the GDSC? All the Titan CAMCC clocks are gated by the TOP GDSC, yes. > >>> >>>>> + >>>>> + vdda-0p8-supply = <&vreg_l2c_0p8>; >>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>; >>>>> + }; >>>>> + >>> >> Thanks, >> Vijay. > Thanks, Vijay.
On 03/03/2026 09:27, Bryan O'Donoghue wrote: > - MXA - first time I've heard of this rail, from memory I don't remember > having seen this in ipcat when I could do so. Yeah no MXA isn't a required vote. https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/ --- bod
On 3/3/2026 1:30 AM, Bryan O'Donoghue wrote: > On 03/03/2026 09:27, Bryan O'Donoghue wrote: >> - MXA - first time I've heard of this rail, from memory I don't remember >> having seen this in ipcat when I could do so. > > Yeah no MXA isn't a required vote. > > https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/ If I am not wrong, CAMCC only enables the power domains that source the CAMCC block and it's register access. And for that, it only needs those power domains to be just enabled without any performance vote. Based on her comment, if MXA is always enabled (at min level), probably CAMCC driver doesn't need to enable or scale it explicitly. However, the camera devices that actually depend on this power domain for their core functionality need to scale this per the core clock corner. I can double check though. > > --- > bod > Thanks, Vijay.
On 3/3/26 10:30 AM, Bryan O'Donoghue wrote: > On 03/03/2026 09:27, Bryan O'Donoghue wrote: >> - MXA - first time I've heard of this rail, from memory I don't remember >> having seen this in ipcat when I could do so. > > Yeah no MXA isn't a required vote. That depends on the use case. MXA is always-on (that's the 'A' in the name, as opposed to 'C' for 'Collapsible'), but it's not always at the required performance state (svs, nom, etc.). For some clock controllers specifically, there is no need to put them into the picture, as the rail may be unconnected altogether, or only used for some retention mechanisms (which only require the rail to be enabled and nothing more) Konrad > > https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/ > > --- > bod > >
On 03/03/2026 12:34, Konrad Dybcio wrote: > That depends on the use case. > > MXA is always-on (that's the 'A' in the name, as opposed to 'C' > for 'Collapsible'), but it's not always at the required performance > state (svs, nom, etc.). For some clock controllers specifically, there > is no need to put them into the picture, as the rail may be unconnected > altogether, or only used for some retention mechanisms (which only > require the rail to be enabled and nothing more) Does this rail have an OPP table you can share ? --- bod
On 3/3/26 3:56 PM, Bryan O'Donoghue wrote: > On 03/03/2026 12:34, Konrad Dybcio wrote: >> That depends on the use case. >> >> MXA is always-on (that's the 'A' in the name, as opposed to 'C' >> for 'Collapsible'), but it's not always at the required performance >> state (svs, nom, etc.). For some clock controllers specifically, there >> is no need to put them into the picture, as the rail may be unconnected >> altogether, or only used for some retention mechanisms (which only >> require the rail to be enabled and nothing more) > > Does this rail have an OPP table you can share ? Camera clocks on X1 (mclks and the fixed PLL2, which is exclusively used to derive MCLKs) that potentially depend on this rail (awaiting Taniya's opinion on the other thread [1]) would only need LOWSVS_D1 for all of their configurations (ftbl_cam_cc_mclk0_clk_src[]) i.e. let's wait for a definitive answer as there's a lot of layers.. [1] https://lore.kernel.org/linux-arm-msm/382725b5-1e72-44b2-b9ae-38aea1f7a976@oss.qualcomm.com/ Konrad
On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
> Hi Bryan,
>
> On 2/26/2026 4:34 AM, 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 | 114 +++++++++++++++++++++
>> 1 file changed, 114 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..c937d26ccbda9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> @@ -0,0 +1,114 @@
>> +# 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:
>> + maxItems: 1
>> +
>> + 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
>> + - 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>
>> +
>> + 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>;
> As we are cleaning up the PHY device nodes, we should consider fixing
> the power domains as well. Although TOP GDSC is defined as a power
> domain, it is not the power source for the PHY devices. Rather, it is
> the MMCX, MXC and optionally MXA based on the architecture (Refer to
> 'Voltage rail' column for PHY clocks in IPCAT).
Feel free to send me a qcom laptop and I will :)
From memory though I _thought_ only the TOP was required for the PHY.
I'd be grateful if you could confirm yourself in ipcat.
- TITAN_TOP_GDSC
- MXC
- MMCX
- MXA - first time I've heard of this rail, from memory I don't remember
having seen this in ipcat when I could do so.
There is no
> parent-child relationship between the TOP GDSC and these in the clock
> driver and it was just working as the required power rails are getting
> enabled by/for other MM devices.
Well only the GDSC is supplied by the clock controller.
>> +
>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>> + };
>> +
>> + csiphy_opp_table: opp-table-csiphy {
>> + compatible = "operating-points-v2";
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>> + };
>> +
>> + opp-400000000 {
>> + opp-hz = /bits/ 64 <400000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-480000000 {
>> + opp-hz = /bits/ 64 <480000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> + };
>>
> Thanks,
> Vijay.
On 3/3/2026 1:27 AM, Bryan O'Donoghue wrote:
> On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
>> Hi Bryan,
>>
>> On 2/26/2026 4:34 AM, 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 | 114 +++++++++
>>> ++++++++++++
>>> 1 file changed, 114 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..c937d26ccbda9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>> @@ -0,0 +1,114 @@
>>> +# 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:
>>> + maxItems: 1
>>> +
>>> + 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
>>> + - 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>
>>> +
>>> + 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>;
>> As we are cleaning up the PHY device nodes, we should consider fixing
>> the power domains as well. Although TOP GDSC is defined as a power
>> domain, it is not the power source for the PHY devices. Rather, it is
>> the MMCX, MXC and optionally MXA based on the architecture (Refer to
>> 'Voltage rail' column for PHY clocks in IPCAT).
>
> Feel free to send me a qcom laptop and I will :)
:)
>
> From memory though I _thought_ only the TOP was required for the PHY.
> I'd be grateful if you could confirm yourself in ipcat.
>
> - TITAN_TOP_GDSC
> - MXC
> - MMCX
> - MXA - first time I've heard of this rail, from memory I don't remember
> having seen this in ipcat when I could do so.
MCX and MMCX are comminly required power domains across the PHYs but a
subset of PHYs have the dependency on MXA.
>
> There is no
>> parent-child relationship between the TOP GDSC and these in the clock
>> driver and it was just working as the required power rails are getting
>> enabled by/for other MM devices.
>
> Well only the GDSC is supplied by the clock controller.
Right, GDSC is controlled by the CAMCC to suspend the subsystems. But
the actual power supply and the voltage rails are under the control of
the RPMH. So the clients need to enable and vote for the required perf
corner as the core clocks scale up/down to be independent of the other
subsystems sharing those voltage rails.
>
>>> +
>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>> + };
>>> +
>>> + csiphy_opp_table: opp-table-csiphy {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-300000000 {
>>> + opp-hz = /bits/ 64 <300000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>>> + };
>>> +
>>> + opp-400000000 {
>>> + opp-hz = /bits/ 64 <400000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-480000000 {
>>> + opp-hz = /bits/ 64 <480000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> + };
>>>
>> Thanks,
>> Vijay.
>
Thanks,
Vijay.
On 3/3/2026 10:08 AM, Vijay Kumar Tumati wrote:
>
>
> On 3/3/2026 1:27 AM, Bryan O'Donoghue wrote:
>> On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
>>> Hi Bryan,
>>>
>>> On 2/26/2026 4:34 AM, 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 | 114 ++++++++
>>>> + ++++++++++++
>>>> 1 file changed, 114 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..c937d26ccbda9
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>> @@ -0,0 +1,114 @@
>>>> +# 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:
>>>> + maxItems: 1
>>>> +
>>>> + 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
>>>> + - 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>
>>>> +
>>>> + 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>;
>>> As we are cleaning up the PHY device nodes, we should consider fixing
>>> the power domains as well. Although TOP GDSC is defined as a power
>>> domain, it is not the power source for the PHY devices. Rather, it is
>>> the MMCX, MXC and optionally MXA based on the architecture (Refer to
>>> 'Voltage rail' column for PHY clocks in IPCAT).
>>
>> Feel free to send me a qcom laptop and I will :)
> :)
>>
>> From memory though I _thought_ only the TOP was required for the PHY.
>> I'd be grateful if you could confirm yourself in ipcat.
>>
>> - TITAN_TOP_GDSC
>> - MXC
>> - MMCX
>> - MXA - first time I've heard of this rail, from memory I don't remember
>> having seen this in ipcat when I could do so.
> MCX and MMCX are comminly required power domains across the PHYs but a
> subset of PHYs have the dependency on MXA.
Actually, it's a bit more complicated on this target as
cam_cc_cphy_rx_clk_src also depends on MXA, which means all the CBCs
connected this RCG do as well.
>>
>> There is no
>>> parent-child relationship between the TOP GDSC and these in the clock
>>> driver and it was just working as the required power rails are getting
>>> enabled by/for other MM devices.
>>
>> Well only the GDSC is supplied by the clock controller.
> Right, GDSC is controlled by the CAMCC to suspend the subsystems. But
> the actual power supply and the voltage rails are under the control of
> the RPMH. So the clients need to enable and vote for the required perf
> corner as the core clocks scale up/down to be independent of the other
> subsystems sharing those voltage rails.
>>
>>>> +
>>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>>> + };
>>>> +
>>>> + csiphy_opp_table: opp-table-csiphy {
>>>> + compatible = "operating-points-v2";
>>>> +
>>>> + opp-300000000 {
>>>> + opp-hz = /bits/ 64 <300000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>>>> + };
>>>> +
>>>> + opp-400000000 {
>>>> + opp-hz = /bits/ 64 <400000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> +
>>>> + opp-480000000 {
>>>> + opp-hz = /bits/ 64 <480000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> + };
>>>>
>>> Thanks,
>>> Vijay.
>>
> Thanks,
> Vijay.
On 03/03/2026 18:58, Vijay Kumar Tumati wrote:
>>> - TITAN_TOP_GDSC
>>> - MXC
>>> - MMCX
>>> - MXA - first time I've heard of this rail, from memory I don't remember
>>> having seen this in ipcat when I could do so.
>> MCX and MMCX are comminly required power domains across the PHYs but a
>> subset of PHYs have the dependency on MXA.
> Actually, it's a bit more complicated on this target as
> cam_cc_cphy_rx_clk_src also depends on MXA, which means all the CBCs
> connected this RCG do as well.
Right but that's something to model in the clock-controller then not the
PHY.
i.e. if a clock depends on MXA then the clock controller should
represent that dependency - not the PHY that depends on the clock.
camcc on hamoa looks like this
camcc: clock-controller@ade0000 {
compatible = "qcom,x1e80100-camcc";
reg = <0 0x0ade0000 0 0x20000>;
clocks = <&gcc GCC_CAMERA_AHB_CLK>,
<&bi_tcxo_div2>,
<&bi_tcxo_ao_div2>,
<&sleep_clk>;
power-domains = <&rpmhpd RPMHPD_MXC>,
<&rpmhpd RPMHPD_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>,
<&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
So... we may need to add MXA here, probably do based on what you've said
but I believe TITAN_TOP_GDSC is the only power-domain we need to list
for the PHYs themselves, as what you've described above is a clock power
dependency which we basically already capture in the clock controller -
absent the MXA - which is apparently always on...
Sidenote, is MXA required for videocc too ?
videocc: clock-controller@aaf0000 {
compatible = "qcom,x1e80100-videocc";
reg = <0 0x0aaf0000 0 0x10000>;
clocks = <&bi_tcxo_div2>,
<&gcc GCC_VIDEO_AHB_CLK>;
power-domains = <&rpmhpd RPMHPD_MMCX>,
<&rpmhpd RPMHPD_MXC>;
required-opps = <&rpmhpd_opp_low_svs>,
<&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
---
bod
On 3/3/2026 2:53 PM, Bryan O'Donoghue wrote:
> On 03/03/2026 18:58, Vijay Kumar Tumati wrote:
>>>> - TITAN_TOP_GDSC
>>>> - MXC
>>>> - MMCX
>>>> - MXA - first time I've heard of this rail, from memory I don't
>>>> remember
>>>> having seen this in ipcat when I could do so.
>>> MCX and MMCX are comminly required power domains across the PHYs but
>>> a subset of PHYs have the dependency on MXA.
>> Actually, it's a bit more complicated on this target as
>> cam_cc_cphy_rx_clk_src also depends on MXA, which means all the CBCs
>> connected this RCG do as well.
>
> Right but that's something to model in the clock-controller then not the
> PHY.
>
> i.e. if a clock depends on MXA then the clock controller should
> represent that dependency - not the PHY that depends on the clock.
>
> camcc on hamoa looks like this
>
> camcc: clock-controller@ade0000 {
> compatible = "qcom,x1e80100-camcc";
> reg = <0 0x0ade0000 0 0x20000>;
> clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> <&bi_tcxo_div2>,
> <&bi_tcxo_ao_div2>,
> <&sleep_clk>;
> power-domains = <&rpmhpd RPMHPD_MXC>,
> <&rpmhpd RPMHPD_MMCX>;
> required-opps = <&rpmhpd_opp_low_svs>,
> <&rpmhpd_opp_low_svs>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
> };
>
> So... we may need to add MXA here, probably do based on what you've said
> but I believe TITAN_TOP_GDSC is the only power-domain we need to list
> for the PHYs themselves, as what you've described above is a clock power
> dependency which we basically already capture in the clock controller -
> absent the MXA - which is apparently always on...
>
> Sidenote, is MXA required for videocc too ?
>
> videocc: clock-controller@aaf0000 {
> compatible = "qcom,x1e80100-videocc";
> reg = <0 0x0aaf0000 0 0x10000>;
> clocks = <&bi_tcxo_div2>,
> <&gcc GCC_VIDEO_AHB_CLK>;
> power-domains = <&rpmhpd RPMHPD_MMCX>,
> <&rpmhpd RPMHPD_MXC>;
> required-opps = <&rpmhpd_opp_low_svs>,
> <&rpmhpd_opp_low_svs>;
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
> };
>
> ---
> bod
Well, the current upstream clock driver (at least for CAMCC) enables
these power domains at the min level but they do not scale them. So even
if we add MXA in the camcc device, they won't be scaled per the PHY core
clocks. For example, if you are running PHY at TURBO, the power supplies
may still be at the min level or scaled individually according to the
requests from other sub systems. If we need this to be controlled from
the clock driver directly, we will need multiple performance states for
the TOP GDSC.However, this GDSC enables all the clocks in Titan, each
with it's own voltage rail connections, so a bit complicated but can be
discussed with the clock driver team.
Sorry, I do not know about videocc.
Thanks,
Vijay.
On 03/03/2026 23:17, Vijay Kumar Tumati wrote:
> Sorry, I do not know about videocc.
I think Iris does those itself see:
iris: video-codec@aa00000 {
compatible = "qcom,x1e80100-iris",
"qcom,sm8550-iris";
reg = <0 0x0aa00000 0 0xf0000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
<&videocc VIDEO_CC_MVS0_GDSC>,
<&rpmhpd RPMHPD_MXC>,
<&rpmhpd RPMHPD_MMCX>;
power-domain-names = "venus",
"vcodec0",
"mxc",
"mmcx";
Still not getting an especially clear picture on what _levels_ you are
proposing here for MXA - here are the three opps we have for the PHY.
Sorry I don't get how turbo is coming into this ..
+ csiphy_opp_table: opp-table-csiphy {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ required-opps = <&rpmhpd_opp_low_svs_d1>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+ };
---
bod
On 3/3/2026 3:26 PM, Bryan O'Donoghue wrote:
> On 03/03/2026 23:17, Vijay Kumar Tumati wrote:
>> Sorry, I do not know about videocc.
>
> I think Iris does those itself see:
>
> iris: video-codec@aa00000 {
> compatible = "qcom,x1e80100-iris",
> "qcom,sm8550-iris";
>
> reg = <0 0x0aa00000 0 0xf0000>;
> interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>
> power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
> <&videocc VIDEO_CC_MVS0_GDSC>,
> <&rpmhpd RPMHPD_MXC>,
> <&rpmhpd RPMHPD_MMCX>;
> power-domain-names = "venus",
> "vcodec0",
> "mxc",
> "mmcx";
>
> Still not getting an especially clear picture on what _levels_ you are
> proposing here for MXA - here are the three opps we have for the PHY.
>
> Sorry I don't get how turbo is coming into this ..
Sure, I was just giving an example. I haven't looked a lot into the
IPCAT / clock corners of this target particularly. Someone needs to
check the clock plan, understand which PHYs require which power domains
and add that in the following OPP table and as for scaling you can use
the same RPMH levels for all those power domains. Btw, if you had
defined the below OPP table for TOP GDSC, I think that is wrong. It only
has two perf states (on and off) and doesn't need OPP scaling. If you
look at the Iris driver, they link only the mxc and mmcx power domains
to the OPP table using 'PD_FLAG_REQUIRED_OPP, not the GDSCs.
>
> + csiphy_opp_table: opp-table-csiphy {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>;
> + };
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-480000000 {
> + opp-hz = /bits/ 64 <480000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + };
> + };
>
> ---
> bod
Thanks,
Vijay.
On 03/03/2026 23:50, Vijay Kumar Tumati wrote:
> Sure, I was just giving an example. I haven't looked a lot into the
> IPCAT / clock corners of this target particularly. Someone needs to
> check the clock plan,
I mean, feel free.
understand which PHYs require which power domains
> and add that in the following OPP table and as for scaling you can use
> the same RPMH levels for all those power domains. Btw, if you had
> defined the below OPP table for TOP GDSC, I think that is wrong. It only
> has two perf states (on and off) and doesn't need OPP scaling. If you
> look at the Iris driver, they link only the mxc and mmcx power domains
> to the OPP table using 'PD_FLAG_REQUIRED_OPP, not the GDSCs.
>>
>> + csiphy_opp_table: opp-table-csiphy {
>> + compatible = "operating-points-v2";
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>> + };
>> +
>> + opp-400000000 {
>> + opp-hz = /bits/ 64 <400000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-480000000 {
>> + opp-hz = /bits/ 64 <480000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> + };
>>
>> ---
>> bod
Yes, we should scale the MX*, that's incorrect.
csiphy_mxc_opp_table: opp-table-csiphy-mxc {
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>;
};
};
csiphy_mxa_opp_table: opp-table-csiphy-mxa {
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>;
};
};
csiphy0: phy@ace4000 {
power-domains = <&rpmhpd RPMHPD_MXC>,
<&rpmhpd RPMHPD_MMCX>;
operating-points-v2 = <&csiphy_mxc_opp_table>;
...
};
csiphy4: phy@acec000 {
power-domains = <&rpmhpd RPMHPD_MXA>,
<&rpmhpd RPMHPD_MMCX>;
operating-points-v2 = <&csiphy_mxa_opp_table>;
...
};
---
bod
On 3/3/2026 4:02 PM, Bryan O'Donoghue wrote:
> On 03/03/2026 23:50, Vijay Kumar Tumati wrote:
>> Sure, I was just giving an example. I haven't looked a lot into the
>> IPCAT / clock corners of this target particularly. Someone needs to
>> check the clock plan,
>
> I mean, feel free.
>
> understand which PHYs require which power domains
>> and add that in the following OPP table and as for scaling you can use
>> the same RPMH levels for all those power domains. Btw, if you had
>> defined the below OPP table for TOP GDSC, I think that is wrong. It
>> only has two perf states (on and off) and doesn't need OPP scaling. If
>> you look at the Iris driver, they link only the mxc and mmcx power
>> domains to the OPP table using 'PD_FLAG_REQUIRED_OPP, not the GDSCs.
>>>
>>> + csiphy_opp_table: opp-table-csiphy {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-300000000 {
>>> + opp-hz = /bits/ 64 <300000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>>> + };
>>> +
>>> + opp-400000000 {
>>> + opp-hz = /bits/ 64 <400000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-480000000 {
>>> + opp-hz = /bits/ 64 <480000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> + };
>>>
>>> ---
>>> bod
>
> Yes, we should scale the MX*, that's incorrect.
>
> csiphy_mxc_opp_table: opp-table-csiphy-mxc {
> 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>;
> };
> };
>
> csiphy_mxa_opp_table: opp-table-csiphy-mxa {
> 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>;
> };
> };
>
> csiphy0: phy@ace4000 {
> power-domains = <&rpmhpd RPMHPD_MXC>,
> <&rpmhpd RPMHPD_MMCX>;
> operating-points-v2 = <&csiphy_mxc_opp_table>;
> ...
> };
>
> csiphy4: phy@acec000 {
> power-domains = <&rpmhpd RPMHPD_MXA>,
> <&rpmhpd RPMHPD_MMCX>;
> operating-points-v2 = <&csiphy_mxa_opp_table>;
> ...
> };
>
> ---
> bod
Yes, something like this based on this target architecture. A couple
things though.
You will still need to have the GDSC as a power domain and attach to it,
just skip that from registering with the OPP framework .
As I mentioned, if the RCG, 'cam_cc_cphy_rx_clk_src' depends on MXA
(actually, I just checked for X1E80100 and it seems to require all
three), the children of those (all CSIPHY clocks) indirectly depend on
all three power domains. Additionally, This is the RCG for CSID and CSID
Lite RX clocks as well but we can deal with those when we refactor the
CSID nodes.
Thanks,
Vijay.
On Thu, Feb 26, 2026 at 12:34:25PM +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 | 114 +++++++++++++++++++++
> 1 file changed, 114 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..c937d26ccbda9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,114 @@
> +# 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
Qualcomm SoC 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.
So just to be clear: this is not MIPI CSI, but only the CSI PHY? There
are no ports here, which seems fine for the phy and will be in the MIPI
CSI block?
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
> +
> + clocks:
> + maxItems: 4
> +
> + clock-names:
> + items:
> + - const: csiphy
probably: core or iface
> + - const: csiphy_timer
timer
> + - const: camnoc_axi
axi or noc
> + - const: cpas_ahb
bus, ahb or cpas, depending whether this is only one ahb or this is bus of
some cpas subblock
See also: https://lore.kernel.org/all/20260115-sm6150_evk-v3-2-81526dd15543@oss.qualcomm.com/
> +
> + interrupts:
> + maxItems: 1
> +
> + operating-points-v2:
Just true. It is not an array.
> + maxItems: 1
Also opp-table like in other schemas.
> +
> + power-domains:
> + maxItems: 1
> +
> + 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
> + - 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>
> +
> + csiphy@ace4000 {
phy@ or csi-phy@
> + 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>;
> +
> + vdda-0p8-supply = <&vreg_l2c_0p8>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> + };
> +
> + csiphy_opp_table: opp-table-csiphy {
Drop entire node, not relevant here.
Best regards,
Krzysztof
On 27/02/2026 09:41, Krzysztof Kozlowski wrote: > On Thu, Feb 26, 2026 at 12:34:25PM +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 | 114 +++++++++++++++++++++ >> 1 file changed, 114 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..c937d26ccbda9 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml >> @@ -0,0 +1,114 @@ >> +# 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 > > Qualcomm SoC 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. > > So just to be clear: this is not MIPI CSI, but only the CSI PHY? There > are no ports here, which seems fine for the phy and will be in the MIPI > CSI block? CAMSS ports map to the CSID - CSI Decoder yes. > >> + >> +properties: >> + compatible: >> + const: qcom,x1e80100-csi2-phy >> + >> + reg: >> + maxItems: 1 >> + >> + "#phy-cells": >> + const: 1 >> + >> + clocks: >> + maxItems: 4 >> + >> + clock-names: >> + items: >> + - const: csiphy > > probably: core or iface > >> + - const: csiphy_timer > > timer > >> + - const: camnoc_axi > > axi or noc > >> + - const: cpas_ahb > > bus, ahb or cpas, depending whether this is only one ahb or this is bus of > some cpas subblock > > See also: https://lore.kernel.org/all/20260115-sm6150_evk-v3-2-81526dd15543@oss.qualcomm.com/ > > >> + >> + interrupts: >> + maxItems: 1 >> + >> + operating-points-v2: > > Just true. It is not an array. LOL I asked a chatbot to review my submission and it told me to change this from true to a list. €90 subscription well spent... Thanks for review. --- bod
© 2016 - 2026 Red Hat, Inc.