From patchwork Mon Dec 12 17:19:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13071264 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 14697C00145 for ; Mon, 12 Dec 2022 17:20:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EDA9710E237; Mon, 12 Dec 2022 17:20:25 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9773610E237 for ; Mon, 12 Dec 2022 17:20:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670865621; x=1702401621; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=xzEJURbwfmaKmH86uCTxOZ9sm/Zq9tGeWfAtSZYcHdk=; b=Z10to+w89ExE00ylBfHXPiri9AUVK31McpAOUCBAaTNsZKokC3g4D89x /hx4JN2kC34gj7wVWbdarXUlboHKwCos2gyQgHuSNeyKViFKa/TlXf0oM QKKng3+EijauVcUKbQZV0t/JDBSR6qS9GT/WEoDAjdD4FPnAQHXpPn7NA amcekCorMv2WoFHzkBIJFOZA6pY2jOl7Yu3bStIgUOpvy4w5Ikkov3Fjz 1plv05LaX5R5Eo3B7g2XoP1q6oeLLE62mwU6nTzuSx9B50okKPjxfYQm/ xULzCZ35Y3gxEhM6zYuInhRZ8UL+fIPpoeCK73+4SbVwuwzdfgfU6cfEW A==; X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="319769724" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="319769724" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 09:20:20 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="650411398" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="650411398" Received: from jzywicka-mobl.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.5.179]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 09:20:18 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Mon, 12 Dec 2022 17:19:57 +0000 Message-Id: <20221212171958.82593-1-matthew.auld@intel.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 1/2] drm/i915/migrate: fix corner case in CCS aux copying X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Shuicheng Lin , Andrzej Hajda , Nirmoy Das Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" In the case of lmem -> lmem transfers, which is currently only possible with small-bar systems, we need to ensure we copy the CCS aux state as-is, rather than nuke it. This should fix some nasty display corruption sometimes seen on DG2 small-bar systems, when also using DG2_RC_CCS_CC for the surface. Fixes: e3afc690188b ("drm/i915/display: consider DG2_RC_CCS_CC when migrating buffers") Signed-off-by: Matthew Auld Cc: Ville Syrjälä Cc: Nirmoy Das Cc: Andrzej Hajda Cc: Shuicheng Lin Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/gt/intel_migrate.c | 37 +++++++++++++++++++------ 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c b/drivers/gpu/drm/i915/gt/intel_migrate.c index e08a739b7091..3f638f198796 100644 --- a/drivers/gpu/drm/i915/gt/intel_migrate.c +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c @@ -839,14 +839,35 @@ intel_context_migrate_copy(struct intel_context *ce, if (err) goto out_rq; - /* - * While we can't always restore/manage the CCS state, - * we still need to ensure we don't leak the CCS state - * from the previous user, so make sure we overwrite it - * with something. - */ - err = emit_copy_ccs(rq, dst_offset, INDIRECT_ACCESS, - dst_offset, DIRECT_ACCESS, len); + if (src_is_lmem) { + /* + * If the src is already in lmem, then we must + * be doing an lmem -> lmem transfer, and so + * should be safe to directly copy the CCS + * state. In this case we have either + * initialised the CCS aux state when first + * clearing the pages (since it is already + * allocated in lmem), or the user has + * potentially populated it, in which case we + * need to copy the CCS state as-is. + */ + err = emit_copy_ccs(rq, + dst_offset, INDIRECT_ACCESS, + src_offset, INDIRECT_ACCESS, + len); + } else { + /* + * While we can't always restore/manage the CCS + * state, we still need to ensure we don't leak + * the CCS state from the previous user, so make + * sure we overwrite it with something. + */ + err = emit_copy_ccs(rq, + dst_offset, INDIRECT_ACCESS, + dst_offset, DIRECT_ACCESS, + len); + } + if (err) goto out_rq; From patchwork Mon Dec 12 17:19:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Matthew Auld X-Patchwork-Id: 13071265 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3D8E4C4332F for ; Mon, 12 Dec 2022 17:20:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 25B8210E238; Mon, 12 Dec 2022 17:20:33 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3DD5510E238 for ; Mon, 12 Dec 2022 17:20:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670865622; x=1702401622; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FRCFXAK0CgbAO508wGIZu3cJUyCR6Tpr4/izHzEaTxU=; b=JglQElwWsGNFjG8fW7G4UzE0kPrZusZ6nUrS5Mh6MhbwKAY9idBtW+F7 vZSZO5xmDAv9iTY1M0m+NAOEUjyQvNUKZop1ONzke3wPHo9C7r9Ag+UAs ex/2Cx8YPK/qaq2WF+XLe59hXgGsVdCTpDlN8EAYqasqOlX4iyBQztXN3 M3Uv2cfYm9RK+MUITYdpzuAWq9m51WxCQDtgQ4Dod6j4wzGslnuljJ8TJ BWaZ0sAH1pxJqiXRTr6PHpVtRfAFCohK1U8AF1ZYMrwsRnnSCWqq4Q6OM onxhvVxw/7trCeNB2D89mP5cqshbfmqBMARKD1K+r8Ei93cnMSqVtvyRF g==; X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="319769731" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="319769731" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 09:20:21 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10559"; a="650411408" X-IronPort-AV: E=Sophos;i="5.96,239,1665471600"; d="scan'208";a="650411408" Received: from jzywicka-mobl.ger.corp.intel.com (HELO mwauld-desk1.intel.com) ([10.252.5.179]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Dec 2022 09:20:20 -0800 From: Matthew Auld To: intel-gfx@lists.freedesktop.org Date: Mon, 12 Dec 2022 17:19:58 +0000 Message-Id: <20221212171958.82593-2-matthew.auld@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221212171958.82593-1-matthew.auld@intel.com> References: <20221212171958.82593-1-matthew.auld@intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 2/2] drm/i915/ttm: consider CCS for backup objects X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: stable@vger.kernel.org, Shuicheng Lin , Andrzej Hajda , Nirmoy Das Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" It seems we can have one or more framebuffers that are still pinned when suspending lmem, in such a case we end up creating a shmem backup object, instead of evicting the object directly, but this will skip copying the CCS aux state, since we don't allocate the extra storage for the CCS pages as part of the ttm_tt construction. Since we can already deal with pinned objects just fine, it doesn't seem too nasty to just extend to support dealing with the CCS aux state, if the object is a pinned framebuffer. This fixes display corruption (like in gnome-shell) seen on DG2 when returning from suspend. Fixes: da0595ae91da ("drm/i915/migrate: Evict and restore the flatccs capable lmem obj") Signed-off-by: Matthew Auld Cc: Ville Syrjälä Cc: Nirmoy Das Cc: Andrzej Hajda Cc: Shuicheng Lin Cc: # v5.19+ Tested-by: Nirmoy Das Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 +++ .../gpu/drm/i915/gem/i915_gem_object_types.h | 10 ++++++---- drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 18 +++++++++++++++++- 3 files changed, 26 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 733696057761..1a0886b8aaa1 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -785,6 +785,9 @@ bool i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj) if (!HAS_FLAT_CCS(to_i915(obj->base.dev))) return false; + if (obj->flags & I915_BO_ALLOC_CCS_AUX) + return true; + for (i = 0; i < obj->mm.n_placements; i++) { /* Compression is not allowed for the objects with smem placement */ if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h index a7b70701617a..19c9bdd8f905 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -327,16 +327,18 @@ struct drm_i915_gem_object { * dealing with userspace objects the CPU fault handler is free to ignore this. */ #define I915_BO_ALLOC_GPU_ONLY BIT(6) +#define I915_BO_ALLOC_CCS_AUX BIT(7) #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \ I915_BO_ALLOC_VOLATILE | \ I915_BO_ALLOC_CPU_CLEAR | \ I915_BO_ALLOC_USER | \ I915_BO_ALLOC_PM_VOLATILE | \ I915_BO_ALLOC_PM_EARLY | \ - I915_BO_ALLOC_GPU_ONLY) -#define I915_BO_READONLY BIT(7) -#define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */ -#define I915_BO_PROTECTED BIT(9) + I915_BO_ALLOC_GPU_ONLY | \ + I915_BO_ALLOC_CCS_AUX) +#define I915_BO_READONLY BIT(8) +#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */ +#define I915_BO_PROTECTED BIT(10) /** * @mem_flags - Mutable placement-related flags * diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c index 07e49f22f2de..7e67742bc65e 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c @@ -50,6 +50,7 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region *apply, container_of(bo->bdev, typeof(*i915), bdev); struct drm_i915_gem_object *backup; struct ttm_operation_ctx ctx = {}; + unsigned int flags; int err = 0; if (bo->resource->mem_type == I915_PL_SYSTEM || obj->ttm.backup) @@ -65,7 +66,22 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region *apply, if (obj->flags & I915_BO_ALLOC_PM_VOLATILE) return 0; - backup = i915_gem_object_create_shmem(i915, obj->base.size); + /* + * It seems that we might have some framebuffers still pinned at this + * stage, but for such objects we might also need to deal with the CCS + * aux state. Make sure we force the save/restore of the CCS state, + * otherwise we might observe display corruption, when returning from + * suspend. + */ + flags = 0; + if (i915_gem_object_needs_ccs_pages(obj)) { + WARN_ON_ONCE(!i915_gem_object_is_framebuffer(obj)); + WARN_ON_ONCE(!pm_apply->allow_gpu); + + flags = I915_BO_ALLOC_CCS_AUX; + } + backup = i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_SMEM], + obj->base.size, 0, flags); if (IS_ERR(backup)) return PTR_ERR(backup);