Issue: Adding a dTD to a Primed Endpoint May Not Get Recognized with revision 2.20a. There is an issue with the add dTD tripwire semaphore (ATDTW bit in USBCMD register) that can cause the controller to ignore a dTD that is added to a primed endpoint. When this happens, the software can read the tripwire bit and the status bit at '1' even though the endpoint is unprimed. This issue observed with the Windows host machine. Workaround: The software must implement a periodic cycle, and check for each dTD pending on execution (Active = 1), if the endpoint is primed. It can do this by reading the corresponding bits in the ENDPTPRIME and ENDPTSTAT registers. If these bits are read at 0, the software needs to re-prime the endpoint by writing 1 to the corresponding bit in the ENDPTPRIME register. Added conditional revision check of 2.20[CI_REVISION_22] along with 2.40. Signed-off-by: Piyush Mehta <piyush.mehta@xxxxxxx> Acked-by: Peter Chen <peter.chen@xxxxxxxxxx> --- Change in V2: - Addressed the Peter review comment - Update the subject line. - Added Peter Ack in patch as Acked-by. - Switch to new @amd.com to AMD/Xilinx acquisition. Link: https://lore.kernel.org/all/1629825378-8089-7-git-send-email-manish.narani@xxxxxxxxxx --- drivers/usb/chipidea/udc.c | 3 ++- drivers/usb/chipidea/udc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 0b7bd3c643c3..2d7f616270c1 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -688,7 +688,8 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq) if ((TD_STATUS_ACTIVE & tmptoken) != 0) { int n = hw_ep_bit(hwep->num, hwep->dir); - if (ci->rev == CI_REVISION_24) + if (ci->rev == CI_REVISION_24 || + ci->rev == CI_REVISION_22) if (!hw_read(ci, OP_ENDPTSTAT, BIT(n))) reprime_dtd(ci, hwep, node); hwreq->req.status = -EALREADY; -- 2.25.1
