Re: [PATCH 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Fri, Jul 18, 2025 at 12:27:34PM +0300, Dmitry Baryshkov wrote:
> 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@oss.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.
> 

The 0.95V and 1.9V regulators are located on the inserted M.2 *card* and
get automatically enabled by the 3.3V supply of the M.2 *slot*. If you
remove the card or insert a different one, they won't be present. This
is why they shouldn't be part of the DT. The M.2 slot only has a 3.3V
supply and a 1.8V supply.

The only reason why they are here is that the current bindings for the
WCN7850 require describing the whole PMU and internal regulators of the
M.2 card. Ideally, we should have a generic description for the M.2
slot/connector instead.

Thanks,
Stephan