From patchwork Thu Dec 22 18:44:55 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniele Ceraolo Spurio X-Patchwork-Id: 9485495 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 10C97601C0 for ; Thu, 22 Dec 2016 18:44:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 21A822843D for ; Thu, 22 Dec 2016 18:44:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 14D182843F; Thu, 22 Dec 2016 18:44:59 +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 94AF82843D for ; Thu, 22 Dec 2016 18:44:58 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B95036F35E; Thu, 22 Dec 2016 18:44:57 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6F8F56F35E for ; Thu, 22 Dec 2016 18:44:56 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 22 Dec 2016 10:44:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,389,1477983600"; d="scan'208";a="21774255" Received: from relo-linux-1.fm.intel.com (HELO [10.1.27.60]) ([10.1.27.60]) by orsmga002.jf.intel.com with ESMTP; 22 Dec 2016 10:44:55 -0800 To: intel-gfx@lists.freedesktop.org References: <20161221141126.2452-1-chris@chris-wilson.co.uk> <20161221153014.GA63572@mwajdecz-MOBL1.ger.corp.intel.com> <20161221160330.GC735@nuc-i3427.alporthouse.com> <20161221163032.GB63572@mwajdecz-MOBL1.ger.corp.intel.com> <83F5C7385F545743AD4FB2A62F75B0730195A36D@ORSMSX108.amr.corp.intel.com> <20161222145315.GA32716@ahiler-desk.igk.intel.com> <20161222151808.GC11865@nuc-i3427.alporthouse.com> <20161222163839.GC32716@ahiler-desk.igk.intel.com> From: Daniele Ceraolo Spurio Organization: Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ Message-ID: <9976488e-c41d-a9a5-ee0d-768ff4fe10b9@intel.com> Date: Thu, 22 Dec 2016 10:44:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161222163839.GC32716@ahiler-desk.igk.intel.com> Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Reserve the upper end of the Global GTT for the GuC X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP On 22/12/16 08:38, Arkadiusz Hiler wrote: > On Thu, Dec 22, 2016 at 03:18:08PM +0000, Chris Wilson wrote: >> On Thu, Dec 22, 2016 at 03:53:15PM +0100, Arkadiusz Hiler wrote: >>> On Wed, Dec 21, 2016 at 07:35:04PM +0100, Srivatsa, Anusha wrote: >>>> With enable_guc_loading=2 and enable_guc_submission=0 I get HuC >>>> authentication failure and with enable_guc_loading and >>>> enable_guc_submisssion both set to 2 the device does not show any >>>> display. >>> >>> Sadly "the fix" fixes the issues we had with the loading - we can load >>> GuC but... >>> >>> GuC Actions (INTEL_GUC_ACTION*, and intel_guc_send()) seem to care about >>> kernel context pinned location as well (not directly though). And it's >>> much more restritive. >>> >>> Experimentally I was able to determine that if we have ctx pinned above >>> 0x10000000 (2 GB) mark, GuC Actions just fail. >> >> Are we certain this only applies to the kernel/golden context? No other >> objects accessed by the GuC are affected? >> -Chris > > Not sure yet. > I've root caused the issue to the ring being placed in the bottom area of the GGTT (GuC validates the ring offset as well). It looks like the allocator will place the ring offset immediately after the ctx if the latter is placed at an offset below 0x10000000 and will instead restart from the bottom of the GGTT otherwise. Without Chris' patch to pin the context at the top: CTX: 92KiB 01 01 LLC dirty (pinned x 1) (ggtt offset: 00080000, size: 00017000, type: 0) RING:16KiB 40 40 LLC dirty (pinned x 1) (ggtt offset: 00097000, size: 00004000, type: 0) (stolen: 00002000) With the patch: CTX: 92KiB 01 01 LLC dirty (pinned x 1) (ggtt offset: fede6000, size: 00017000, type: 0) RING:16KiB 40 40 LLC dirty (pinned x 1) (ggtt offset: 00001000, size: 00004000, type: 0) (stolen: 00002000) Forcing the ring to be above GUC_WOPCM_TOP fixed both HuC loading and host2guc with GuC submission for me (see diff below). Can someone verify? Daniele >> -- >> Chris Wilson, Intel Open Source Technology Centre > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 69ccf4f..0d944ab 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1830,6 +1830,9 @@ int intel_ring_pin(struct intel_ring *ring) return ret; } + if (HAS_GUC_SCHED(ring->engine->i915)) + flags |= PIN_OFFSET_BIAS | GUC_WOPCM_TOP; + ret = i915_vma_pin(vma, 0, PAGE_SIZE, flags); if (unlikely(ret)) return ret;