wb7: fix USB gadget high-speed enumeration (PHY TX tune)#361
Draft
evgeny-boger wants to merge 4 commits into
Draft
wb7: fix USB gadget high-speed enumeration (PHY TX tune)#361evgeny-boger wants to merge 4 commits into
evgeny-boger wants to merge 4 commits into
Conversation
The PHYs on Allwinner SoCs have a 5-bit TX tune field controlling the TX amplitude (2 bits) and slew rate (3 bits) of the line driver. The driver currently hardcodes the value inherited from the Allwinner BSP (minimum amplitude, slew rate 5), which on some boards results in a high-speed TX signal too weak for the link partner: on Wiren Board 7 (A40i/R40) devices the USB gadget fails to enumerate at high speed on several tested hosts and bulk data gets corrupted under load. Add optional per-PHY properties to tune the TX amplitude and slew rate. Signed-off-by: Evgeny Boger <boger@wirenboard.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The driver programs the PHY TX tune field (registers 0x20-0x24) with a fixed value of 0x14, inherited from the Allwinner BSP: TX amplitude tune 0 (the minimum) and slew rate tune 5. The minimum TX amplitude turns out to be insufficient for some host/device combinations at high speed. On Wiren Board 7 (A40i/R40) devices the USB gadget reliably fails to enumerate when connected directly to several tested laptop root ports: the HS chirp handshake succeeds and host SETUP packets are decoded fine, but the host never accepts the IN data stage, so enumeration retries forever while musb logs "SetupEnd came in a wrong ep0stage". With the amplitude raised to the maximum (3) enumeration succeeds, but bulk IN data still gets corrupted under load (>100 packet errors per second on the host side) until the slew rate tune is raised as well; with amplitude 3 and slew rate 7 the link is error-free over minutes-long saturated transfers. Add optional per-PHY devicetree properties to set the two TX tune fields, keeping the current values as defaults. Signed-off-by: Evgeny Boger <boger@wirenboard.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With the default TX tune (minimum amplitude, slew rate 5) the USB gadget fails to enumerate at high speed on several tested hosts when connected directly (without a hub): the host never receives the ep0 IN data stage. Even when enumeration succeeds, bulk IN data gets corrupted under load. Set both tune fields to maximum: validated error-free on WB 7.4.2 with 60+ s of saturated bidirectional iperf traffic. Also change the (currently unparsed) usb_otg maximum-speed cap from full-speed to high-speed to document that the FS workaround from #122 is no longer wanted. Signed-off-by: Evgeny Boger <boger@wirenboard.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
WB7 USB gadget reliably fails to enumerate at high speed when connected directly to some laptop root ports (no hub in between). The HS chirp handshake succeeds and host SETUP packets are decoded fine, but the host never accepts the ep0 IN data stage, so enumeration retries forever while musb floods dmesg with
SetupEnd came in a wrong ep0stage. Through most hubs enumeration works, masking the issue.This is the same marginality that #122 worked around by capping the gadget to full-speed — a cap that silently became a no-op on 6.x kernels (the 5.10-era
usb_get_maximum_speed()parsing in musb sunxi glue was lost in the rebase), which is why the failure resurfaced.Root cause
phy-sun4i-usbhardcodes the PHY TX tune field (regs 0x20-0x24) to the Allwinner BSP default0x14= minimum TX amplitude, slew rate 5. The resulting HS TX signal is too weak for some host receivers.Fix
allwinner,usbX-tx-amplitude(0-3) andallwinner,usbX-tx-slew-rate(0-7), defaults unchangedFirst two commits are upstream-shaped (bindings + driver), prepared for mainline submission as well.
Validation (WB 7.4.2, ALEPBSP3, direct connection to Latitude 9430 root port)
Deterministic A/B on live hardware via PHY tp-write:
Kernel built from this branch (6.18.22-wb6-usbtune, device config) — boots pending on-device deb verification.
Caveats
maximum-speed = "high-speed"dts change is currently unparsed (see above) and only documents intent.🤖 Generated with Claude Code