| Message ID | 20250505094245.2660750-3-quic_amakhija@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add DSI display support for SA8775P target | expand |
Hi Dmitry, On 5/5/2025 3:32 PM, Dmitry Baryshkov wrote: > On Mon, May 05, 2025 at 03:12:41PM +0530, Ayushi Makhija wrote: >> Add anx7625 DSI to DP bridge device nodes. >> >> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> >> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >> --- >> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 183 +++++++++++++++++++++ >> 1 file changed, 183 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >> index 175f8b1e3b2d..de14f3ea8835 100644 >> --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >> +++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >> @@ -28,6 +28,15 @@ chosen { >> stdout-path = "serial0:115200n8"; >> }; >> >> + vph_pwr: vph-pwr-regulator { >> + compatible = "regulator-fixed"; >> + regulator-name = "vph_pwr"; >> + regulator-min-microvolt = <12000000>; >> + regulator-max-microvolt = <12000000>; > > 12 V, if my eyes don't deceive me. Yes, it's 12V. According to the chipset's power grid, the VPH rail is rated at 12 volts. That's significantly higher than what we typically see on mobile platforms. I guess, this is due to the SA8775P Ride SX being designed for automotive applications, where higher voltage levels are required. > >> + regulator-always-on; >> + regulator-boot-on; >> + }; >> + > > [...] > >> + >> + bridge@58 { >> + compatible = "analogix,anx7625"; >> + reg = <0x58>; >> + interrupts-extended = <&io_expander 2 IRQ_TYPE_EDGE_FALLING>; >> + enable-gpios = <&io_expander 1 GPIO_ACTIVE_HIGH>; >> + reset-gpios = <&io_expander 0 GPIO_ACTIVE_HIGH>; >> + vdd10-supply = <&vph_pwr>; >> + vdd18-supply = <&vph_pwr>; >> + vdd33-supply = <&vph_pwr>; > > Here you are saying that 1.0V, 1.8V and 3.3V pins are powered on by 12V > supply. I wonder how the board doesn't trigger all fire alarms in the > building. > Let me try to explain the connections from the schematics. In the SA8775P RIDE SX platform, the ANX bridge supplies are connected from the below sources: 1) AVDD1P8 is sourced from the `VREG_1P8` of the backplane card. 2) AVDD3P0 is sourced from the `VREG_3P0` of the backplane card. 3) AVDD1P0 is sourced from the TPS74801 LDO voltage regulator that has `VREG_1P8` connected to VIN & EN lines, and `VREG_3P0` connected to BIAS line. The `VREG_1P8` is sourced from a buck converter TPS54618CQRTERQ1 that is using `VREG_5P0` as VIN and EN_VR1P8_M3P3 as EN signal. Where the `EN_VR1P8_M3P3` is an output signal from SAK-TC397XX-256F300S BD micro-controller. Similarly, the `VREG_1P3` and `VREG_5P0` are sourced from another buck converter LM5143QRWGRQ1 that is using `VREG_12P0` as VIN and `EN_VR5P0_M3P3` as EN signal. Where the EN_VR5P0_M3P3 is an output from the same micro-controller. Combining above details, all three ANX bridge supplies are getting enabled by `VREG_12P0` supply, `EN_VR1P8_M3P3` and `EN_VR5P0_M3P3` signals once the SOC is out of reset. The `VREG_12P0` is directly sourced from `VBATT_IN`. Since, there is no SW control for ANX bridge supplies and they are getting enabled once the SOC is out of reset, I have used vph-pwr-regulator dummy regulator. I am not sure if it's the right way to handle above scenario. Please let me know if there is other way to do the same. Thanks, Ayushi >> + >
On Tue, May 06, 2025 at 05:42:50PM +0530, Ayushi Makhija wrote: > Hi Dmitry, > > On 5/5/2025 3:32 PM, Dmitry Baryshkov wrote: > > On Mon, May 05, 2025 at 03:12:41PM +0530, Ayushi Makhija wrote: > >> Add anx7625 DSI to DP bridge device nodes. > >> > >> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> > >> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> > >> --- > >> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 183 +++++++++++++++++++++ > >> 1 file changed, 183 insertions(+) > >> > >> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi > >> index 175f8b1e3b2d..de14f3ea8835 100644 > >> --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi > >> +++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi > >> @@ -28,6 +28,15 @@ chosen { > >> stdout-path = "serial0:115200n8"; > >> }; > >> > >> + vph_pwr: vph-pwr-regulator { > >> + compatible = "regulator-fixed"; > >> + regulator-name = "vph_pwr"; > >> + regulator-min-microvolt = <12000000>; > >> + regulator-max-microvolt = <12000000>; > > > > 12 V, if my eyes don't deceive me. > > Yes, it's 12V. According to the chipset's power grid, the VPH rail is rated at 12 volts. > That's significantly higher than what we typically see on mobile platforms. I guess, > this is due to the SA8775P Ride SX being designed for automotive applications, where higher voltage levels are required. > > > > >> + regulator-always-on; > >> + regulator-boot-on; > >> + }; > >> + > > > > [...] > > > >> + > >> + bridge@58 { > >> + compatible = "analogix,anx7625"; > >> + reg = <0x58>; > >> + interrupts-extended = <&io_expander 2 IRQ_TYPE_EDGE_FALLING>; > >> + enable-gpios = <&io_expander 1 GPIO_ACTIVE_HIGH>; > >> + reset-gpios = <&io_expander 0 GPIO_ACTIVE_HIGH>; > >> + vdd10-supply = <&vph_pwr>; > >> + vdd18-supply = <&vph_pwr>; > >> + vdd33-supply = <&vph_pwr>; > > > > Here you are saying that 1.0V, 1.8V and 3.3V pins are powered on by 12V > > supply. I wonder how the board doesn't trigger all fire alarms in the > > building. > > > > Let me try to explain the connections from the schematics. > > In the SA8775P RIDE SX platform, the ANX bridge supplies are connected from the below sources: > > 1) AVDD1P8 is sourced from the `VREG_1P8` of the backplane card. > 2) AVDD3P0 is sourced from the `VREG_3P0` of the backplane card. > 3) AVDD1P0 is sourced from the TPS74801 LDO voltage regulator that has `VREG_1P8` connected to > VIN & EN lines, and `VREG_3P0` connected to BIAS line. > > The `VREG_1P8` is sourced from a buck converter TPS54618CQRTERQ1 that is using > `VREG_5P0` as VIN and EN_VR1P8_M3P3 as EN signal. > Where the `EN_VR1P8_M3P3` is an output signal from SAK-TC397XX-256F300S BD micro-controller. > > Similarly, the `VREG_1P3` and `VREG_5P0` are sourced from another buck converter LM5143QRWGRQ1 > that is using `VREG_12P0` as VIN and `EN_VR5P0_M3P3` as EN signal. > Where the EN_VR5P0_M3P3 is an output from the same micro-controller. > > Combining above details, all three ANX bridge supplies are getting enabled by `VREG_12P0` supply, > `EN_VR1P8_M3P3` and `EN_VR5P0_M3P3` signals once the SOC is out of reset. > > The `VREG_12P0` is directly sourced from `VBATT_IN`. > > Since, there is no SW control for ANX bridge supplies and they are getting enabled > once the SOC is out of reset, I have used vph-pwr-regulator dummy regulator. > I am not sure if it's the right way to handle above scenario. Please let me know if there is other way to do the same. Add these regulators as fixed ones, describing the power grid. Consult other board files if you are unsure. RB3, RB5, HDKs - all these boards have fixed-regulators for the grid.
On 5/6/2025 5:58 PM, Dmitry Baryshkov wrote: > On Tue, May 06, 2025 at 05:42:50PM +0530, Ayushi Makhija wrote: >> Hi Dmitry, >> >> On 5/5/2025 3:32 PM, Dmitry Baryshkov wrote: >>> On Mon, May 05, 2025 at 03:12:41PM +0530, Ayushi Makhija wrote: >>>> Add anx7625 DSI to DP bridge device nodes. >>>> >>>> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com> >>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> >>>> --- >>>> arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 183 +++++++++++++++++++++ >>>> 1 file changed, 183 insertions(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >>>> index 175f8b1e3b2d..de14f3ea8835 100644 >>>> --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >>>> +++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi >>>> @@ -28,6 +28,15 @@ chosen { >>>> stdout-path = "serial0:115200n8"; >>>> }; >>>> >>>> + vph_pwr: vph-pwr-regulator { >>>> + compatible = "regulator-fixed"; >>>> + regulator-name = "vph_pwr"; >>>> + regulator-min-microvolt = <12000000>; >>>> + regulator-max-microvolt = <12000000>; >>> >>> 12 V, if my eyes don't deceive me. >> >> Yes, it's 12V. According to the chipset's power grid, the VPH rail is rated at 12 volts. >> That's significantly higher than what we typically see on mobile platforms. I guess, >> this is due to the SA8775P Ride SX being designed for automotive applications, where higher voltage levels are required. >> >>> >>>> + regulator-always-on; >>>> + regulator-boot-on; >>>> + }; >>>> + >>> >>> [...] >>> >>>> + >>>> + bridge@58 { >>>> + compatible = "analogix,anx7625"; >>>> + reg = <0x58>; >>>> + interrupts-extended = <&io_expander 2 IRQ_TYPE_EDGE_FALLING>; >>>> + enable-gpios = <&io_expander 1 GPIO_ACTIVE_HIGH>; >>>> + reset-gpios = <&io_expander 0 GPIO_ACTIVE_HIGH>; >>>> + vdd10-supply = <&vph_pwr>; >>>> + vdd18-supply = <&vph_pwr>; >>>> + vdd33-supply = <&vph_pwr>; >>> >>> Here you are saying that 1.0V, 1.8V and 3.3V pins are powered on by 12V >>> supply. I wonder how the board doesn't trigger all fire alarms in the >>> building. >>> >> >> Let me try to explain the connections from the schematics. >> >> In the SA8775P RIDE SX platform, the ANX bridge supplies are connected from the below sources: >> >> 1) AVDD1P8 is sourced from the `VREG_1P8` of the backplane card. >> 2) AVDD3P0 is sourced from the `VREG_3P0` of the backplane card. >> 3) AVDD1P0 is sourced from the TPS74801 LDO voltage regulator that has `VREG_1P8` connected to >> VIN & EN lines, and `VREG_3P0` connected to BIAS line. >> >> The `VREG_1P8` is sourced from a buck converter TPS54618CQRTERQ1 that is using >> `VREG_5P0` as VIN and EN_VR1P8_M3P3 as EN signal. >> Where the `EN_VR1P8_M3P3` is an output signal from SAK-TC397XX-256F300S BD micro-controller. >> >> Similarly, the `VREG_1P3` and `VREG_5P0` are sourced from another buck converter LM5143QRWGRQ1 >> that is using `VREG_12P0` as VIN and `EN_VR5P0_M3P3` as EN signal. >> Where the EN_VR5P0_M3P3 is an output from the same micro-controller. >> >> Combining above details, all three ANX bridge supplies are getting enabled by `VREG_12P0` supply, >> `EN_VR1P8_M3P3` and `EN_VR5P0_M3P3` signals once the SOC is out of reset. >> >> The `VREG_12P0` is directly sourced from `VBATT_IN`. >> >> Since, there is no SW control for ANX bridge supplies and they are getting enabled >> once the SOC is out of reset, I have used vph-pwr-regulator dummy regulator. >> I am not sure if it's the right way to handle above scenario. Please let me know if there is other way to do the same. > > Add these regulators as fixed ones, describing the power grid. Consult > other board files if you are unsure. RB3, RB5, HDKs - all these boards > have fixed-regulators for the grid. > Hi Dmirty, After referring the RB3, RB5, HDKs boards example for fixed regulator. 1) Reference 1 (qrb5165-rb5.dts file) (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts) In qrb5165-rb5.dts file, If we refer the fixed regulator of lt9611_1v2 lt9611_1v2: lt9611-vdd12-regulator { compatible = "regulator-fixed"; regulator-name = "LT9611_1V2"; vin-supply = <&vdc_3v3>; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; }; Here we can see the vin-supply is vdc_3v3, which is itself is a fixed-regulator. vdc_3v3: vdc-3v3-regulator { compatible = "regulator-fixed"; regulator-name = "VDC_3V3"; vin-supply = <&vreg_l11c_3p3>; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-always-on; }; Then vin-supply for vdc_3v3 is vreg_l11c_3p3, Which is a RPMH regulator. vreg_l11c_3p3: ldo11 { regulator-name = "vreg_l11c_3p3"; regulator-min-microvolt = <3296000>; regulator-max-microvolt = <3296000>; regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; regulator-always-on; }; Do we need to do the same for our vdd10-supply , vdd18-supply and vdd33-supply of anx7625 bridge supplies ? Example for vdd18-supply (AVDD1P8) (Anx7625 vdd18-supply) vreg_1p8 : vreg-vdd18-regulator { compatible = "regulator-fixed"; regulator-name = "vreg_1p8"; vin-supply = <&vreg_5p0>; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; Here vreg_1p8 is using vreg_5p0 as vin-supply. vreg_5p0 : vreg-5p0-regulator { compatible = "regulator-fixed"; regulator-name = "vreg_5p0"; vin-supply = <&vreg_12p0>; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; }; Here vreg_5p0 is using vreg_12p0 as vin-supply. vreg_12p0: vreg-12p0-regulator { compatible = "regulator-fixed"; regulator-name = "vreg_12p0"; regulator-min-microvolt = <12000000>; regulator-max-microvolt = <12000000>; }; 2) Reference 2 (qcs6490-rb3gen2.dts) (https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts) Or In qcs6490-rb3gen2.dts file, If we refer the fixed regulator of lt9611_1v2 lt9611_1v2: lt9611-vdd12-regulator { compatible = "regulator-fixed"; regulator-name = "LT9611_1V2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; }; There is not any vin-supply here. Example for vdd18-supply (AVDD1P8) (Anx7625 vdd18-supply) vreg_1p8 : vreg-vdd18-regulator { compatible = "regulator-fixed"; regulator-name = "vreg_1p8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; Let me know, Which way we need to define the our anx7625 bridge supplies. Thanks, Ayushi
diff --git a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi index 175f8b1e3b2d..de14f3ea8835 100644 --- a/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi @@ -28,6 +28,15 @@ chosen { stdout-path = "serial0:115200n8"; }; + vph_pwr: vph-pwr-regulator { + compatible = "regulator-fixed"; + regulator-name = "vph_pwr"; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + regulator-always-on; + regulator-boot-on; + }; + vreg_conn_1p8: vreg_conn_1p8 { compatible = "regulator-fixed"; regulator-name = "vreg_conn_1p8"; @@ -128,6 +137,30 @@ dp1_connector_in: endpoint { }; }; }; + + dp-dsi0-connector { + compatible = "dp-connector"; + label = "DSI0"; + type = "full-size"; + + port { + dp_dsi0_connector_in: endpoint { + remote-endpoint = <&dsi2dp_bridge0_out>; + }; + }; + }; + + dp-dsi1-connector { + compatible = "dp-connector"; + label = "DSI1"; + type = "full-size"; + + port { + dp_dsi1_connector_in: endpoint { + remote-endpoint = <&dsi2dp_bridge1_out>; + }; + }; + }; }; &apps_rsc { @@ -519,7 +552,108 @@ &i2c18 { clock-frequency = <400000>; pinctrl-0 = <&qup_i2c18_default>; pinctrl-names = "default"; + status = "okay"; + + io_expander: gpio@74 { + compatible = "ti,tca9539"; + reg = <0x74>; + interrupts-extended = <&tlmm 98 IRQ_TYPE_EDGE_BOTH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + reset-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>; + + pinctrl-0 = <&io_expander_intr_active>, + <&io_expander_reset_active>; + pinctrl-names = "default"; + }; + + i2c-mux@70 { + compatible = "nxp,pca9543"; + #address-cells = <1>; + + #size-cells = <0>; + reg = <0x70>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + bridge@58 { + compatible = "analogix,anx7625"; + reg = <0x58>; + interrupts-extended = <&io_expander 2 IRQ_TYPE_EDGE_FALLING>; + enable-gpios = <&io_expander 1 GPIO_ACTIVE_HIGH>; + reset-gpios = <&io_expander 0 GPIO_ACTIVE_HIGH>; + vdd10-supply = <&vph_pwr>; + vdd18-supply = <&vph_pwr>; + vdd33-supply = <&vph_pwr>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dsi2dp_bridge0_in: endpoint { + remote-endpoint = <&mdss0_dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + + dsi2dp_bridge0_out: endpoint { + remote-endpoint = <&dp_dsi0_connector_in>; + }; + }; + }; + }; + }; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + bridge@58 { + compatible = "analogix,anx7625"; + reg = <0x58>; + interrupts-extended = <&io_expander 10 IRQ_TYPE_EDGE_FALLING>; + enable-gpios = <&io_expander 9 GPIO_ACTIVE_HIGH>; + reset-gpios = <&io_expander 8 GPIO_ACTIVE_HIGH>; + vdd10-supply = <&vph_pwr>; + vdd18-supply = <&vph_pwr>; + vdd33-supply = <&vph_pwr>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dsi2dp_bridge1_in: endpoint { + remote-endpoint = <&mdss0_dsi1_out>; + }; + }; + + port@1 { + reg = <1>; + + dsi2dp_bridge1_out: endpoint { + remote-endpoint = <&dp_dsi1_connector_in>; + }; + }; + }; + }; + }; + }; + }; &mdss0 { @@ -566,6 +700,40 @@ &mdss0_dp1_phy { status = "okay"; }; +&mdss0_dsi0 { + vdda-supply = <&vreg_l1c>; + + status = "okay"; +}; + +&mdss0_dsi0_out { + data-lanes = <0 1 2 3>; + remote-endpoint = <&dsi2dp_bridge0_in>; +}; + +&mdss0_dsi0_phy { + vdds-supply = <&vreg_l4a>; + + status = "okay"; +}; + +&mdss0_dsi1 { + vdda-supply = <&vreg_l1c>; + + status = "okay"; +}; + +&mdss0_dsi1_out { + data-lanes = <0 1 2 3>; + remote-endpoint = <&dsi2dp_bridge1_in>; +}; + +&mdss0_dsi1_phy { + vdds-supply = <&vreg_l4a>; + + status = "okay"; +}; + &pmm8654au_0_gpios { gpio-line-names = "DS_EN", "POFF_COMPLETE", @@ -714,6 +882,21 @@ ethernet0_mdio: ethernet0-mdio-pins { }; }; + io_expander_intr_active: io-expander-intr-active-state { + pins = "gpio98"; + function = "gpio"; + drive-strength = <2>; + bias-disable; + }; + + io_expander_reset_active: io-expander-reset-active-state { + pins = "gpio97"; + function = "gpio"; + drive-strength = <2>; + bias-disable; + output-high; + }; + qup_uart10_default: qup-uart10-state { pins = "gpio46", "gpio47"; function = "qup1_se3";