[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23d10901-6b8a-41fb-8cb2-e8e361093561@quicinc.com>
Date: Tue, 2 Sep 2025 14:56:37 +0800
From: Yingying Tang <quic_yintang@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: 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
<yintang@....qualcomm.com>,
<miaoqing.pan@....qualcomm.com>,
"stone Zhang
(Stone)" <stonez@....qualcomm.com>,
<zhichen@....qualcomm.com>
Subject: Re: [PATCH v8 3/3] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
On 9/2/2025 10:37 AM, Dmitry Baryshkov wrote:
> On Mon, Sep 01, 2025 at 11:02:24AM +0800, Yingying Tang wrote:
>>
>>
>> On 8/28/2025 7:18 PM, Dmitry Baryshkov wrote:
>>> On Thu, Aug 28, 2025 at 12:48:47PM +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 the following peripherals on the carrier board:
>>>> - UART
>>>> - On-board regulators
>>>> - USB Type-C mux
>>>> - Pinctrl
>>>> - Embedded USB (EUSB) repeaters
>>>> - NVMe
>>>> - pmic-glink
>>>> - USB DisplayPorts
>>>> - Bluetooth
>>>> - Graphic
>>>> - 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>, and Yongxing Mou (USB DisplayPorts)
>>>> <quic_yongmou@...cinc.com>.
>>>>
>>>> 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 | 1247 ++++++++++++++++++++++++++++
>>>> 2 files changed, 1248 insertions(+)
>>>>
>>>> +
>>>> + wcd938x: audio-codec {
>>>> + compatible = "qcom,wcd9385-codec";
>>>> +
>>>> + pinctrl-0 = <&wcd_default>;
>>>> + pinctrl-names = "default";
>>>> +
>>>> + reset-gpios = <&tlmm 191 GPIO_ACTIVE_LOW>;
>>>> +
>>>> + qcom,micbias1-microvolt = <1800000>;
>>>> + qcom,micbias2-microvolt = <1800000>;
>>>> + qcom,micbias3-microvolt = <1800000>;
>>>> + qcom,micbias4-microvolt = <1800000>;
>>>> + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000
>>>> + 500000 500000 500000 500000>;
>>>
>>> Other platforms use a single line here. If you don't want to do it,
>>> align data to start from the same column rather than restarting from the
>>> column 1.
>>>
>>>> + qcom,mbhc-headset-vthreshold-microvolt = <1700000>;
>>>> + qcom,mbhc-headphone-vthreshold-microvolt = <50000>;
>>>> + qcom,rx-device = <&wcd_rx>;
>>>> + qcom,tx-device = <&wcd_tx>;
>>>> +
>>>> + vdd-buck-supply = <&vreg_l15b_1p8>;
>>>> + vdd-rxtx-supply = <&vreg_l15b_1p8>;
>>>> + vdd-io-supply = <&vreg_l15b_1p8>;
>>>> + vdd-mic-bias-supply = <&vreg_bob1>;
>>>> +
>>>> + #sound-dai-cells = <1>;
>>>> + };
>>>> +
>>>> + wcn7850-pmu {
>>>> + compatible = "qcom,wcn7850-pmu";
>>>> +
>>>> + vdd-supply = <&vreg_wcn_0p95>;
>>>> + vddio-supply = <&vreg_l15b_1p8>;
>>>> + vddaon-supply = <&vreg_wcn_0p95>;
>>>> + vdddig-supply = <&vreg_wcn_0p95>;
>>>> + vddrfa1p2-supply = <&vreg_wcn_1p9>;
>>>> + vddrfa1p8-supply = <&vreg_wcn_1p9>;
>>>> +
>>>> + bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
>>>
>>> Okay, so how is WiFi controlled? Is there a GPIO? The DT should be
>>> describing the hardware, not the UEFI behaviour.
>>>
>> Hi Dmitry, as I described in previous mail, On hamoa platfrom whole wifi module's power supply and enable gpio are voted in UEFI.
>> Hamoa is PC platform, so BIOS/UEFI behavior is compatible with Windows/ACPI architecture. UEFI is responsible for enabling power supply
>> for all devices which may be used in boot phase (such as WLAN may be used to boot from network).
>
> This is not completely relevant. You are describing driver / Linux /
> bootloader behaviour. I asked if there is a GPIO in the hardware. If
> there is one, please add it here.
Hi Dimitry,
During the UEFI boot phase, the WLAN enable GPIO has already been asserted, and the WLAN chip is functioning normally.
If we include this GPIO in the kernel device tree, when the kernel configures this GPIO, its voltage level may experience a brief glitch, which could cause the WLAN chip to reset and result in a PCIe link down.
So I didn't add wlan-en-gpio in this hamoa's device tree.
>
>>
>> So we need not Wifi chip's power and control GPIO in kernel side, thanks
>
> What if someone requests this GPIO from userspace and pulls it down?
>
>>>> +
>>>> + pinctrl-0 = <&wcn_bt_en>;
>>>> + pinctrl-names = "default";
>>>> +
>>>
>>
>
Powered by blists - more mailing lists