From patchwork Mon Mar 12 12:55:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 10276209 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1DD9F602BD for ; Mon, 12 Mar 2018 12:55:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0EFFC289AA for ; Mon, 12 Mar 2018 12:55:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 03B7128DAF; Mon, 12 Mar 2018 12:55:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 82B53289AA for ; Mon, 12 Mar 2018 12:55:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FC926E373; Mon, 12 Mar 2018 12:55:55 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from fireflyinternet.com (mail.fireflyinternet.com [109.228.58.192]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3B0CF6E36F for ; Mon, 12 Mar 2018 12:55:51 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from haswell.alporthouse.com (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP id 10994221-1500050 for multiple; Mon, 12 Mar 2018 12:55:46 +0000 Received: by haswell.alporthouse.com (sSMTP sendmail emulation); Mon, 12 Mar 2018 12:55:45 +0000 From: Chris Wilson To: intel-gfx@lists.freedesktop.org Date: Mon, 12 Mar 2018 12:55:42 +0000 Message-Id: <20180312125542.547-2-chris@chris-wilson.co.uk> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180312125542.547-1-chris@chris-wilson.co.uk> References: <20180312125542.547-1-chris@chris-wilson.co.uk> X-Originating-IP: 78.156.65.138 X-Country: code=GB country="United Kingdom" ip=78.156.65.138 Subject: [Intel-gfx] [PATCH 2/2] drm/i915/stolen: Intepret reserved_base=0 as deduce from top X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP On my j1900 Valleyview, and on both of CI's, if I allocate above the power context (as allotted by PCBR) then the objects are not accessed. For example, if it is a ringbuffer, then the commands are not executed, causing a GPU hang with no breadcrumb advancement. On inspection, GEN6_STOLEN_RESERVED is enabled, but has base==0 which we interpret a being invalid. However, it fits neatly in after the powercontext if we interpret base==0 as meaning allocate from top instead, the GPU doesn't hang on boot! Signed-off-by: Chris Wilson Cc: Ville Syrjala Cc: Imre Deak --- drivers/gpu/drm/i915/i915_gem_stolen.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index b04e2551bae6..1bd542977e4c 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -386,12 +386,13 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv) break; } - /* It is possible for the reserved base to be zero, but the register - * field for size doesn't have a zero option. */ - if (reserved_base == 0) { - reserved_size = 0; - reserved_base = stolen_top; - } + /* + * It is possible for the reserved base to be zero, but the register + * field for size doesn't have a zero option. Experience says they + * mean allocate from top. + */ + if (reserved_base == 0) + reserved_base = stolen_top - reserved_size; dev_priv->dsm_reserved = (struct resource) DEFINE_RES_MEM(reserved_base, reserved_size);