Comment 53 for bug 1275794

(In reply to comment #31)
> Jani and I had a conversation about this not-so-very-long ago.
> Unfortunately, the spec is rather vague on the details of AUX_DEFERs.
> There's a little bit more information in there for I2C-over-AUX behavior,
> but nothing directly about native AUX_DEFERs as far as retry timeouts go.
> Essentially the spec just says "the source device can try again later" and
> leaves it at that. There's also an instance in the spec that says "assumes
> the Source repeats request immediately following a DP Sink AUX Defer
> response". Nothing like consistency...
>
> That said, I would think that up to 300us would be a safe value for a retry
> timeout.

I've raised and tested the udelay() from 100 to 300. It doesn't work reliable, especially when replugging the dp connector. But, a value of 500 did.

> That should be fine for isolated DEFERs or even a short series of
> them. However, lots of defers with a timeout value like this can stretch AUX
> operations out beyond specified specified time limits (10ms for link
> training for instance), so that's something to keep in mind.

Just for my understanding:
- What are isolated DEFERs?
- Is such a docking station nothing more than an active DP adapter?