From patchwork Tue Oct 29 18:06:18 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= X-Patchwork-Id: 3110151 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 8F743BF924 for ; Tue, 29 Oct 2013 18:09:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 72FD120204 for ; Tue, 29 Oct 2013 18:09:25 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 2813820173 for ; Tue, 29 Oct 2013 18:09:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8267DEEC76; Tue, 29 Oct 2013 11:07:36 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id A2DC0EEC67; Tue, 29 Oct 2013 11:07:26 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 29 Oct 2013 11:07:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.93,594,1378882800"; d="scan'208";a="424716905" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.98]) by fmsmga002.fm.intel.com with SMTP; 29 Oct 2013 11:07:23 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 29 Oct 2013 20:07:23 +0200 From: ville.syrjala@linux.intel.com To: dri-devel@lists.freedesktop.org Subject: [PATCH 14/14] drm/i915: Add a kludge for DSL incrementing too late and ISR not working Date: Tue, 29 Oct 2013 20:06:18 +0200 Message-Id: <1383069978-12476-15-git-send-email-ville.syrjala@linux.intel.com> X-Mailer: git-send-email 1.8.1.5 In-Reply-To: <1383069978-12476-1-git-send-email-ville.syrjala@linux.intel.com> References: <1383069978-12476-1-git-send-email-ville.syrjala@linux.intel.com> MIME-Version: 1.0 Cc: intel-gfx@lists.freedesktop.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Ville Syrjälä On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as far as display interrupts are concerned. Instead it sort of looks like some ISR bits just directly reflect the corresponding bit from PIPESTAT. The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So in that sense it sort of looks a bit like the south interrupt scheme on PCH platforms. So it goes something a bit like this: PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual interrupt In any case that means the intel_pipe_in_vblank_locked() doesn't actually work for pre-PCH platforms. As a last resort, add a similar kludge as radeon has that fixes things up if we got called from the vblank interrupt, but the scanline counter value indicates that we're not quite there yet. We know that the scanline counter increments at hsync but is otherwise accurate, so we can limit the kludge to the line just prior to vblank start, instead of the relative distance that radeon uses. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 79 ++++++++++++++++++++--------------------- 1 file changed, 39 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 70daf3c..b93f39c 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -603,36 +603,15 @@ static u32 gm45_get_vblank_counter(struct drm_device *dev, int pipe) #define __raw_i915_read32(dev_priv__, reg__) readl((dev_priv__)->regs + (reg__)) #define __raw_i915_read16(dev_priv__, reg__) readw((dev_priv__)->regs + (reg__)) -static bool intel_pipe_in_vblank_locked(struct drm_device *dev, enum pipe pipe) +static bool ilk_pipe_in_vblank_locked(struct drm_device *dev, enum pipe pipe) { struct drm_i915_private *dev_priv = dev->dev_private; uint32_t status; - int reg; - if (IS_VALLEYVIEW(dev)) { - status = pipe == PIPE_A ? - I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT : - I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT; - - reg = VLV_ISR; - } else if (IS_GEN2(dev)) { - status = pipe == PIPE_A ? - I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT : - I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT; - - reg = ISR; - } else if (INTEL_INFO(dev)->gen < 5) { - status = pipe == PIPE_A ? - I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT : - I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT; - - reg = ISR; - } else if (INTEL_INFO(dev)->gen < 7) { + if (INTEL_INFO(dev)->gen < 7) { status = pipe == PIPE_A ? DE_PIPEA_VBLANK : DE_PIPEB_VBLANK; - - reg = DEISR; } else { switch (pipe) { default: @@ -646,14 +625,9 @@ static bool intel_pipe_in_vblank_locked(struct drm_device *dev, enum pipe pipe) status = DE_PIPEC_VBLANK_IVB; break; } - - reg = DEISR; } - if (IS_GEN2(dev)) - return __raw_i915_read16(dev_priv, reg) & status; - else - return __raw_i915_read32(dev_priv, reg) & status; + return __raw_i915_read32(dev_priv, DEISR) & status; } static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe, @@ -710,17 +684,42 @@ static int i915_get_crtc_scanoutpos(struct drm_device *dev, int pipe, else position = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & DSL_LINEMASK_GEN3; - /* - * The scanline counter increments at the leading edge - * of hsync, ie. it completely misses the active portion - * of the line. Fix up the counter at both edges of vblank - * to get a more accurate picture whether we're in vblank - * or not. - */ - in_vbl = intel_pipe_in_vblank_locked(dev, pipe); - if ((in_vbl && position == vbl_start - 1) || - (!in_vbl && position == vbl_end - 1)) - position = (position + 1) % vtotal; + if (HAS_PCH_SPLIT(dev)) { + /* + * The scanline counter increments at the leading edge + * of hsync, ie. it completely misses the active portion + * of the line. Fix up the counter at both edges of vblank + * to get a more accurate picture whether we're in vblank + * or not. + */ + in_vbl = ilk_pipe_in_vblank_locked(dev, pipe); + if ((in_vbl && position == vbl_start - 1) || + (!in_vbl && position == vbl_end - 1)) + position = (position + 1) % vtotal; + } else { + /* + * ISR vblank status bits don't work the way we'd want + * them to work on non-PCH platforms (for + * ilk_pipe_in_vblank_locked()), and there doesn't + * appear any other way to determine if we're currently + * in vblank. + * + * Instead let's assume that we're already in vblank if + * we got called from the vblank interrupt and the + * scanline counter value indicates that we're on the + * line just prior to vblank start. This should result + * in the correct answer, unless the vblank interrupt + * delivery really got delayed for almost exactly one + * full frame/field. + */ + if (flags & DRM_CALLED_FROM_VBLIRQ && + position == vbl_start - 1) { + position = (position + 1) % vtotal; + + /* Signal this correction as "applied". */ + ret |= 0x8; + } + } } else { /* Have access to pixelcount since start of frame. * We can split this into vertical and horizontal