[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17d1e632-31c9-48b2-bf0f-5b57234de113@quicinc.com>
Date: Tue, 16 Sep 2025 18:39:23 +0800
From: Yingying Tang <quic_yintang@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Dmitry Baryshkov
<dmitry.baryshkov@....qualcomm.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>, <zhichen@....qualcomm.com>
Subject: Re: [PATCH v11 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
On 9/16/2025 6:36 PM, Konrad Dybcio wrote:
> On 9/16/25 12:29 PM, 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"
>
> Surely gpio-regulator.c implements .get_voltage which reads the pin
> state though? Did you test this, or are you theorycrafting?
>
Yes we tested this case many times, "regulator-boot-on" causes PCIe link down. No any issue with "regulator-always-on"
> Konrad
>
Powered by blists - more mailing lists