| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <bd136800-8ef5-4597-b918-41b9f97db14f@quicinc.com>
Date: Wed, 7 May 2025 18:27:54 +0530
From: Ayushi Makhija <quic_amakhija@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: <linux-arm-msm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<freedreno@...ts.freedesktop.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <robdclark@...il.com>,
<sean@...rly.run>, <marijn.suijten@...ainline.org>,
<andersson@...nel.org>, <robh@...nel.org>, <robh+dt@...nel.org>,
<krzk+dt@...nel.org>, <konradybcio@...nel.org>, <conor+dt@...nel.org>,
<andrzej.hajda@...el.com>, <neil.armstrong@...aro.org>,
<rfoss@...nel.org>, <Laurent.pinchart@...asonboard.com>,
<jonas@...boo.se>, <jernej.skrabec@...il.com>,
<quic_abhinavk@...cinc.com>, <quic_rajeevny@...cinc.com>,
<quic_vproddut@...cinc.com>, <quic_jesszhan@...cinc.com>,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Subject: Re: [PATCH v6 07/11] arm64: dts: qcom: sa8775p-ride: add anx7625 DSI
to DP bridge nodes
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@...cinc.com>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@....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
Powered by blists - more mailing lists