Fix/atcphy pipehandler#503
Conversation
| } | ||
| do { | ||
| set32(atcphy->regs.pipehandler + PIPEHANDLER_LOCK_REQ, PIPEHANDLER_LOCK_EN); | ||
| ret = readl_poll_timeout(atcphy->regs.pipehandler + PIPEHANDLER_LOCK_ACK, reg, |
There was a problem hiding this comment.
I've never seen macos do this in traces and I highly suspect we're doing something else that's wrong here. have you seen this in traces or is this something you worked out by just playing with the hardware?
There was a problem hiding this comment.
Mostly try and error. My use case is using an M1 air in clamshell mode with fedora remix server (low idle power compute node for my homelab). So I need an Ethernet adapter. While it works fine when Hot Plugging the adapter, it fails on reboot (no phy detected/initialised). This was a defensive retry code attempt that seemed to work. But I agree with you something else is going on. Further testing shows that it is not reliable and if I removed some debug traces it would change the timing and fail again. Will probably move this issue to the forum before making further changes. Need to also understand some iboot behaviour differences between m1 and newer chips and assumptions made for how long it takes to load necessary firmwares. Thanks for reviewing.
There was a problem hiding this comment.
yeah, that's what I was afraid of :( atcphy shouldn't have any firmware fwiw
There was a problem hiding this comment.
Yes but some usb hubs also have an external display (dcpext) which requires some lane allocation, initialisation and firmware (video modes). Not sure how all this is orchestrated to work in a generic way for typeC hubs in non-macOS and macOS systems. Any idea?
| * If the pipehandler is still up and the target mode uses the dummy PIPE | ||
| * state (DP, USB2, TBT, OFF), tear it down before reconfiguring the lanes. | ||
| * Normally atcphy_usb3_power_off() does this, but a TypeC mux switch to | ||
| * DP alt mode can race the DWC3 PHY teardown on hotplug. By the time the |
There was a problem hiding this comment.
how does this race actually happen? can you describe this in more detail?
the fix here may be correct but I want to be sure we can't fix this at another level (e.g. the type c controller)
…mode hotplug Five related fixes for the Type-C PHY on t8103: - Retry the pipehandler lock with backoff: the lock ACK is generated by the lane-0 RXDETECT state machine, which takes 150-688ms (measured on J313) to become responsive after PHY reset release. The single 1ms poll times out at boot and leaves the PHY unconfigured for the rest of the session. - Clear the RXVALID/RXDETECT overrides on lock failure so a transient timeout no longer suppresses receiver detection until the next full reconfigure. - Tear the pipehandler down in atcphy_mux_set() when a DP alt-mode switch races DWC3 phy_power_off() on hotplug, and scope the WARN to that case: modes that keep the USB3 PIPE state (pin assignment D) legitimately arrive with pipehandler_up set. - Configure the PHY for USB3 inline when xhci set_mode wins the race against tipd 500ms-debounced typec_mux_set and the PHY is still OFF. - Skip the host-mode BIST in the set_mode path: its RXDETECT override suppresses xhci link detection, so devices attached at power-on fail to enumerate when the first port scan lands inside that window. With all five applied, boot enumeration of a 4-device USB3 dock went from a coin flip to 14/15 on t8103/J313. Signed-off-by: milijan <milijan@users.noreply.github.com>
milijan
force-pushed
the
fix/atcphy-pipehandler
branch
from
cfca9fe to
87a2ad1
Compare
2 participants
Two fixes observed on J313 (M1 MacBook Air) with a USB-C multiport hub:
Retry pipehandler lock with backoff: Replace the single poll with up to 10 retries at 5–10 ms intervals (~100 ms total). Avoids having to hard cycle the usb-c connection.
Fix teardown race and spurious WARN on USB3_DP. Scope the WARN to the failure case only.
Tested on Fedora Asahi Remix 44, kernel 6.19.