I've been looking at how EHCI handles errors on split transactions. The case I'm interested in is when the host has successfully completed the Start Split and is attempting a Complete Split transfer. If an error occurs, like a babble or a stall, what does the EHCI driver do with the Complete Split transfer? The hardware guys have told me there's two ways software can recover from a stall on the Complete Split transfer: - a "hard retry" where software flushes the TT pipe, resets the endpoint, sets the splitXState in the QH to “start” and then sets the active bit in the QH to make the host controller retry the start split. - a "soft retry" where SW leaves the completion sitting in the TT, leaves splitXstate in the QH at “complete” and then sets the active bit in the QH to make the host controller retry the complete split. Which does EHCI do? I looked at qh_completions() in ehci-q.c, and it seems like it always clears the TT (except in the case of a stall, which was an interesting thread to read about). So am I correct in thinking the EHCI driver always does a "hard retry"? Sarah Sharp -- 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
