On 07/22/14 22:22, Nick Hudson wrote:
On 07/22/14 18:46, Paul Zimmerman wrote:
The nak_frame handling would have added some benefit, but wouldn't
handle all
cases.
I'm seeing problems with devices NAKing to the point of confusing
dwc2 completely,
so I'd like to investigate a NAK holdoff scheme that's acceptable
for dwc2. I
suspect the best thing to do here is to add a nak_count field to
dwc2_qh (or maybe
dwc2_qtd) and increment in dwc2_hc_nak_intr. If the count exceeds a
threshold
then it would call
dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_NAK);
and go around again.
I assume the NAK count would need resetting everywhere
qtd->error_count is reset.
How does this sound?
Sounds good to me. BTW, can you give me a pointer to one of the devices
that gives excessive NAKs? I would like to buy one for the lab here to
test with.
I'm seeing problems with a d-link dwcl-g122 wifi dongle that someone
sent me.
The attached patch helps with my d-link dwl-g122 - it's adapted from the
raspberry pi dwc_otg driver.
I'm not sure the NYET/NAK/ACK/other case and would happily remove it.
I assume the scheduler is doing something that is confusing the core
with this particular device. The error recovery is still valid I think.
Nick
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 47b9eb5..5de7b58 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -1890,12 +1890,21 @@ static void dwc2_hc_chhltd_intr_dma(struct dwc2_hsotg *hsotg,
"hcint 0x%08x, intsts 0x%08x\n",
chan->hcint,
readl(hsotg->regs + GINTSTS));
+ goto error;
}
}
} else {
dev_info(hsotg->dev,
"NYET/NAK/ACK/other in non-error case, 0x%08x\n",
chan->hcint);
+error:
+
+ /* Failthrough: use 3-strikes rule */
+ qtd->error_count++;
+ dwc2_update_urb_state_abn(hsotg, chan, chnum, qtd->urb,
+ qtd, DWC2_HC_XFER_XACT_ERR);
+ dwc2_hcd_save_data_toggle(hsotg, chan, chnum, qtd);
+ dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_XACT_ERR);
}
}
