From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com ([134.134.136.31]:63990 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbdALR5a (ORCPT ); Thu, 12 Jan 2017 12:57:30 -0500 Message-ID: <1484243846.21150.1.camel@intel.com> Subject: Re: [PATCH v8] drm/i915/gen9: Fix PCODE polling during CDCLK change notification From: Imre Deak Reply-To: imre.deak@intel.com To: Greg Kroah-Hartman Cc: stable@vger.kernel.org, Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , Chris Wilson , Jani Nikula Date: Thu, 12 Jan 2017 19:57:26 +0200 In-Reply-To: <20170112172136.GC13342@kroah.com> References: <1484227358-26883-1-git-send-email-imre.deak@intel.com> <20170112172136.GC13342@kroah.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: On Thu, 2017-01-12 at 18:21 +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 12, 2017 at 03:22:38PM +0200, Imre Deak wrote: > > commit 848496e5902833600f7992f4faa82dc1546051ba > > Author: Ville Syrjälä > > Date:   Wed Jul 13 16:32:03 2016 +0300 > > > >     drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL > > > > increased the timeout to match the spec, but we still see a timeout on > > at least one SKL. A CDCLK change request following the failed one will > > succeed nevertheless. > > > > I could reproduce this problem easily by running kms_pipe_crc_basic in a > > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in > > the worst case - when the pre-emption happened right after calculating > > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only > > once which failed and so _wait_for() timed out. As opposed to this the > > spec says to keep retrying the request for at most a 3ms period. > > > > To fix this send the first request explicitly to guarantee that there is > > 3ms between the first and last request. Though this matches the spec, I > > noticed that in rare cases this can still time out if we sent only a few > > requests (in the worst case 2) _and_ PCODE is busy for some reason even > > after a previous request and a 3ms delay. To work around this retry the > > polling with pre-emption disabled to maximize the number of requests. > > Also increase the timeout to 10ms to account for interrupts that could > > reduce the number of requests. With this change I couldn't trigger > > the problem. > > > > v2: > > - Use 1ms poll period instead of 10us. (Chris) > > v3: > > - Poll with pre-emption disabled to increase the number of request > >   attempts. (Ville, Chris) > > - Factor out a helper to poll, it's also needed by the next patch. > > v4: > > - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the > >   reply is generic. (Ville) > > v5: > > - List the request specific timeout values as code comment. (Ville) > > v6: > > - Try the poll first with preemption enabled. > > - Add code comment about first request being queued by PCODE. (Art) > > - Add timeout_base_ms argument. (Ville) > > v7: > > - Clarify code comment about first queued request. (Chris) > > v8: > > - Rebased on 4.9.2 > > > > Cc: Ville Syrjälä > > Cc: Chris Wilson > > Cc: Art Runyan > > Cc: # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms > > Cc: # v4.2- > > Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 > > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B > > Signed-off-by: Imre Deak > > Reviewed-by: Chris Wilson > > Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com > > (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) > > Signed-off-by: Jani Nikula > > --- > >  drivers/gpu/drm/i915/i915_drv.h      |  2 + > >  drivers/gpu/drm/i915/intel_display.c | 31 +++++---------- > >  drivers/gpu/drm/i915/intel_pm.c      | 75 ++++++++++++++++++++++++++++++++++++ > >  3 files changed, 87 insertions(+), 21 deletions(-) > > What tree is this patch for?  Please give us a hint, we don't like > guessing... It's for the 4.9 stable tree and for other stable trees starting from 4.2. It's the upstream commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd rebased on top of 4.9.2 according to our discussion at http://www.spinics.net/lists/stable/msg155406.html --Imre