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

On Fri, Aug 01, 2025 at 12:39:09PM +0200, Konrad Dybcio wrote:

On 8/1/25 3:48 AM, Yijie Yang wrote:

quoted

On 2025-08-01 04:22, Dmitry Baryshkov wrote:

quoted

On Thu, Jul 31, 2025 at 04:45:33PM +0800, Yijie Yang wrote:

quoted

On 2025-07-31 02:42, Dmitry Baryshkov wrote:

quoted

On Wed, Jul 30, 2025 at 02:28:25PM +0800, Yijie Yang wrote:

quoted

On 2025-07-29 18:37, Dmitry Baryshkov wrote:

quoted

On Tue, Jul 29, 2025 at 09:32:00AM +0800, Yijie Yang wrote:

quoted

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

quoted

quoted

quoted

+    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.

quoted

quoted

quoted

quoted

quoted

quoted

+        compatible = "regulator-fixed";
+

[...]

quoted

quoted

quoted

+
+    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.

There is no DT representation of USB4 hardware at the moment, feel
free to pretend it doesn't exist for now.

If we wanted to be hyper-correct, the way USB(3) is plugged into the
bigger picture isn't quite pristine either, but that's a story for
another day - need some puzzle pieces to come together first

Ack. Then the current description is fine.

-- 
With best wishes
Dmitry