[Intel-gfx] [PATCH] drm/i915/dg1: remove redundant uc_index assignment

Just clean up the redundant uc_index assignment for DG1. Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/gt/intel_mocs.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c index c4c37585ae8c..0c300727a5c2 100644

[Intel-gfx] [PATCH v2] drm/i915: fix one mem leak in mmap_offset_attach()

em: Store mmap_offsets in an rbtree rather than a plain list") Cc: # v5.7+ Cc: Chris Wilson Cc: Tvrtko Ursulin Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_m

[Intel-gfx] [PATCH] drm/i915: fix one mem leak in mmap_offset_attach()

Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index efe69d6b86f4..d50b2f643a10 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem

[Intel-gfx] [PATCH] drm/i915: fix one mem leak in mmap_offset_attach()

. However the driver just revokes the vma_node one time when closing the object, it leads to memory leak easily. This patch is to fix the memory leak by calling drm_vma_node_allow() one time also. Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 in

[Intel-gfx] [PATCH v2] drm/i915/dg1: Update DMC_DEBUG3 register

iewed-by: Matt Roper Cc: Jani Nikula Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/display/intel_display_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_

[Intel-gfx] [PATCH] drm/i915/dg1: Update DMC_DEBUG3 register

Current DMC_DEBUG3(_MMIO(0x101090)) address is for TGL, it is not wrong for DG1. Just like commit 5bcc95ca382e ("drm/i915/dg1: Update DMC_DEBUG register"), correct this issue for DG1 platform to avoid wrong register being read. BSpec: 49788 Signed-off-by: Chuansheng Liu --- drive

[Intel-gfx] [PATCH] drm/i915/debugfs: print more workaround registers

In the node i915_wa_registers, we could print out more information with whitelist, GT workaround and engine workaround. In addition, fix the warning by checkpatch.pl: WARNING: Prefer seq_puts to seq_printf Signed-off-by: Chuansheng Liu --- drivers/gpu/drm/i915/i915_debugfs.c | 60

[Intel-gfx] [PATCH] drm/i915: Fix the use-after-free between i915_active_ref and __active_retire

hit use-after-free in __i915_active_fence_set() === Here we need to use spinlock ref->tree_lock to protect the access of READ_ONCE(ref->cache), then the race scenerio can be resolved. with this patch, it passed our stress test for a very long time. Signed-off-by: Chuansheng Liu --- driver

[Intel-gfx] [PATCH i-g-t v3] i915/pm_rps: install SIGTERM handler for load_helper process

tch, the GT may keep busy after running this subtest. Enabling rps should be tracked on the other side. V3: As suggested by Chris, s/SIGUSR1/SIGTERM, since both signals take the same function. Signed-off-by: Chuansheng Liu --- tests/i915/i915_pm_rps.c | 4 ++-- 1 file changed, 2 insertions(+)

[Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

tch, the GT may keep busy after running this subtest. Enabling rps should be tracked on the other side. Signed-off-by: Chuansheng Liu --- tests/i915/i915_pm_rps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c index ef627c0b..8c71c1a1 100

[Intel-gfx] drm/i915: Avoid accessing the stolen address when it is unavailable

In our platform, we hit the the stolen region initialization failure case, such as below log: [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0x7b00] And it causes the dev_priv->mm.stolen_base is NULL, in this case, we should avoid accessing it any more. Here is

[Intel-gfx] [PATCH] drm/i915: Sync the hotplug work when device suspending

It is possible that during i915 device suspending with one pending hotplug work, one of cases is the device resume/suspend quickly. At this case, the hotplug work will be executed even after device is OFF, in Intel Android platform, it will cause system hang. Here we need sync the hotplug work i