On 13/01/2020 14:31, Tomi Valkeinen wrote:
Hi Andrzej,
On 09/12/2019 16:45, Andrey Smirnov wrote:
- Chris Healy
On Mon, Dec 9, 2019 at 12:27 AM Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Link training fails with:
Link training timeout waiting for LT_LOOPDONE! main link enable error: -110
This is caused by too tight timeouts, which were changed recently in aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()").
With a quick glance, the commit does not change the timeouts. However, the method of delaying/sleeping is different, and as the timeout in the previous implementation was not explicit, the new version in practice has much tighter timeout.
The same change was made to other parts in the driver, but the link training timeout is the only one I have seen causing issues. Nevertheless, 1 us sleep is not very sane, and the timeouts look pretty tight, so lets fix all the timeouts.
One exception was the aux busy poll, where the poll sleep was much longer than necessary (or optimal).
I measured the times on my setup, and now the sleep times are set to such values that they result in multiple loops, but not too many (say, 5-10 loops). The timeouts were all increased to 100ms, which should be more than enough for all of these, but in case of bad errors, shouldn't stop the driver as multi-second timeouts could do.
Signed-off-by: Tomi Valkeinen tomi.valkeinen@ti.com Fixes: aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()")
Tested on RDU2 with TC358767/eDP panel, doesn't seem to break anything there, so:
Tested-by: Andrey Smirnov andrew.smirnov@gmail.com
Andrzej, can you pick this up for -fixes?
Tomi
Reviewed-by: Neil Armstrong narmstrong@baylibre.com
Applied to drm-misc-fixes
Neil