[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <njeivdzwyy6qxome77asapmi3a3l34mpauk366f6zgpt2mvorz@ra77f5vjd5lf>
Date: Sat, 1 Mar 2025 23:42:51 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Andy Yan <andyshrk@....com>
Cc: Heiko Stuebner <heiko@...ech.de>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
FUKAUMI Naoki <naoki@...xa.com>, linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
Hello Andy,
On Sat, Mar 01, 2025 at 08:38:01PM +0800, Andy Yan wrote:
> At 2024-12-11 00:36:01, "Sebastian Reichel" <sebastian.reichel@...labora.com> wrote:
> >Add hardware description for the USB-C port in the Radxa Rock 5 Model B.
> >This describes the OHCI, EHCI and XHCI USB parts, but not yet the
> >DisplayPort AltMode (bindings are not yet upstream).
> >
> >The fusb302 node is marked with status "fail", since the board is usually
> >powered through the USB-C port. Handling of errors can result in hard
> >resets, which removed the bus power for some time resulting in a board
> >reset.
> >
> >The main problem is that devices are supposed to interact with the
> >power-supply within 5 seconds after the plug event according to the
> >USB PD specification. This is more or less impossible to achieve when
> >the kernel is the first software communicating with the power-supply.
> >
> >Recent U-Boot (v2025.01) will start doing USB-PD communication, which
> >solves this issue. Upstream U-Boot doing USB-PD communication will also
> >set the fusb302 node status to "okay". That way booting a kernel with
> >the updated DT on an old U-Boot avoids a reset loop.
>
> Do you have any plans to continue working on this patch?
> I've been working on enabling the DP Alt Mode output recently
> and think the Rock 5b is a good starting point。
This is still on my radar. I recently send an updates U-Boot series
with some TCPM improvements:
https://lore.kernel.org/u-boot/20250226184506.64114-1-sebastian.reichel@collabora.com/
Even with that there are more issues resulting in hard resets
happening in some circumstances (if they are happening depends a lot
on the specific powre supply being used). I'm still looking for the
root cause of these. It's also hard to tell when it is a good time
to apply this patch. Some people will probably see a regression due
to using power-supplies diverging too far from the standard :/
Greetings,
-- Sebastian
>
> >
> >Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> >---
> > .../boot/dts/rockchip/rk3588-rock-5b.dts | 121 ++++++++++++++++++
> > 1 file changed, 121 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >index d597112f1d5b..cb5990df6ccb 100644
> >--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >@@ -5,6 +5,7 @@
> > #include <dt-bindings/gpio/gpio.h>
> > #include <dt-bindings/leds/common.h>
> > #include <dt-bindings/soc/rockchip,vop2.h>
> >+#include <dt-bindings/usb/pd.h>
> > #include "rk3588.dtsi"
> >
> > / {
> >@@ -84,6 +85,15 @@ rfkill-bt {
> > shutdown-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_HIGH>;
> > };
> >
> >+ vcc12v_dcin: regulator-vcc12v-dcin {
> >+ compatible = "regulator-fixed";
> >+ regulator-name = "vcc12v_dcin";
> >+ regulator-always-on;
> >+ regulator-boot-on;
> >+ regulator-min-microvolt = <12000000>;
> >+ regulator-max-microvolt = <12000000>;
> >+ };
> >+
> > vcc3v3_pcie2x1l0: regulator-vcc3v3-pcie2x1l0 {
> > compatible = "regulator-fixed";
> > enable-active-high;
> >@@ -142,6 +152,7 @@ vcc5v0_sys: regulator-vcc5v0-sys {
> > regulator-boot-on;
> > regulator-min-microvolt = <5000000>;
> > regulator-max-microvolt = <5000000>;
> >+ vin-supply = <&vcc12v_dcin>;
> > };
> >
> > vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
> >@@ -264,6 +275,67 @@ regulator-state-mem {
> > };
> > };
> >
> >+&i2c4 {
> >+ pinctrl-names = "default";
> >+ pinctrl-0 = <&i2c4m1_xfer>;
> >+ status = "okay";
> >+
> >+ usbc0: usb-typec@22 {
> >+ compatible = "fcs,fusb302";
> >+ reg = <0x22>;
> >+ interrupt-parent = <&gpio3>;
> >+ interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
> >+ pinctrl-names = "default";
> >+ pinctrl-0 = <&usbc0_int>;
> >+ vbus-supply = <&vcc12v_dcin>;
> >+ /*
> >+ * When the board is starting to send power-delivery messages
> >+ * too late (5 seconds according to the specification), the
> >+ * power-supply reacts with a hard-reset. That removes the
> >+ * power from VBUS for some time, which resets te whole board.
> >+ */
> >+ status = "fail";
> >+
> >+ usb_con: connector {
> >+ compatible = "usb-c-connector";
> >+ label = "USB-C";
> >+ data-role = "dual";
> >+ power-role = "sink";
> >+ try-power-role = "sink";
> >+ op-sink-microwatt = <1000000>;
> >+ sink-pdos =
> >+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>,
> >+ <PDO_VAR(5000, 20000, 5000)>;
> >+
> >+ ports {
> >+ #address-cells = <1>;
> >+ #size-cells = <0>;
> >+
> >+ port@0 {
> >+ reg = <0>;
> >+ usbc0_role_sw: endpoint {
> >+ remote-endpoint = <&dwc3_0_role_switch>;
> >+ };
> >+ };
> >+
> >+ port@1 {
> >+ reg = <1>;
> >+ usbc0_orien_sw: endpoint {
> >+ remote-endpoint = <&usbdp_phy0_orientation_switch>;
> >+ };
> >+ };
> >+
> >+ port@2 {
> >+ reg = <2>;
> >+ dp_altmode_mux: endpoint {
> >+ remote-endpoint = <&usbdp_phy0_dp_altmode_mux>;
> >+ };
> >+ };
> >+ };
> >+ };
> >+ };
> >+};
> >+
> > &i2c6 {
> > status = "okay";
> >
> >@@ -423,6 +495,10 @@ usb {
> > vcc5v0_host_en: vcc5v0-host-en {
> > rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
> > };
> >+
> >+ usbc0_int: usbc0-int {
> >+ rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
> >+ };
> > };
> > };
> >
> >@@ -835,6 +911,14 @@ &uart2 {
> > status = "okay";
> > };
> >
> >+&u2phy0 {
> >+ status = "okay";
> >+};
> >+
> >+&u2phy0_otg {
> >+ status = "okay";
> >+};
> >+
> > &u2phy1 {
> > status = "okay";
> > };
> >@@ -866,6 +950,29 @@ &usbdp_phy1 {
> > status = "okay";
> > };
> >
> >+&usbdp_phy0 {
> >+ mode-switch;
> >+ orientation-switch;
> >+ sbu1-dc-gpios = <&gpio4 RK_PA6 GPIO_ACTIVE_HIGH>;
> >+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> >+ status = "okay";
> >+
> >+ port {
> >+ #address-cells = <1>;
> >+ #size-cells = <0>;
> >+
> >+ usbdp_phy0_orientation_switch: endpoint@0 {
> >+ reg = <0>;
> >+ remote-endpoint = <&usbc0_orien_sw>;
> >+ };
> >+
> >+ usbdp_phy0_dp_altmode_mux: endpoint@1 {
> >+ reg = <1>;
> >+ remote-endpoint = <&dp_altmode_mux>;
> >+ };
> >+ };
> >+};
> >+
> > &usb_host0_ehci {
> > status = "okay";
> > };
> >@@ -874,6 +981,20 @@ &usb_host0_ohci {
> > status = "okay";
> > };
> >
> >+&usb_host0_xhci {
> >+ usb-role-switch;
> >+ status = "okay";
> >+
> >+ port {
> >+ #address-cells = <1>;
> >+ #size-cells = <0>;
> >+
> >+ dwc3_0_role_switch: endpoint {
> >+ remote-endpoint = <&usbc0_role_sw>;
> >+ };
> >+ };
> >+};
> >+
> > &usb_host1_ehci {
> > status = "okay";
> > };
> >--
> >2.45.2
> >
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists