linux-stable.git/drivers/gpu, branch v5.15.151

Revert "drm/bridge: lt8912b: Register and attach our DSI device at probe"

2024-03-06T14:38:50+00:00

This reverts commit ef4a40953c8076626875ff91c41e210fcee7a6fd which is
commit d89078c37b10f05fa4f4791b71db2572db361b68 upstream.

The commit was applied to make further commits apply cleanly, but the
commit depends on other commits in the same patchset. I.e. the
controlling DSI host would need a change too. Thus one would need to
backport the full patchset changing the DSI hosts and all downstream
DSI device drivers.

Revert the commit and fix up the conflicts with the backported fixes
to the lt8912b driver.

Signed-off-by: Max Krummenacher 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix memory leak in dm_sw_fini()

2024-03-01T12:22:00+00:00

[ Upstream commit bae67893578d608e35691dcdfa90c4957debf1d3 ]

After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:

unreferenced object 0xffff896302b45800 (size 1024):
  comm "(udev-worker)", pid 222, jiffies 4294894636
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 6265fd77):
    [] kmalloc_trace+0x29d/0x340
    [] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [] dm_sw_init+0x15/0x2b0 [amdgpu]
    [] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [] local_pci_probe+0x3e/0x90
    [] pci_device_probe+0xc3/0x230
    [] really_probe+0xe2/0x480
    [] __driver_probe_device+0x78/0x160
    [] driver_probe_device+0x1f/0x90
    [] __driver_attach+0xce/0x1c0
    [] bus_for_each_dev+0x70/0xc0
    [] bus_add_driver+0x112/0x210
    [] driver_register+0x55/0x100
    [] do_one_initcall+0x41/0x300

Fix this by freeing dmub_srv after destroying it.

Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
Signed-off-by: Armin Wolf 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/syncobj: call drm_syncobj_fence_add_wait when WAIT_AVAILABLE flag is set

2024-03-01T12:22:00+00:00

[ Upstream commit 3c43177ffb54ea5be97505eb8e2690e99ac96bc9 ]

When waiting for a syncobj timeline point whose fence has not yet been
submitted with the WAIT_FOR_SUBMIT flag, a callback is registered using
drm_syncobj_fence_add_wait and the thread is put to sleep until the
timeout expires. If the fence is submitted before then,
drm_syncobj_add_point will wake up the sleeping thread immediately which
will proceed to wait for the fence to be signaled.

However, if the WAIT_AVAILABLE flag is used instead,
drm_syncobj_fence_add_wait won't get called, meaning the waiting thread
will always sleep for the full timeout duration, even if the fence gets
submitted earlier. If it turns out that the fence *has* been submitted
by the time it eventually wakes up, it will still indicate to userspace
that the wait completed successfully (it won't return -ETIME), but it
will have taken much longer than it should have.

To fix this, we must call drm_syncobj_fence_add_wait if *either* the
WAIT_FOR_SUBMIT flag or the WAIT_AVAILABLE flag is set. The only
difference being that with WAIT_FOR_SUBMIT we will also wait for the
fence to be signaled after it has been submitted while with
WAIT_AVAILABLE we will return immediately.

IGT test patch: https://lists.freedesktop.org/archives/igt-dev/2024-January/067537.html

v1 -> v2: adjust lockdep_assert_none_held_once condition

(cherry picked from commit 8c44ea81634a4a337df70a32621a5f3791be23df)

Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
Signed-off-by: Erik Kurzinger 
Signed-off-by: Simon Ser 
Reviewed-by: Daniel Vetter 
Reviewed-by: Simon Ser 
Link: https://patchwork.freedesktop.org/patch/msgid/20240119163208.3723457-1-ekurzinger@nvidia.com
Signed-off-by: Sasha Levin

drm/nouveau/instmem: fix uninitialized_var.cocci warning

2024-03-01T12:21:59+00:00

[ Upstream commit 2046e733e125fa58ed997f3d26d43543faf82c95 ]

Fix following coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c:316:11-12:
WARNING this kind of initialization is deprecated.

`void *map = map` has the same form of
uninitialized_var() macro. I remove the redundant assignement. It has
been tested with gcc (Debian 8.3.0-6) 8.3.0.

The patch which removed uninitialized_var() is:
https://lore.kernel.org/all/20121028102007.GA7547@gmail.com/
And there is very few "/* GCC */" comments in the Linux kernel code now.

Signed-off-by: Guo Zhengkui 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20220228142352.18006-1-guozhengkui@vivo.com
Stable-dep-of: 3b1ae9b71c2a ("octeontx2-af: Consider the action set by PF")
Signed-off-by: Sasha Levin

nouveau: fix function cast warnings

2024-03-01T12:21:58+00:00

[ Upstream commit 0affdba22aca5573f9d989bcb1d71d32a6a03efe ]

clang-16 warns about casting between incompatible function types:

drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from 'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
  161 |         .fini = (void(*)(void *))release_firmware,

This one was done to use the generic shadow_fw_release() function as a
callback for struct nvbios_source. Change it to use the same prototype
as the other five instances, with a trivial helper function that actually
calls release_firmware.

Fixes: 70c0f263cc2e ("drm/nouveau/bios: pull in basic vbios subdev, more to come later")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Danilo Krummrich 
Link: https://patchwork.freedesktop.org/patch/msgid/20240213095753.455062-1-arnd@kernel.org
Signed-off-by: Sasha Levin

drm/i915/dg1: Update DMC_DEBUG3 register

2024-03-01T12:21:53+00:00

[ Upstream commit b60668cb4c57a7cc451de781ae49f5e9cc375eaf ]

Current DMC_DEBUG3(_MMIO(0x101090)) address is for TGL,
it is 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

v2: fix "not wrong" typo. (Jani)

Reviewed-by: Matt Roper 
Cc: Jani Nikula 
Signed-off-by: Chuansheng Liu 
Signed-off-by: Matt Roper 
Link: https://patchwork.freedesktop.org/patch/msgid/20220211002933.84240-1-chuansheng.liu@intel.com
Signed-off-by: Sasha Levin

drm/amdgpu: init iommu after amdkfd device init

2024-03-01T12:21:52+00:00

[ Upstream commit 286826d7d976e7646b09149d9bc2899d74ff962b ]

This patch is to fix clinfo failure in Raven/Picasso:

Number of platforms: 1
  Platform Profile: FULL_PROFILE
  Platform Version: OpenCL 2.2 AMD-APP (3364.0)
  Platform Name: AMD Accelerated Parallel Processing
  Platform Vendor: Advanced Micro Devices, Inc.
  Platform Extensions: cl_khr_icd cl_amd_event_callback

  Platform Name: AMD Accelerated Parallel Processing Number of devices: 0

Signed-off-by: Yifan Zhang 
Reviewed-by: James Zhu 
Tested-by: James Zhu 
Acked-by: Felix Kuehling 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/ttm: Fix an invalid freeing on already freed page in error path

2024-03-01T12:21:48+00:00

commit 40510a941d27d405a82dc3320823d875f94625df upstream.

If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.

However the second step was incorrectly freeing the pages already
freed in the first step.

Fix.

Signed-off-by: Thomas Hellström 
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König 
Cc: Dave Airlie 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.4+
Reviewed-by: Matthew Auld 
Reviewed-by: Christian König 
Link: https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellstrom@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: reset gpu for s3 suspend abort case

2024-03-01T12:21:47+00:00

[ Upstream commit 6ef82ac664bb9568ca3956e0d9c9c478e25077ff ]

In the s3 suspend abort case some type of gfx9 power
rail not turn off from FCH side and this will put the
GPU in an unknown power status, so let's reset the gpu
to a known good power state before reinitialize gpu
device.

Signed-off-by: Prike Liang 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: skip to program GFXDEC registers for suspend abort

2024-03-01T12:21:47+00:00

[ Upstream commit 93bafa32a6918154aa0caf9f66679a32c2431357 ]

In the suspend abort cases, the gfx power rail doesn't turn off so
some GFXDEC registers/CSB can't reset to default value and at this
moment reinitialize GFXDEC/CSB will result in an unexpected error.
So let skip those program sequence for the suspend abort case.

Signed-off-by: Prike Liang 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin