Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757179AbcC2OFp (ORCPT ); Tue, 29 Mar 2016 10:05:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50582 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751724AbcC2OFm (ORCPT ); Tue, 29 Mar 2016 10:05:42 -0400 Message-ID: <1459260340.15060.0.camel@redhat.com> Subject: Re: [PATCH v4 RESEND 1/5] drm/dp_helper: Increase retry interval to 1000us From: Lyude Paul To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, arthur.j.runyan@intel.com, open list Date: Tue, 29 Mar 2016 10:05:40 -0400 In-Reply-To: <20160329082732.GL2510@phenom.ffwll.local> References: <1459175606-13875-1-git-send-email-cpaul@redhat.com> <1459175606-13875-2-git-send-email-cpaul@redhat.com> <20160329082732.GL2510@phenom.ffwll.local> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1644 Lines: 47 Yep, the rest of the patchset works fine without this patch On Tue, 2016-03-29 at 10:27 +0200, Daniel Vetter wrote: > On Mon, Mar 28, 2016 at 10:33:22AM -0400, Lyude wrote: > > > > This is part of a patch series to migrate all of the workarounds for > > commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to > > drm's DP helper. > > > > Signed-off-by: Lyude > > --- > >  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 7d58f59..d1128fb 100644 > > --- a/drivers/gpu/drm/drm_dp_helper.c > > +++ b/drivers/gpu/drm/drm_dp_helper.c > > @@ -160,7 +160,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw) > >  } > >  EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate); > >   > > -#define AUX_RETRY_INTERVAL 500 /* us */ > > +#define AUX_RETRY_INTERVAL 1000 /* us */ > Was this to adapt to the msleep(1) in the i915 function? If so it's kinda > wrong anyway, since an msleep(1) actually sleeps 1 jiffy, and on most > systems that's a lot more than 1 ms. If it all still works, I'd just drop > this patch here. I suspect that the magic is all in the more aggressive > retrying and the throwaway read, not in how long we actually wait. > > On patches 2-5: Reviewed-by: Daniel Vetter > > > > >   > >  /** > >   * DOC: dp helpers > > --  > > 2.5.5 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Lyude