kernel/linux.git/drivers/gpu, branch v5.10.185

drm/i915/gen11+: Only load DRAM information from pcode

2023-06-21T13:45:41+00:00

[ Upstream commit 5d0c938ec9cc96fc7b8abcff0ca8b2a084e9c90c ] Up to now we were reading some DRAM information from MCHBAR register and from pcode what is already not good but some GEN12(TGL-H and ADL-S) platforms have MCHBAR DRAM information in different offsets. This was notified to HW team that decided that the best alternative is always apply the 16gb_dimm watermark adjustment for GEN12+ platforms and read the remaning DRAM information needed to other display programming from pcode. So here moving the DRAM pcode function to intel_dram.c, removing the duplicated fields from intel_qgv_info, setting and using information from dram_info. v2: - bring back num_points to intel_qgv_info as num_qgv_point can be overwritten in icl_get_qgv_points() - add gen12_get_dram_info() and simplify gen11_get_dram_info() Reviewed-by: Lucas De Marchi Signed-off-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20210128164312.91160-2-jose.souza@intel.com Signed-off-by: Henning Schild Signed-off-by: Greg Kroah-Hartman

drm/i915/dg1: Wait for pcode/uncore handshake at startup

2023-06-21T13:45:41+00:00

[ Upstream commit f9c730ede7d3f40900cb493890d94d868ff2f00f ] DG1 does some additional pcode/uncore handshaking at boot time; this handshaking must complete before various other pcode commands are effective and before general work is submitted to the GPU. We need to poll a new pcode mailbox during startup until it reports that this handshaking is complete. The bspec doesn't give guidance on how long we may need to wait for this handshaking to complete. For now, let's just set a really long timeout; if we still don't get a completion status by the end of that timeout, we'll just continue on and hope for the best. v2 (Lucas): Rename macros to make clear the relation between command and result (requested by José) Bspec: 52065 Cc: Clinton Taylor Cc: Ville Syrjälä Cc: Radhakrishna Sripada Signed-off-by: Matt Roper Signed-off-by: Lucas De Marchi Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20201001063917.3133475-2-lucas.demarchi@intel.com Signed-off-by: Henning Schild Signed-off-by: Greg Kroah-Hartman

drm/nouveau: add nv_encoder pointer check for NULL

2023-06-21T13:45:39+00:00

[ Upstream commit 55b94bb8c42464bad3d2217f6874aa1a85664eac ] Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova Reviewed-by: Lyude Paul [Fixed patch title] Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20230512103320.82234-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin

drm/nouveau/dp: check for NULL nv_connector->native_mode

2023-06-21T13:45:39+00:00

[ Upstream commit 20a2ce87fbaf81e4c3dcb631d738e423959eb320 ] Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20230512111526.82408-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin

drm/nouveau: don't detect DSM for non-NVIDIA device

2023-06-21T13:45:39+00:00

[ Upstream commit 11d24327c2d7ad7f24fcc44fb00e1fa91ebf6525 ] The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine. Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't. This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace. As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess. Fixes: ccfc2d5cdb02 ("drm/nouveau: Use generic helper to check _PR3 presence") Signed-off-by: Ratchanan Srirattanamet Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79 Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/DM6PR19MB2780805D4BE1E3F9B3AC96D0BC409@DM6PR19MB2780.namprd19.prod.outlook.com Signed-off-by: Sasha Levin

nouveau: fix client work fence deletion race

2023-06-21T13:45:37+00:00

commit c8a5d5ea3ba6a18958f8d76430e4cd68eea33943 upstream. This seems to have existed for ever but is now more apparant after commit 9bff18d13473 ("drm/ttm: use per BO cleanup workers") My analysis: two threads are running, one in the irq signalling the fence, in dma_fence_signal_timestamp_locked, it has done the DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached the callbacks. The second thread in nouveau_cli_work_ready, where it sees the fence is signalled, so then puts the fence, cleanups the object and frees the work item, which contains the callback. Thread one goes again and tries to call the callback and causes the use-after-free. Proposed fix: lock the fence signalled check in nouveau_cli_work_ready, so either the callbacks are done or the memory is freed. Reviewed-by: Karol Herbst Fixes: 11e451e74050 ("drm/nouveau: remove fence wait code from deferred client work handler") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie Link: https://lore.kernel.org/dri-devel/20230615024008.1600281-1-airlied@gmail.com/ Signed-off-by: Greg Kroah-Hartman

drm:amd:amdgpu: Fix missing buffer object unlock in failure path

2023-06-21T13:45:36+00:00

[ Upstream commit 60ecaaf54886b0642d5c4744f7fbf1ff0d6b3e42 ] smatch warning - 1) drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3615 gfx_v9_0_kiq_resume() warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'. 2) drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:6901 gfx_v10_0_kiq_resume() warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'. Signed-off-by: Sukrut Bellary Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/atomic: Don't pollute crtc_state->mode_blob with error pointers

2023-06-14T09:10:00+00:00

commit 439cf34c8e0a8a33d8c15a31be1b7423426bc765 upstream. Make sure we don't assign an error pointer to crtc_state->mode_blob as that will break all kinds of places that assume either NULL or a valid pointer (eg. drm_property_blob_put()). Cc: stable@vger.kernel.org Reported-by: fuyufan Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220209091928.14766-1-ville.syrjala@linux.intel.com Acked-by: Maxime Ripard Signed-off-by: Fedor Pchelkin Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix xclk freq on CHIP_STONEY

2023-06-14T09:09:49+00:00

commit b447b079cf3a9971ea4d31301e673f49612ccc18 upstream. According to Alex, most APUs from that time seem to have the same issue (vbios says 48Mhz, actual is 100Mhz). I only have a CHIP_STONEY so I limit the fixup to CHIP_STONEY Signed-off-by: Chia-I Wu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/rcar: stop using 'imply' for dependencies

2023-06-09T08:30:18+00:00

commit 42d95d1b3a9c649bf5ee881fee5938e00126479a upstream. The meaning of the 'imply' keyword has changed recently, and neither the old meaning (select the symbol if its dependencies are met) nor the new meaning (enable it by default, but let the user set any other setting) is what we want here. Work around this by adding two more Kconfig options that lead to the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS are enabled, that portion of the driver becomes usable, and no configuration results in a link error. This avoids a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin': rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable' arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': Link: https://lore.kernel.org/all/20200417155553.675905-5-arnd@arndb.de/ Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Reviewed-by: Randy Dunlap Signed-off-by: Laurent Pinchart Cc: Dan Carpenter Signed-off-by: Greg Kroah-Hartman