From patchwork Thu Jul 5 09:10:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 1158681 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id 0BE39DFB7C for ; Thu, 5 Jul 2012 09:11:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E009DA0DE8 for ; Thu, 5 Jul 2012 02:11:25 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id 28A9F9E7CF for ; Thu, 5 Jul 2012 02:10:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.66.37; Received: from arrandale.alporthouse.com (unverified [78.156.66.37]) by fireflyinternet.com (Firefly Internet SMTP) with ESMTP id 117546381-1500050 for multiple; Thu, 05 Jul 2012 10:10:47 +0100 From: Chris Wilson To: intel-gfx@lists.freedesktop.org Date: Thu, 5 Jul 2012 10:10:10 +0100 Message-Id: <1341479410-3073-1-git-send-email-chris@chris-wilson.co.uk> X-Mailer: git-send-email 1.7.10 X-Originating-IP: 78.156.66.37 Cc: stable@kernel.org Subject: [Intel-gfx] [PATCH] drm/i915: Detect the error case for too large CRTC offsets X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org On gen4+, we program the CRTC offset into the DSPTILEOFF register, which is limited to 12-bits of integer precision in both the x and the y axes. Programming a value larger than or equal to 4096 results in a wraparound of the CRTC location and a distorted output. This is undesirable, so abort the operation and report the error condition. We could attempt to mitigate this error by recomputing the DSPSURF base address to a nearby tile-row and adjusting the offsets relative to the fake CRTC subsurface. However, the question is whether this is common enough to merit a workaround as only clients that use a single composite fb and not per-crtc-fb such as X suffer. Such a design (rendering directly into a single composite fb across the scanouts) interacts badly with the power management of the display engine and is strongly discouraged; future windowing systems are designed around being able to page-flip per-crtc-fb. Within X itself, the mechanisms are already in place to avoid making such setcrtc requests, at a slight cost to efficiency. Cc: stable@kernel.org Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5708d9b..bd3f84b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1995,6 +1995,11 @@ static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb, return -EINVAL; } + if (INTEL_INFO(dev)->gen >= 4 && (x|y) & ~4095) { + DRM_ERROR("CRTC offset too larget (%d, %d)\n", x, y); + return -EINVAL; + } + intel_fb = to_intel_framebuffer(fb); obj = intel_fb->obj; @@ -2069,6 +2074,11 @@ static int ironlake_update_plane(struct drm_crtc *crtc, return -EINVAL; } + if ((x|y) & ~4095) { + DRM_ERROR("CRTC offset too larget (%d, %d)\n", x, y); + return -EINVAL; + } + intel_fb = to_intel_framebuffer(fb); obj = intel_fb->obj;