| 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: <m6qrmvku6anw6ajg2qdbusodjxesfusi7w2pogvvz5lj5vfyx2@mcit7fy5w6ij>
Date: Wed, 7 May 2025 18:48:54 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Ayushi Makhija <quic_amakhija@...cinc.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 Wed, May 07, 2025 at 06:27:54PM +0530, Ayushi Makhija wrote:
> 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.
>
[...]
>
> Let me know, Which way we need to define the our anx7625 bridge supplies.
Please describe the power grid. As accurate as seems logical for you. I
won't give you a single 'this is correct' here, but generally I'd prefer
having all vin-supply properly set. Please use grid names from the
schematics in order to describe the regulators (instead of inventing
them).
Hope this helps. Anyway, it's easier to discuss the code once you post
something, so I'm looking forward to seeing the patch.
--
With best wishes
Dmitry
Powered by blists - more mailing lists