From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Subject: Re: [PATCH 1/3] drm/dp: make aux retries less chatty Date: Wed, 19 Mar 2014 16:21:49 +0200 Message-ID: <87eh1yxo8y.fsf@intel.com> References: <1395114666-2052-1-git-send-email-alexander.deucher@amd.com> <87pplkymqk.fsf@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id DC2518F108 for ; Wed, 19 Mar 2014 07:22:14 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Alex Deucher Cc: Alex Deucher , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org On Wed, 19 Mar 2014, Alex Deucher wrote: > On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula > wrote: >> On Tue, 18 Mar 2014, Alex Deucher wrote: >>> Switch to debug only to avoid flooding the logs. >>> This mirrors the behavior in some other drivers. >> >> I'd rather think we should find out why the DP devices are replying with >> repeated native or i2c-over-aux defers. This doesn't help; I'm not in >> favour. > > While I agree with you in theory, in practice this will generate a ton > of regression bug reports since there will be new error messages in > the kernel log on some systems even though the displays are working > fine. I'm only seeing this on certain cards, others are perfectly > fine even with the same monitors and I don't have the bandwidth right > now to debug this further. In all cases the monitors are working > correctly. I'd argue we *want* the regression reports even when everything seems to be working fine. Otherwise we'll never fix the stuff up. Just a while back we used to have an infinite retry loop there in i915, until a buggy dock firmware actually deferred indefinitely. Clearly most devices out there eventually replied with something other than defer. We'd like to find out whether and how much the retry and/or delay should be increased to not hit the error condition at all. That's how I feel anyway. I'd like to see others chime in as well, and I won't insist if y'all think the error message must go. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center