Re: EHCI split transaction question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Apr 2010, Sarah Sharp wrote:

> 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.

I don't see any point in doing this.  In general, a STALL response to a
Complete Split means that the FS/LS device sent a STALL.  So why try to
do the same transfer over again?

>  - 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.

By the same reasoning, there's no point doing this either.

> Which does EHCI do?

When you say "EHCI", do you really mean "ehci-hcd"?  EHCI (that is, the 
controller hardware) doesn't do anything to recover from STALLs.

ehci-hcd doesn't follow either of these courses.  It simply completes
the URB with a -EPIPE error.

>  I looked at qh_completions() in ehci-q.c, and it

Note that qh_completions handles Control, Bulk, and Interrupt transfers 
but not Isochronous transfers.

> seems like it always clears the TT (except in the case of a stall, which

This happens only for Control and Bulk transfers, not for Interrupt.

> was an interesting thread to read about).  So am I correct in thinking
> the EHCI driver always does a "hard retry"?

Nope.  It doesn't retry at all.

Alan Stern

--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux