kernel/linux.git/drivers/gpu/drm, branch v6.5.12

Revert "drm/ast: report connection status on Display Port."

2023-11-20T10:57:25+00:00

This reverts commit f81bb0ac7872893241319ea82504956676ef02fd. The commit depends on e329cb53b45d ("drm/ast: Add BMC virtual connector") and will cause hangs on boot without that dependency. Signed-off-by: Sasha Levin

drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE

2023-11-20T10:57:24+00:00

[ Upstream commit 101c9f637efa1655f55876644d4439e552267527 ] If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been submitted for the given timeline point the call will fail immediately with EINVAL. This does not match the intended behavior where the call should wait until the fence has been submitted (or the timeout expires). The following small example program illustrates the issue. It should wait for 5 seconds and then print ETIME, but instead it terminates right away after printing EINVAL. #include #include #include #include #include int main(void) { int fd = open("/dev/dri/card0", O_RDWR); uint32_t syncobj; drmSyncobjCreate(fd, 0, &syncobj); struct timespec ts; clock_gettime(CLOCK_MONOTONIC, &ts); uint64_t point = 1; if (drmSyncobjTimelineWait(fd, &syncobj, &point, 1, ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) { printf("drmSyncobjTimelineWait failed %d\n", errno); } } Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8") Signed-off-by: Erik Kurzinger Reviewed by: Simon Ser Signed-off-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/1fac96f1-2f3f-f9f9-4eb0-340f27a8f6c0@nvidia.com Signed-off-by: Sasha Levin

drm/vc4: tests: Fix UAF in the mock helpers

2023-11-20T10:57:24+00:00

[ Upstream commit cdcd6aef9db5797995d4153ea19fdf56d189f0e4 ] The VC4 mock helpers allocate the CRTC, encoders and connectors using a call to kunit_kzalloc(), but the DRM device they are attache to survives for longer than the test itself which leads to use-after-frees reported by KASAN. Switch to drmm_kzalloc to tie the lifetime of these objects to the main DRM device. Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure") Reported-by: Linux Kernel Functional Testing Closes: https://lore.kernel.org/all/CA+G9fYvJA2HGqzR9LGgq63v0SKaUejHAE6f7+z9cwWN-ourJ_g@mail.gmail.com/ Tested-by: Anders Roxell Reviewed-by: Maíra Canal Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20231024105640.352752-1-mripard@kernel.org Signed-off-by: Sasha Levin

drm/amdgpu: don't put MQDs in VRAM on ARM | ARM64

2023-11-20T10:57:21+00:00

[ Upstream commit ba0fb4b48c19a2d2380fc16ca4af236a0871d279 ] Issues were reported with commit 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM") on an ADLINK Ampere Altra Developer Platform (AVA developer platform). Various ARM systems seem to have problems related to PCIe and MMIO access. In this case, I'm not sure if this is specific to the ADLINK platform or ARM in general. Seems to be some coherency issue with VRAM. For now, just don't put MQDs in VRAM on ARM. Link: https://lists.freedesktop.org/archives/amd-gfx/2023-October/100453.html Fixes: 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM") Acked-by: Christian König Signed-off-by: Alex Deucher Cc: alexey.klimov@linaro.org Signed-off-by: Sasha Levin

drm/amdgpu/gfx10,11: use memcpy_to/fromio for MQDs

2023-11-20T10:57:21+00:00

[ Upstream commit b3c942bb6c32a8ddc1d52ee6bc24b8cf732dddf4 ] Since they were moved to VRAM, we need to use the IO variants of memcpy. Fixes: 1cfb4d612127 ("drm/amdgpu: put MQDs in VRAM") Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/pm: Fix a memory leak on an error path

2023-11-20T10:57:02+00:00

[ Upstream commit 828f8e31379b28fe7f07fb5865b8ed099d223fca ] Add missing free on an error path. Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support") Reviewed-by: Yang Wang Signed-off-by: Kunwu.Chan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm: mediatek: mtk_dsi: Fix NO_EOT_PACKET settings/handling

2023-11-20T10:57:02+00:00

[ Upstream commit 5855d422a6f250f3518f43b49092c8e87a5e42be ] Due to the initial confusion about MIPI_DSI_MODE_EOT_PACKET, properly renamed to MIPI_DSI_MODE_NO_EOT_PACKET, reflecting its actual meaning, both the DSI_TXRX_CON register setting for bit (HSTX_)DIS_EOT and the later calculation for horizontal sync-active (HSA), back (HBP) and front (HFP) porches got incorrect due to the logic being inverted. This means that a number of settings were wrong because....: - DSI_TXRX_CON register setting: bit (HSTX_)DIS_EOT should be set in order to disable the End of Transmission packet; - Horizontal Sync and Back/Front porches: The delta used to calculate all of HSA, HBP and HFP should account for the additional EOT packet. Before this change... - Bit (HSTX_)DIS_EOT was being set when EOT packet was enabled; - For HSA/HBP/HFP delta... all three were wrong, as words were added when EOT disabled, instead of when EOT packet enabled! Invert the logic around flag MIPI_DSI_MODE_NO_EOT_PACKET in the MediaTek DSI driver to fix the aforementioned issues. Fixes: 8b2b99fd7931 ("drm/mediatek: dsi: Fine tune the line time caused by EOTp") Fixes: c87d1c4b5b9a ("drm/mediatek: dsi: Use symbolized register definition") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Alexandre Mergnat Tested-by: Michael Walle Link: https://patchwork.kernel.org/project/dri-devel/patch/20230523104234.7849-1-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin

drm/msm/dsi: free TX buffer in unbind

2023-11-20T10:57:02+00:00

[ Upstream commit 5e05be78264594634860087953649487f486ffcc ] If the drm/msm init code gets an error during output modeset initialisation, the kernel will report an error regarding DRM memory manager not being clean during shutdown. This is because msm_dsi_modeset_init() allocates a piece of GEM memory for the TX buffer, but destruction of the buffer happens only at msm_dsi_host_destroy(), which is called during DSI driver's remove() time, much later than the DRM MM shutdown. To solve this issue, move the TX buffer destruction to dsi_unbind(), so that the buffer is destructed at the correct time. Note, we also have to store a reference to the address space, because priv->kms->aspace is cleared before components are unbound. Reported-by: Bjorn Andersson Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order") Signed-off-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/562238/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm/dsi: use msm_gem_kernel_put to free TX buffer

2023-11-20T10:57:02+00:00

[ Upstream commit 69b321b2c3df4f7e51a9de587e41f324b0b717b0 ] Use exiting function to free the allocated GEM object instead of open-coding it. This has a bonus of internally calling msm_gem_put_vaddr() to compensate for msm_gem_get_vaddr() in msm_get_kernel_new(). Fixes: 1e29dff00400 ("drm/msm: Add a common function to free kernel buffer objects") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/562239/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map()

2023-11-20T10:57:02+00:00

[ Upstream commit 6471da5ee311d53ef46eebcb7725bc94266cc0cf ] The "ret" variable is declared as ssize_t and it can hold negative error codes but the "rk_obj->base.size" variable is type size_t. This means that when we compare them, they are both type promoted to size_t and the negative error code becomes a high unsigned value and is treated as success. Add a cast to fix this. Fixes: 38f993b7c59e ("drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain") Signed-off-by: Dan Carpenter Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/2bfa28b5-145d-4b9e-a18a-98819dd686ce@moroto.mountain Signed-off-by: Sasha Levin