From patchwork Fri Mar 6 17:58:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 5956961 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D3BFFBF6C3 for ; Fri, 6 Mar 2015 17:57:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EFEE620374 for ; Fri, 6 Mar 2015 17:57:06 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 51FDA20397 for ; Fri, 6 Mar 2015 17:57:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 86C146E2D4; Fri, 6 Mar 2015 09:57:04 -0800 (PST) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by gabe.freedesktop.org (Postfix) with ESMTP id 2CF366E185 for ; Fri, 6 Mar 2015 09:57:03 -0800 (PST) Received: by widem10 with SMTP id em10so5414137wid.5 for ; Fri, 06 Mar 2015 09:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=TVKZHVrm8HWNaEWLWnT0nh/WP4bMtTzVLPC1NJtwv3Y=; b=gMweNuqANbVcUQbiuz+cqr7fI/T6C4QYlcrhf9i4AbuXKx/htauZzUuTFyriXB23ML tvesfsN5WNI+cSm/EktSASbhKE7Dm+sE9jBfzhrg3jwzAyQpZkC5UR7qZQmkHGmxFnCo Jj2li4Q2ZqmbqF3EZitJLLLY5t2t2wazUJWI0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding; bh=TVKZHVrm8HWNaEWLWnT0nh/WP4bMtTzVLPC1NJtwv3Y=; b=boCFTRocc/WHHLct/HPK7AFESRiDkoK81rfyh1T8XLg4v3Jnvrz7ZNh/Rlfjc0SdhD fm4+qRbQ1iU20o94jp6gWmPvbTUtmQXlkoLatx4/BfBhe6bCJC6lM89wvKIIjuSHg2Ll nIR4+iDX9Wge9xenfhd2DFAZUVADh5tUe6Q8XyCV3ixFxNKzKgmetwOKG+5V1ITGCcBb MXeqpPjDB5Qf3pQ3Z4d/JtfzRHSIz1xGqJAD2vaRwdasETX1rNmFeD3wC0ULkdyTAnQs rXS2dTrMCoiC9aOwuZqFsTRydjf63mMYvmWVblVfN773el2mh8T3SMR5G8B2osF5Cpu8 MqtA== X-Gm-Message-State: ALoCoQm4EFRztNRTBHFvRITrG0v03KiEIvym3JWxvq/SG4fSAA2WROf7vl2uo3Z9lGsYkQz3EjwC X-Received: by 10.194.59.199 with SMTP id b7mr32345407wjr.26.1425664622461; Fri, 06 Mar 2015 09:57:02 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by mx.google.com with ESMTPSA id j7sm3246660wix.4.2015.03.06.09.57.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Mar 2015 09:57:01 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Subject: [PATCH] Revert "intel: Fix documentation for drm_intel_gem_bo_wait()" Date: Fri, 6 Mar 2015 18:58:35 +0100 Message-Id: <1425664715-29548-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Cc: Daniel Vetter , Daniel Vetter , DRI Development X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_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 This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b. Chris noticed that "negative values wait forever" is indeed intended behaviour and the issue is just that we didn't have a testcase (fixed now) and that a regression slipped through (fixed and on track for all stable kernels). So lets undo the documentation change for consistency, since working around kernel regressions isn't good. Practical impact is nil anyway. v2: Add a note to docs that some kernels have been broken. v3: Remove the random garbage included by accident. Cc: Kristian Høgsberg Cc: Chris Wilson Reviewed-by: Kristian Høgsberg Signed-off-by: Daniel Vetter --- intel/intel_bufmgr_gem.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 33d8fbc46242..acbfd4ada209 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -1655,14 +1655,12 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo) * * @bo: buffer object to wait for * @timeout_ns: amount of time to wait in nanoseconds. - * If value is less than or equal to 0, return immediately. + * If value is less than 0, an infinite wait will occur. * - * Returns 0 if the wait was successful ie. the last batch referencing - * the object has completed within the allotted time. Otherwise some - * negative return value describes the error. Of particular interest - * is -ETIME when the wait has failed to yield the desired result. - * Use a timeout of INT64_MAX to wait indefinitely (well, at least 292 - * years). + * Returns 0 if the wait was successful ie. the last batch referencing the + * object has completed within the allotted time. Otherwise some negative return + * value describes the error. Of particular interest is -ETIME when the wait has + * failed to yield the desired result. * * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows * the operation to give up after a certain amount of time. Another subtle @@ -1675,6 +1673,9 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo) * not guarantee that the buffer is re-issued via another thread, or an flinked * handle. Userspace must make sure this race does not occur if such precision * is important. + * + * Note that some kernels have broken the inifite wait for negative values + * promise, upgrade to latest stable kernels if this is the case. */ drm_public int drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)