[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ng7koaqz6s4cslugrujklsrprsl7v7wijtserr6edvsvbeqfkv@pldexeryni7h>
Date: Fri, 18 Jul 2025 12:27:34 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Yijie Yang <yijie.yang@....qualcomm.com>
Cc: Stephan Gerhold <stephan.gerhold@...aro.org>,
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
Subject: Re: [PATCH 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
On Fri, Jul 18, 2025 at 04:19:13PM +0800, Yijie Yang wrote:
>
>
> On 2025-07-18 00:37, Stephan Gerhold wrote:
> > On Wed, Jul 16, 2025 at 05:08:42PM +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.
> > >
> > > This change enables and overlays the following peripherals on the carrier
> > > board:
> > > - UART
> > > - On-board regulators
> > > - USB Type-C mux
> > > - Pinctrl
> > > - Embedded USB (EUSB) repeaters
> > > - NVMe
> > > - pmic-glink
> > >
> > > Written with contributions from Shuai Zhang (added Bluetooth).
> > >
> > > 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 | 835 +++++++++++++++++++++++++++++
> > > 2 files changed, 836 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > index 4bfa926b6a0850c3c459bcba28129c559d50a7cf..c5994b75d3e56e74ffb64b2389ee1bcc086f3065 100644
> > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8039-t2.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM) += hamoa-iot-evk.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq5018-rdp432-c2.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq5018-tplink-archer-ax55-v1.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq5332-rdp441.dtb
> > > diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..843f39c9d59286a9303a545411b2518d7649a059
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> > > [...]
> > > + 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;
> > > + };
> > > +
> > > + /*
> > > + * TODO: These two regulators are actually part of the removable M.2
> > > + * card and not the CRD mainboard. Need to describe this differently.
> > > + * Functionally it works correctly, because all we need to do is to
> > > + * turn on the actual 3.3V supply above.
> > > + */
> > > + vreg_wcn_0p95: regulator-wcn-0p95 {
> > > + compatible = "regulator-fixed";
> > > +
> > > + regulator-name = "VREG_WCN_0P95";
> > > + regulator-min-microvolt = <950000>;
> > > + regulator-max-microvolt = <950000>;
> > > +
> > > + vin-supply = <&vreg_wcn_3p3>;
> > > + };
> > > +
> > > + vreg_wcn_1p9: regulator-wcn-1p9 {
> > > + compatible = "regulator-fixed";
> > > +
> > > + regulator-name = "VREG_WCN_1P9";
> > > + regulator-min-microvolt = <1900000>;
> > > + regulator-max-microvolt = <1900000>;
> > > +
> > > + vin-supply = <&vreg_wcn_3p3>;
> > > + };
> >
> > Like the TODO comment already says, regulators located on a M.2 card
> > shouldn't be described as part of the device DT. We need a proper
> > solution for modelling the M.2 slots together with the standard power
> > supplies (3.3V and 1.8V) and hook this up to the pwrseq subsystem. This
> > is also the reason why the CRD does not have Bluetooth enabled upstream
> > yet, this needs to be solved first.
> >
> > As far as I know, there is no one actively working on addressing this at
> > the moment. Perhaps you can assign someone at QC to work on solving this
> > upstream.
>
> This power section is now managed by UEFI, rendering these regulator nodes
> unnecessary. Therefore, I will remove them in the next version.
No. The regulators for the M.2 slot should be present here so that Linux
doesn't disable them. Which triggers a question: how are they
controlled? I don't see a GPIO line there.
>
> >
> > Thanks,
> > Stephan
>
> --
> Best Regards,
> Yijie
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists