Remove usb-role-switch property from fusb302 node and replace with
extcon property. The usb-role-switch property breaks PD negotiation
and DP alt mode on kernel 6.18+.
Fix based on PR #9245 (Pinebook Pro) by amazingfate.
Apply Helios64: fix Type-C PHY registration #9158 to 6.19.
Problem:
On Helios64 boot, the Type-C PHY (ff7c0000.phy) gets stuck in
"deferred probe" state with unknown reason. This causes:
- USB 3.0 SuperSpeed via Type-C port not working
- DisplayPort via Type-C (Alt Mode) not working
The following messages appear in dmesg:
platform ff7c0000.phy: deferred probe pending: (reason unknown)
platform fe800000.usb: deferred probe pending: wait for supplier /phy@ff7c0000/usb3-port
platform fec00000.dp: deferred probe pending: wait for supplier /phy@ff7c0000/dp-port
Along with dependency cycle warnings:
/phy@ff7c0000/dp-port: Fixed dependency cycle(s) with /i2c@ff3d0000/typec-portc@22/connector
Root cause:
The Helios64 DTS uses a legacy Type-C connection method:
&tcphy0 {
extcon = <&fusb0>; // Expects extcon from fusb302
};
However:
1. The FUSB302 driver with TCPM support (since kernel ~4.14) does NOT
create extcon devices
2. Instead, it uses the Type-C connector class (/sys/class/typec/)
3. The phy-rockchip-typec driver calls extcon_get_edev_by_phandle(),
fails to find an extcon device at the specified phandle, and
returns -EPROBE_DEFER
4. The PHY remains in deferred probe indefinitely
The extcon-cables property is present in the DTS, but without a
typec_extcon_bridge node it serves no purpose.
This bug has existed since Type-C support was added to Helios64
(at least since kernel 6.6). It likely worked with older fusb302
driver versions, but broke after the transition to TCPM.
Solution:
Use the typec-extcon-bridge driver (Armbian patch from Ondrej Jirman/megi)
which translates Type-C connector class events to the extcon interface.
The Pinebook Pro patch (board-pbp-add-dp-alt-mode.patch) implements this
correctly: it has a typec_extcon_bridge node, and all extcon references
point to it rather than directly to fusb0.
Changes:
1. Add typec_extcon_bridge node with compatible = "linux,typec-extcon-bridge"
2. Change extcon = <&fusb0> to extcon = <&typec_extcon_bridge> in
tcphy0, cdn_dp, u2phy0, usbdrd_dwc3_0 nodes
3. Add usb-role-switch, mode-switch, orientation-switch properties
to fusb0 connector for integration with the bridge
4. Update PDO definitions with DUAL_ROLE and DATA_SWAP flags
5. Convert typec-altmodes property to modern altmodes subnode format
(required for TCPM port registration)
6. Add extcon,ignore-usb to u2phy0 (following Pinebook Pro pattern)
7. Add snps,usb3-phy-reset-quirk to usbdrd_dwc3_0
After this fix:
- Type-C PHY (ff7c0000.phy) no longer stuck in deferred probe
- USB 3.0 SuperSpeed via Type-C port should work
- DisplayPort via Type-C (Alt Mode) should work
- Correct cable orientation detection
- USB role switching (host/device)
Known remaining issues:
- FUSB302 fails to register TCPM port with error:
4-0022 typec_fusb302: cannot register tcpm port
This prevents USB Power Delivery negotiation. The root cause
appears to be in the connector configuration and requires
further investigation.
- For 6.18 + 6.19
- mixtile-blade3: add 4-pin header fan at 40c
- mixtile-blade3: add gpu nodes
- mixtile-blade3: add vcc5v0-host-en "usb" pinctrl
- somehow results in 2 working RTL8169's behind the ASM1182e on pcie2x1l0
- which just means the _schematics lie_
- mixtile-blade3: drop rst pinctrl from pcie2x1l0 and pcie2x1l1
- this is me probably being stupid, but also required for working ASM1182e/RTL8169
- Status of this mainline port:
- Initially started by Joshua Riek (2023?)
- I then added some PCIe3x4 stuff, but never got around to finishing it
- Specifically, the 2 FUSB302's are beyond me for now
- One of them _powers_ the board. To use with mainline, power the board some other way with 12V, otherwise kaboom.
- See sre's talk on this issue; Blade3 should be similar to Rock-5b in this aspect.
- A challenge has been the PCI2x1 lanes to the miniPCIe and ASM1182e switch
- Which by themselves seem to work, but the devices behind them (Switch + RTL8169 NICs) do not get powered
- Until one day I tried to describe a (in theory) USB-related power pin, and suddenly both PCIe NICs started working!
- All that said, the board is really not stable with this; end-users are much better off with vendor kernel for now.
- Any and all help is appreciated. Those boards are nice, they've 2 FUSB302, and fancy PCIe Endpoint mode stuff.
- Schematics we have access to are in https://damwold5pt25n.cloudfront.net/blade3/file/Schematic_Blade_3_v1.1.0.pdf
- Those clearly lie.
- Add mainline device tree for YY3588 board
- Enable all peripherals: USB 3.0, Ethernet, PCIe, HDMI
- Add RK8602 PMIC regulators for CPU/NPU power
- Enable I2C buses for PMIC and RTC
- Fix pinctrl conflicts (I2C1 M2, disable SFC for UART7)
- Configure USB-C and USB 3.0 host ports
- Add HDMI0 output with HDPTX PHY
- Enable thermal management with PWM fan
- Add SD card and eMMC storage support
- Configure all UARTs, I2S audio, and SPI buses
- ES8323 audio codec currently disabled for further debugging
- vendor:
- kernel: armbian/linux-rockchip already had a DTS from jriek
- u-boot: taken from jriek (reorg'ed the defconfig)
- edge:
- kernel: taken from jriek's 6.11 wip branch
- u-boot: generic (can only boot SD/eMMC)
- straight-ish from vendor (which is a complete mess)
- front:
- blue ports work (in usb2.0 mode, which also happens in vendor kernel)
- black ports do NOT work (but are powered...?)
- back:
- white ports work in usb 2.0 mode (as expected, also in vendor kernel)
- those ports have too-long wires (flat cable) and reset all the time
- in summary: blue "USB3" ports at the front work in USB2.0 mode
- rest doesn't
- works: PCIe/NVMe, GMAC, Realtek DSA switch, SD, SPI-NOR
- does not work: USB (I didn't manage to pick correctly; lets wait for Kwiboo on this)
- untested: everything else
