[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <umnolmlh63rgtoj4e6aubaupr3o44gxcufzele6wkxlosukskz@d5kuxk3pfkfu>
Date: Tue, 16 Sep 2025 14:04:51 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Yingying Tang <quic_yintang@...cinc.com>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
Yijie Yang <yijie.yang@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Yingying Tang <yingying.tang@....qualcomm.com>,
Shuai Zhang <shuaz@....qualcomm.com>
Subject: Re: [PATCH v11 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
On Tue, Sep 16, 2025 at 06:29:08PM +0800, Yingying Tang wrote:
>
>
> On 9/16/2025 6:14 PM, Dmitry Baryshkov wrote:
> > On Tue, Sep 16, 2025 at 09:42:26AM +0800, Yingying Tang wrote:
> >>
> >>
> >> On 9/12/2025 5:00 PM, Stephan Gerhold wrote:
> >>> On Wed, Sep 10, 2025 at 05:02:12PM +0800, Yijie Yang wrote:
> >>>> The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of
> >>>> the Hamoa IoT SoM and a carrier board. Together, they form a complete
> >>>> embedded system capable of booting to UART.
> >>>>
> >>>> Make the following peripherals on the carrier board enabled:
> >>>> - UART
> >>>> - On-board regulators
> >>>> - USB Type-C mux
> >>>> - Pinctrl
> >>>> - Embedded USB (EUSB) repeaters
> >>>> - NVMe
> >>>> - pmic-glink
> >>>> - USB DisplayPorts
> >>>> - Bluetooth
> >>>> - WLAN
> >>>> - Audio
> >>>>
> >>>> Written in collaboration with Quill Qi (Audio) <le.qi@....qualcomm.com>,
> >>>> Jie Zhang (Graphics) <quic_jiezh@...cinc.com>, Shuai Zhang (Bluetooth)
> >>>> <quic_shuaz@...cinc.com>, Yingying Tang (WLAN) <quic_yintang@...cinc.com>,
> >>>> and Yongxing Mou (USB DisplayPorts) <quic_yongmou@...cinc.com>.
> >>>
> >>> This looks like you should have Co-developed-by: tags together with
> >>> their Signed-off-by: tags.
> >>>
> >>>>
> >>>> Signed-off-by: Yijie Yang <yijie.yang@....qualcomm.com>
> >>>> ---
> >>>> arch/arm64/boot/dts/qcom/Makefile | 1 +
> >>>> arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 1221 ++++++++++++++++++++++++++++
> >>>> 2 files changed, 1222 insertions(+)
> >>>>
> >>>> +
> >>>> + vreg_wcn_3p3: regulator-wcn-3p3 {
> >>>> + compatible = "regulator-fixed";
> >>>> +
> >>>> + regulator-name = "VREG_WCN_3P3";
> >>>> + regulator-min-microvolt = <3300000>;
> >>>> + regulator-max-microvolt = <3300000>;
> >>>> +
> >>>> + gpio = <&tlmm 214 GPIO_ACTIVE_HIGH>;
> >>>> + enable-active-high;
> >>>> +
> >>>> + pinctrl-0 = <&wcn_sw_en>;
> >>>> + pinctrl-names = "default";
> >>>> +
> >>>
> >>> regulator-boot-on?
> >>
> >> It shoulde be regulator-always-on
> >
> > Why it's not boot-on and always-on?
> >
> As I described before, connectivity power is voted by UEFI in boot phase.So PCIe link between connetivity card and RC4 is established once RC4 is on.
> If we set this node as "regulator-boot-on", connectivity power will be down first then up. That cause PCIe link down and the link can't be trained again unless you reboot board.
> So we can't set it to "regulator-boot-on"
I've asked about it being boot-on + always-on. Any issues with that? I
doubt that it will cause a spike on the regulator.
> >>>
> >>>> + regulator-always-on;
> >>>> + };
> >>>> +
> >>
> >
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists