* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 16:36 [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B Sebastian Reichel
@ 2024-12-10 22:10 ` FUKAUMI Naoki
2024-12-10 22:41 ` FUKAUMI Naoki
2024-12-10 23:08 ` Sebastian Reichel
2024-12-11 0:06 ` FUKAUMI Naoki
2025-03-01 12:38 ` Andy Yan
2 siblings, 2 replies; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-10 22:10 UTC (permalink / raw)
To: Sebastian Reichel, Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-rockchip,
devicetree, linux-kernel, linux-arm-kernel, kernel
Hi Sebastian,
Thank you very much for your work!
$ cat
/sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
1500000
1500000
1
USB
C [PD] PD_PPS
20000000
20000000
20000000
$ cat
/sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
5000000
5000000
1
USB
C PD [PD_PPS]
20000000
20000000
20000000
$ ls /sys/class/udc/
fc000000.usb
I can configure it as CDC-NCM and host detects it.
But I could not use it as a HOST port. How to use it?
some minor nitpick is below:
On 12/11/24 01:36, Sebastian Reichel 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.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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";
typec_vin by schematic.
> + 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>;
typec_vin.
> };
>
> 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 {
Is "usbc0" label necessary?
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbc0_int>;
cc_int_l by schematic.
> + vbus-supply = <&vcc12v_dcin>;
typec_vin
> + /*
> + * 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.
... resets "the" whole board.
> + */
> + status = "fail";
> +
> + usb_con: connector {
Is "usb_con" label necessary?
> + 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 {
cc_int_l
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> + 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";
> };
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 22:10 ` FUKAUMI Naoki
@ 2024-12-10 22:41 ` FUKAUMI Naoki
2024-12-10 23:08 ` Sebastian Reichel
1 sibling, 0 replies; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-10 22:41 UTC (permalink / raw)
To: Sebastian Reichel, Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-rockchip,
devicetree, linux-kernel, linux-arm-kernel, kernel
Hi,
two correction,
On 12/11/24 07:10, FUKAUMI Naoki wrote:
> Hi Sebastian,
>
> Thank you very much for your work!
>
> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/
> {current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
> 1500000
> 1500000
> 1
> USB
> C [PD] PD_PPS
> 20000000
> 20000000
> 20000000
>
> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/
> {current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
> 5000000
> 5000000
> 1
> USB
> C PD [PD_PPS]
> 20000000
> 20000000
> 20000000
>
> $ ls /sys/class/udc/
> fc000000.usb
>
> I can configure it as CDC-NCM and host detects it.
> But I could not use it as a HOST port. How to use it?
>
> some minor nitpick is below:
>
> On 12/11/24 01:36, Sebastian Reichel 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.
>>
>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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";
>
> typec_vin by schematic.
>
>> + 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>;
>
> typec_vin.
>
>> };
>> 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 {
>
> Is "usbc0" label necessary?
please ignore, I noticed it's necessary for my work ;)
>
>> + compatible = "fcs,fusb302";
>> + reg = <0x22>;
>> + interrupt-parent = <&gpio3>;
>> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usbc0_int>;
>
> cc_int_l by schematic.
>
>> + vbus-supply = <&vcc12v_dcin>;
>
> typec_vin
>
>> + /*
>> + * 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.
>
> ... resets "the" whole board.
>
>> + */
>> + status = "fail";
>> +
>> + usb_con: connector {
>
> Is "usb_con" label necessary?
it's necessary for my work, but I think "usbc0_con" is consistent with
others.
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
>> + 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 {
>
> cc_int_l
>
> Best regards,
>
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
>
>> + 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";
>> };
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 22:10 ` FUKAUMI Naoki
2024-12-10 22:41 ` FUKAUMI Naoki
@ 2024-12-10 23:08 ` Sebastian Reichel
2024-12-11 0:04 ` FUKAUMI Naoki
1 sibling, 1 reply; 12+ messages in thread
From: Sebastian Reichel @ 2024-12-10 23:08 UTC (permalink / raw)
To: FUKAUMI Naoki
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rockchip, devicetree, linux-kernel, linux-arm-kernel,
kernel
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
Hello Naoki,
On Wed, Dec 11, 2024 at 07:10:55AM +0900, FUKAUMI Naoki wrote:
> Hi Sebastian,
>
> Thank you very much for your work!
>
> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
> 1500000
> 1500000
> 1
> USB
> C [PD] PD_PPS
> 20000000
> 20000000
> 20000000
>
> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
> 5000000
> 5000000
> 1
> USB
> C PD [PD_PPS]
> 20000000
> 20000000
> 20000000
>
> $ ls /sys/class/udc/
> fc000000.usb
>
> I can configure it as CDC-NCM and host detects it.
> But I could not use it as a HOST port. How to use it?
You can switch between host and peripheral for Type-C ports like
this depending on the remote sides capabilities:
* echo host > /sys/class/typec/<port>/data_role
* echo device > /sys/class/typec/<port>/data_role
I tested this with a USB-C hub connected to the port, which works
in host mode.
> some minor nitpick is below:
>
> On 12/11/24 01:36, Sebastian Reichel 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.
> >
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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";
>
> typec_vin by schematic.
Ack. Will update in v2.
> > + 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>;
>
> typec_vin.
>
> > };
> > 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 {
>
> Is "usbc0" label necessary?
no, but does it hurt?
> > + compatible = "fcs,fusb302";
> > + reg = <0x22>;
> > + interrupt-parent = <&gpio3>;
> > + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&usbc0_int>;
>
> cc_int_l by schematic.
Ack. I intentionally switched away from this naming, since cc prefix
is imho a way worse prefix than usbc0. The _l suffix just means
active low, which is already encoded in DT.
But I don't have a strong opinion and can fix this in v2.
> > + vbus-supply = <&vcc12v_dcin>;
>
> typec_vin
>
> > + /*
> > + * 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.
>
> ... resets "the" whole board.
Ack.
>
> > + */
> > + status = "fail";
> > +
> > + usb_con: connector {
>
> Is "usb_con" label necessary?
No. It should either be changed to "usbc0_con" or removed. In
general I tend to add some labels when they might be needed by
something in the future. They are more or less free anyways.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 23:08 ` Sebastian Reichel
@ 2024-12-11 0:04 ` FUKAUMI Naoki
0 siblings, 0 replies; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-11 0:04 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rockchip, devicetree, linux-kernel, linux-arm-kernel,
kernel
Hi Sebastian,
On 12/11/24 08:08, Sebastian Reichel wrote:
> Hello Naoki,
>
> On Wed, Dec 11, 2024 at 07:10:55AM +0900, FUKAUMI Naoki wrote:
>> Hi Sebastian,
>>
>> Thank you very much for your work!
>>
>> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
>> 1500000
>> 1500000
>> 1
>> USB
>> C [PD] PD_PPS
>> 20000000
>> 20000000
>> 20000000
>>
>> $ cat /sys/class/power_supply/tcpm-source-psy-4-0022/{current_max,current_now,online,type,usb_type,voltage_max,voltage_min,voltage_now}
>> 5000000
>> 5000000
>> 1
>> USB
>> C PD [PD_PPS]
>> 20000000
>> 20000000
>> 20000000
>>
>> $ ls /sys/class/udc/
>> fc000000.usb
>>
>> I can configure it as CDC-NCM and host detects it.
>> But I could not use it as a HOST port. How to use it?
>
> You can switch between host and peripheral for Type-C ports like
> this depending on the remote sides capabilities:
>
> * echo host > /sys/class/typec/<port>/data_role
> * echo device > /sys/class/typec/<port>/data_role
thanks!
I tested both data_role and both orientation. all works.
> I tested this with a USB-C hub connected to the port, which works
> in host mode.
>
>> some minor nitpick is below:
>>
>> On 12/11/24 01:36, Sebastian Reichel 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.
>>>
>>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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";
>>
>> typec_vin by schematic.
>
> Ack. Will update in v2.
>
>>> + regulator-always-on;
>>> + regulator-boot-on;
>>> + regulator-min-microvolt = <12000000>;
>>> + regulator-max-microvolt = <12000000>;
both microvolt line can be removed.
>>> + };
>>> +
>>> 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>;
>>
>> typec_vin.
>>
>>> };
>>> 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 {
>>
>> Is "usbc0" label necessary?
>
> no, but does it hurt?
sorry, please keep it.
>>> + compatible = "fcs,fusb302";
>>> + reg = <0x22>;
>>> + interrupt-parent = <&gpio3>;
>>> + interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&usbc0_int>;
>>
>> cc_int_l by schematic.
>
> Ack. I intentionally switched away from this naming, since cc prefix
> is imho a way worse prefix than usbc0. The _l suffix just means
> active low, which is already encoded in DT.
>
> But I don't have a strong opinion and can fix this in v2.
>
>>> + vbus-supply = <&vcc12v_dcin>;
>>
>> typec_vin
>>
>>> + /*
>>> + * 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.
>>
>> ... resets "the" whole board.
>
> Ack.
>
>>
>>> + */
>>> + status = "fail";
>>> +
>>> + usb_con: connector {
>>
>> Is "usb_con" label necessary?
>
> No. It should either be changed to "usbc0_con" or removed. In
> general I tend to add some labels when they might be needed by
> something in the future. They are more or less free anyways.
+1 for "usbc0_con".
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> -- Sebastian
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 16:36 [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B Sebastian Reichel
2024-12-10 22:10 ` FUKAUMI Naoki
@ 2024-12-11 0:06 ` FUKAUMI Naoki
2024-12-11 0:40 ` FUKAUMI Naoki
2025-03-01 12:38 ` Andy Yan
2 siblings, 1 reply; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-11 0:06 UTC (permalink / raw)
To: Sebastian Reichel, Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-rockchip,
devicetree, linux-kernel, linux-arm-kernel, kernel
Sorry, I forgot to write one thing...
On 12/11/24 01:36, Sebastian Reichel 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.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> ---
> .../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";
> };
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-11 0:06 ` FUKAUMI Naoki
@ 2024-12-11 0:40 ` FUKAUMI Naoki
2024-12-12 19:20 ` Sebastian Reichel
0 siblings, 1 reply; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-11 0:40 UTC (permalink / raw)
To: Sebastian Reichel, Heiko Stuebner
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-rockchip,
devicetree, linux-kernel, linux-arm-kernel, kernel
Hi Sebastian,
Sorry for many emails...
I got random reboot during booting kernel/userland...
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
On 12/11/24 09:06, FUKAUMI Naoki wrote:
> Sorry, I forgot to write one thing...
>
> On 12/11/24 01:36, Sebastian Reichel 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.
>>
>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>
> Tested-by: FUKAUMI Naoki <naoki@radxa.com>
>
> --
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.
>
>> ---
>> .../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";
>> };
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-11 0:40 ` FUKAUMI Naoki
@ 2024-12-12 19:20 ` Sebastian Reichel
2024-12-15 1:44 ` FUKAUMI Naoki
0 siblings, 1 reply; 12+ messages in thread
From: Sebastian Reichel @ 2024-12-12 19:20 UTC (permalink / raw)
To: FUKAUMI Naoki
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rockchip, devicetree, linux-kernel, linux-arm-kernel,
kernel
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi Naoki,
On Wed, Dec 11, 2024 at 09:40:13AM +0900, FUKAUMI Naoki wrote:
> I got random reboot during booting kernel/userland...
That is probably related to USB-C PD communication resulting in
another hard reset :( Can you try to get some tcpm_log() data
from debugfs while the board is powered from the GPIO header or
PoE?
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-12 19:20 ` Sebastian Reichel
@ 2024-12-15 1:44 ` FUKAUMI Naoki
0 siblings, 0 replies; 12+ messages in thread
From: FUKAUMI Naoki @ 2024-12-15 1:44 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rockchip, devicetree, linux-kernel, linux-arm-kernel,
kernel
Hi Sebastian,
On 12/13/24 04:20, Sebastian Reichel wrote:
> Hi Naoki,
>
> On Wed, Dec 11, 2024 at 09:40:13AM +0900, FUKAUMI Naoki wrote:
>> I got random reboot during booting kernel/userland...
>
> That is probably related to USB-C PD communication resulting in
> another hard reset :( Can you try to get some tcpm_log() data
> from debugfs while the board is powered from the GPIO header or
> PoE?
Unfortunately I don't have such a tool...
Best regards,
--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.
> Greetings,
>
> -- Sebastian
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:[PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2024-12-10 16:36 [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B Sebastian Reichel
2024-12-10 22:10 ` FUKAUMI Naoki
2024-12-11 0:06 ` FUKAUMI Naoki
@ 2025-03-01 12:38 ` Andy Yan
2025-03-01 22:42 ` [PATCH " Sebastian Reichel
2 siblings, 1 reply; 12+ messages in thread
From: Andy Yan @ 2025-03-01 12:38 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
FUKAUMI Naoki, linux-rockchip, devicetree, linux-kernel,
linux-arm-kernel, kernel
Hi Sebastian,
At 2024-12-11 00:36:01, "Sebastian Reichel" <sebastian.reichel@collabora.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。
>
>Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2025-03-01 12:38 ` Andy Yan
@ 2025-03-01 22:42 ` Sebastian Reichel
2025-03-02 7:56 ` Andy Yan
0 siblings, 1 reply; 12+ messages in thread
From: Sebastian Reichel @ 2025-03-01 22:42 UTC (permalink / raw)
To: Andy Yan
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
FUKAUMI Naoki, linux-rockchip, devicetree, linux-kernel,
linux-arm-kernel, kernel
[-- Attachment #1: Type: text/plain, Size: 6883 bytes --]
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@collabora.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@collabora.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
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re:Re: [PATCH v1 1/1] arm64: dts: rockchip: Add USB-C support to ROCK 5B
2025-03-01 22:42 ` [PATCH " Sebastian Reichel
@ 2025-03-02 7:56 ` Andy Yan
0 siblings, 0 replies; 12+ messages in thread
From: Andy Yan @ 2025-03-02 7:56 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
FUKAUMI Naoki, linux-rockchip, devicetree, linux-kernel,
linux-arm-kernel, kernel
Hello Sebastian,
At 2025-03-02 06:42:51, "Sebastian Reichel" <sebastian.reichel@collabora.com> wrote:
>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@collabora.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 :/
Yes, I have observed similar issues on Rock5B with a USB-C hub as well.
Even after upgrading U-Boot to version v2025.01 and applying your new tcpm patch,
the system still requires three to four automatic resets before successful boot-up once。
Thank you for your clarification and thank you for your work.
>
>Greetings,
>
>-- Sebastian
>
>>
>> >
>> >Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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
>> >
^ permalink raw reply [flat|nested] 12+ messages in thread