On Wed, 26 Nov 2014, Dave Airlie <airlied@xxxxxxxxx> wrote:
> From: Dave Airlie <airlied@xxxxxxxxxx>
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
I think we have a bug with some dongle that defers a lot too. One idea
was to use a progressively longer delay for DP_AUX_NATIVE_REPLY_DEFER.
How about drm_dp_i2c_do_msg(), that one can receive native aux defer
too, along with i2c defer. It feels like both places should have the
same limit for native aux defer, but if you want to keep different i2c
defer retry limit it gets a bit trickier.
BR,
Jani.
>
> This fixes one Dell 4k monitor and one of the
> MST hubs.
>
> Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx>
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 959e207..db0993f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -189,7 +189,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> * retry native transactions, so retry 7 times like for I2C-over-AUX
> * transactions.
> */
> - for (retry = 0; retry < 7; retry++) {
> + for (retry = 0; retry < 32; retry++) {
>
> mutex_lock(&aux->hw_mutex);
> err = aux->transfer(aux, &msg);
> --
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
