On Tue, 22 Jul 2014 18:46:27 +0100, Paul Zimmerman
<Paul.Zimmerman@xxxxxxxxxxxx> wrote:
From: Nick Hudson [mailto:skrll@xxxxxxxxxx]
Sent: Tuesday, July 22, 2014 12:19 AM
On 09/23/13 22:23, Paul Zimmerman wrote:
> Here is the third version of the microframe scheduler patch. This
> version removes the NAK holdoff patch from the series, since it
> was effectively a no-op as pointed out by Matthijs.
I think there was a misunderstanding here - Matthijs was pointing out
that the
next_sched_frame variable was unused. That particular variable is part
of the
downstream Pi driver's FIQ code.
Right, but without that, the patch didn't actually do anything as far as
I could see.
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.
All USB-serial dongles that use a simple bulk in/out FIFO endpoint
structure exhibit this behaviour.
A URB is submitted to the IN endpoint and it's effectively used to "poll"
the endpoint for data.
Typically the very large mismatch between the configured baud rate and the
full-speed bus transfer rate results in a lengthy sequence of NAKs
followed by the next byte received by the UART.
USB-serial devices manufactured by FTDI almost exclusively use this method
of transport.
FTDI ship several variants that package their FT232R USB-serial adapter:
bare board or with pigtail attached.
Note that the NAK holdoff is capable of being implemented without the FIQ
- in our implementation we add a parameter to the QH for the endpoint
(nak_frame) that records the last time this endpoint was polled for data.
An adjustable parameter changes the interval for considering QTDs in this
QH for execution (i.e. submission to the otg core) based on the microframe
number of the last nak_frame received.
In the case where FIQ support is not provided, then the SOF interrupt will
have to be unmasked as long as there are QHs with nak_frame set.
Regards
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
