From: Yijie Yang <yijie.yang@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board
Date: Fri, 1 Aug 2025 09:48:10 +0800 [thread overview]
Message-ID: <31b03c1b-513a-4eae-9233-568aab12e0c8@oss.qualcomm.com> (raw)
In-Reply-To: <mlbutlxudl5i32zrqegxiefaa2sbkntriwdftn7hxo4khidtf2@oiljtmtktovu>
On 2025-08-01 04:22, Dmitry Baryshkov wrote:
> On Thu, Jul 31, 2025 at 04:45:33PM +0800, Yijie Yang wrote:
>>
>>
>> On 2025-07-31 02:42, Dmitry Baryshkov wrote:
>>> On Wed, Jul 30, 2025 at 02:28:25PM +0800, Yijie Yang wrote:
>>>>
>>>>
>>>> On 2025-07-29 18:37, Dmitry Baryshkov wrote:
>>>>> On Tue, Jul 29, 2025 at 09:32:00AM +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
>>>>>> - USB DisplayPorts
>>>>>>
>>>
>>>
>>>>>> + vreg_rtmr0_1p15: regulator-rtmr0-1p15 {
>>>>>
>>>>> Hmm, so there are regulators for the retimer, but they are not used.
>>>>> Could you please point out, why?
>>>>
>>>> According to the schematic, there is a regulator and a retimer (PS8830).
>>>> However, as mentioned above, the retimer is not connected to USB 0 and is
>>>> therefore not used in the EVK. As a result, the regulator is left unused in
>>>> this context.
>>>
>>> What is connected to the retimer then?
>>
>> All data lines are broken, except for some power lines.
>
> Ok. please add a comment. If the retimer is connected to I2C bus, please
> define it too.
It’s not connected to I2C. I will add a comment here.
>
>>
>>>
>>>>
>>>>>
>>>>>> + compatible = "regulator-fixed";
>>>>>> +
>>>
>>> [...]
>>>
>>>>>> +
>>>>>> + usb_1_ss0_sbu_default: usb-1-ss0-sbu-state {
>>>>>> + mode-pins {
>>>>>> + pins = "gpio166";
>>>>>> + function = "gpio";
>>>>>> + bias-disable;
>>>>>> + drive-strength = <2>;
>>>>>> + output-high;
>>>>>
>>>>> What does this pin do? It's not recommended to set GPIO values through
>>>>> pinctrl.
>>>>
>>>> It is used to switch data lines between USB Type-C orientation detection and
>>>> DisplayPort AUX channels.
>>>
>>> I don't think I follow it here. Which data lines? Type-C orientation
>>> detection uses CC1 / CC2, DP AUX use SBU lines.
>>
>> I made a mistake here — this pin switches between two data sources: one is
>> DP AUX, and the other is a GPIO pair configured with the function
>> usb0_sbrx/usb0_sbtx. Both data sources originate from the SoC and are routed
>> to the USB0_SBU1 and USB0_SBU2 lines of the USB Type-C connector.
>
> So, it's some USB4 stuff. Ideally it should be described via the
> gpio-sbu-mux, but I don't think we can do that for now. I'd let Bjorn,
> Konrad or Abel comment on this.
Sure.
>
>>
>>>
>>>> When this GPIO is high, USB0 operates in
>>>> orientation detection mode.
>>>
>>> What does this mean?
>>
>> This means the switch will select the GPIO pair configured as
>> usb0_sbrx/usb0_sbtx.
>>
>>>
>>>>
>>>>>
>>>>>> + };
>>>>>> +
>>>>>> + oe-n-pins {
>>>>>> + pins = "gpio168";
>>>>>> + function = "gpio";
>>>>>> + bias-disable;
>>>>>> + drive-strength = <2>;
>>>>>> + };
>>>>>> +
>>>>>> + sel-pins {
>>>>>> + pins = "gpio167";
>>>>>> + function = "gpio";
>>>>>> + bias-disable;
>>>>>> + drive-strength = <2>;
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + wcn_bt_en: wcn-bt-en-state {
>>>>>> + pins = "gpio116";
>>>>>> + function = "gpio";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-disable;
>>>>>> + };
>>>>>> +
>>>>>> + wwan_sw_en: wwan-sw-en-state {
>>>>>> + pins = "gpio221";
>>>>>> + function = "gpio";
>>>>>> + drive-strength = <4>;
>>>>>> + bias-disable;
>>>>>> + };
>>>>>> +
>>>>>> + wcn_sw_en: wcn-sw-en-state {
>>>>>> + pins = "gpio214";
>>>>>> + function = "gpio";
>>>>>> + drive-strength = <2>;
>>>>>> + bias-disable;
>>>>>> + };
>>>>>> +
>>>>>> + wcn_usb_sw_n: wcn-usb-sw-n-state {
>>>>>
>>>>> What does this pin do? Using pinctrl to set GPIO values is not
>>>>> recommended AFAIR.
>>>>
>>>> This pin functions similarly to usb-1-ss0-sbu-state; it controls the data
>>>> switch between signals from the USB connector and WLAN data.
>>>
>>> Could you please explain it? Does it toggle USB2 signals(you've added it
>>> to the USB2 PHY) being routed either to the USB connector or to the WiFi
>>> card? Or do you mean something else?
>>
>> Yes, that's right. It routes signals between the USB connector and the M.2
>> Wi-Fi card.
>
> Ack. Please add a comment.
Sure, I will.
>
>>
>>>
>>>>>> +&usb_2_hsphy {
>>>>>> + phys = <&eusb5_repeater>;
>>>>>> +
>>>>>> + pinctrl-0 = <&wcn_usb_sw_n>;
>>>>>> + pinctrl-names = "default";
>>>>>> +};
>>>>>> +
>>>>>> +&usb_mp_hsphy0 {
>>>>>> + phys = <&eusb6_repeater>;
>>>>>> +};
>>>>>> +
>>>>>> +&usb_mp_hsphy1 {
>>>>>> + phys = <&eusb3_repeater>;
>>>>>> +};
>>>>>>
>>>>>> --
>>>>>> 2.34.1
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Yijie
>>>>
>>>
>>
>> --
>> Best Regards,
>> Yijie
>>
>
--
Best Regards,
Yijie
next prev parent reply other threads:[~2025-08-01 1:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 1:31 [PATCH v3 0/4] Initial support for Qualcomm Hamoa IOT EVK board Yijie Yang
2025-07-29 1:31 ` [PATCH v3 1/4] dt-bindings: arm: qcom: Document HAMOA-IOT-EVK board Yijie Yang
2025-07-30 7:14 ` Krzysztof Kozlowski
2025-07-29 1:31 ` [PATCH v3 2/4] firmware: qcom: scm: Allow QSEECOM on HAMOA-IOT-EVK Yijie Yang
2025-07-29 1:31 ` [PATCH v3 3/4] arm64: dts: qcom: Add HAMOA-IOT-SOM platform Yijie Yang
2025-07-29 8:36 ` Konrad Dybcio
2025-07-29 10:44 ` Dmitry Baryshkov
2025-07-30 1:11 ` Yijie Yang
2025-07-30 6:44 ` Krzysztof Kozlowski
2025-07-30 7:13 ` Yijie Yang
2025-07-31 15:02 ` Krzysztof Kozlowski
2025-07-29 1:32 ` [PATCH v3 4/4] arm64: dts: qcom: Add base HAMOA-IOT-EVK board Yijie Yang
2025-07-29 5:51 ` Yijie Yang
2025-07-29 8:37 ` Konrad Dybcio
2025-07-29 9:39 ` Yingying Tang
2025-07-31 11:33 ` Konrad Dybcio
2025-07-29 10:37 ` Dmitry Baryshkov
2025-07-30 1:07 ` Yijie Yang
2025-07-30 6:28 ` Yijie Yang
2025-07-30 18:42 ` Dmitry Baryshkov
2025-07-31 8:45 ` Yijie Yang
2025-07-31 20:22 ` Dmitry Baryshkov
2025-08-01 1:48 ` Yijie Yang [this message]
2025-08-01 10:39 ` Konrad Dybcio
2025-08-01 17:54 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31b03c1b-513a-4eae-9233-568aab12e0c8@oss.qualcomm.com \
--to=yijie.yang@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®