On 11/28/25 2:16 PM, [email protected] wrote:
From: Ye Li <[email protected]>
When doing port reset, the PR bit of PORTSC1 will be automatically
cleared by our IP, but standard EHCI needs explicit clear by software.
The EHCI-HCD driver follow the EHCI specification, so after 50ms wait,
it clear the PR bit by writting to the PORTSC1 register with value
loaded before setting PR.
This sequence is ok for our IP when the delay time is exact. But when
the timer is slower
How can the timer be slower ? Maybe there is some bug somewhere else ?
, some bits like PE, PSPD have been set by controller
automatically after the PR is automatically cleared. So the writing to
the PORTSC1 will overwrite these bits set by controller. And eventually
the driver gets wrong status.
We implement the powerup_fixup operation which delays 50ms and will
check the PR until it is cleared by controller. And will update the reg
value which is written to PORTSC register by EHCI-HCD driver. This is
much safer than depending on the delay time to be accurate and aligining
with controller's behaiver.
Signed-off-by: Ye Li <[email protected]>
Signed-off-by: Alice Guo <[email protected]>
---
drivers/usb/host/ehci-mx6.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 25907f22612..0b3f1b69657 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -265,6 +265,25 @@ int usb_phy_mode(int port)
}
#endif
+static void ehci_mx6_powerup_fixup(struct ehci_ctrl *ctrl, uint32_t *status_reg,
+ uint32_t *reg)
+{
+ u32 result;
+ int usec = 2000;
+
+ mdelay(50);
+
+ do {
+ result = ehci_readl(status_reg);
+ udelay(5);
+ if (!(result & EHCI_PS_PR))
+ break;
+ usec--;
+ } while (usec > 0);
+
+ *reg = ehci_readl(status_reg);
+}
Can't the core EHCI code simply check whether PR is cleared already and
skip updating PORTSC if it is instead ?
