summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2025-06-16drm/client: Include <linux/export.h>Thomas Zimmermann8-0/+10
Fixes the compile-time warnings drivers/gpu/drm/clients/drm_client_setup.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_client.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_client_event.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_client_modeset.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fb_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fbdev_dma.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fbdev_shmem.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fbdev_ttm.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") Reviewed-by: André Almeida <andrealmeid@igalia.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612121633.229222-5-tzimmermann@suse.de
2025-06-16drm/bridge: Include <linux/export.h>Thomas Zimmermann13-0/+16
Fix compile-time warnings drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/analogix/analogix_dp_core.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/aux-bridge.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/aux-hpd-bridge.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/imx/imx-legacy-bridge.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/panel.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/samsung-dsim.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_bridge.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_bridge_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") Reviewed-by: André Almeida <andrealmeid@igalia.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612121633.229222-4-tzimmermann@suse.de
2025-06-16drm: Include <linux/export.h>Thomas Zimmermann39-1/+46
Fix the compile-time warnings drivers/gpu/drm/drm_atomic.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_state_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_uapi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_auth.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_buddy.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_color_mgmt.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_connector.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_damage_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_debugfs_crc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_drv.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_edid.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_exec.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fb_dma_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_file.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_flip_work.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_format_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_gpusvm.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_gpuvm.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_managed.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mipi_dbi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mipi_dsi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mode_config.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_modeset_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_modeset_lock.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_panic.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_plane.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_plane_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_print.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_privacy_screen.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_self_refresh_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_simple_kms_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_suballoc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_syncobj.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_vblank_work.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_vma_manager.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_writeback.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/lib/drm_random.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/tests/drm_kunit_helpers.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") Reviewed-by: André Almeida <andrealmeid@igalia.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612121633.229222-3-tzimmermann@suse.de
2025-06-16drm: Do not include <linux/export.h>Thomas Zimmermann1-1/+0
Fix the compile-time error drivers/gpu/drm/drm_pci.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 7d95680d64ac ("scripts/misc-check: check unnecessary #include <linux/export.h> when W=1") Reviewed-by: André Almeida <andrealmeid@igalia.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612121633.229222-2-tzimmermann@suse.de
2025-06-16drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTALVille Syrjälä1-2/+2
BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1 instead of vtotal. Make it so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314150136.22564-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 7b3685c9b38c3097f465efec8b24dbed63258cf6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-16drm/i915/pmu: Fix build error with GCOV and AutoFDO enabledTzung-Bi Shih1-2/+2
i915_pmu.c may fail to build with GCOV and AutoFDO enabled. ../drivers/gpu/drm/i915/i915_pmu.c:116:3: error: call to '__compiletime_assert_487' declared with 'error' attribute: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1 116 | BUILD_BUG_ON(bit > | ^ Here is a way to reproduce the issue: $ git checkout v6.15 $ mkdir build $ ./scripts/kconfig/merge_config.sh -O build -n -m <(cat <<EOF CONFIG_DRM=y CONFIG_PCI=y CONFIG_DRM_I915=y CONFIG_PERF_EVENTS=y CONFIG_DEBUG_FS=y CONFIG_GCOV_KERNEL=y CONFIG_GCOV_PROFILE_ALL=y CONFIG_AUTOFDO_CLANG=y EOF ) $ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \ olddefconfig $ PATH=${PATH}:${HOME}/llvm-20.1.5-x86_64/bin make LLVM=1 O=build \ CLANG_AUTOFDO_PROFILE=...PATH_TO_SOME_AFDO_PROFILE... \ drivers/gpu/drm/i915/i915_pmu.o Although not super sure what happened, by reviewing the code, it should depend on `__builtin_constant_p(bit)` directly instead of assuming `__builtin_constant_p(config)` makes `bit` a builtin constant. Also fix a nit, to reuse the `bit` local variable. Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32") Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250612083023.562585-1-tzungbi@kernel.org (cherry picked from commit 686d773186bf72b739bab7e12eb8665d914676ee) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2025-06-14drm/msm: Fix inverted WARN_ON() logicRob Clark1-1/+1
We want to WARN_ON() if info is NULL. Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 0838fc3e6718 ("drm/msm/adreno: Check for recognized GPU before bind") Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reported-by: Alexey Klimov <alexey.klimov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/658631/
2025-06-14drm/i915/dsi: Assert that vfp+vsync+vbp == vtotal on BXT/GLKVille Syrjälä1-1/+4
Windows code seems to do some dodgy looking +/-1 adjustments to some of the vertical timings. Not sure if that's correct or not, but let's at least cross check some of the values we got from the hardware to double check whether the GOP did the same or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314150136.22564-3-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2025-06-14drm/i915/dsi: Fix off by one in BXT_MIPI_TRANS_VTOTALVille Syrjälä1-2/+2
BXT_MIPI_TRANS_VTOTAL must be programmed with vtotal-1 instead of vtotal. Make it so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314150136.22564-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-06-13drm/vkms: Compile all tests with CONFIG_DRM_VKMS_KUNIT_TESTMaíra Canal1-2/+5
The Kconfig option `CONFIG_DRM_VKMS_KUNIT_TESTS` does not exist. However, the VKMS format tests use such an option for compilation, meaning that they are not compiled at all. Use the Kconfig option `CONFIG_DRM_VKMS_KUNIT_TEST` to compile all VKMS KUnit tests. Fixes: 3e897853debd ("drm/vkms: Create KUnit tests for YUV conversions") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20250611205704.334527-1-mcanal@igalia.com Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
2025-06-13drm/nouveau/bl: increase buffer size to avoid truncate warningJacob Keller1-1/+1
The nouveau_get_backlight_name() function generates a unique name for the backlight interface, appending an id from 1 to 99 for all backlight devices after the first. GCC 15 (and likely other compilers) produce the following -Wformat-truncation warning: nouveau_backlight.c: In function ‘nouveau_backlight_init’: nouveau_backlight.c:56:69: error: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 3 [-Werror=format-truncation=] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~ In function ‘nouveau_get_backlight_name’, inlined from ‘nouveau_backlight_init’ at nouveau_backlight.c:351:7: nouveau_backlight.c:56:56: note: directive argument in the range [1, 2147483647] 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~ nouveau_backlight.c:56:17: note: ‘snprintf’ output between 14 and 23 bytes into a destination of size 15 56 | snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The warning started appearing after commit ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") This fix for the ida usage removed the explicit value check for ids larger than 99. The compiler is unable to intuit that the ida_alloc_max() limits the returned value range between 0 and 99. Because the compiler can no longer infer that the number ranges from 0 to 99, it thinks that it could use as many as 11 digits (10 + the potential - sign for negative numbers). The warning has gone unfixed for some time, with at least one kernel test robot report. The code breaks W=1 builds, which is especially frustrating with the introduction of CONFIG_WERROR. The string is stored temporarily on the stack and then copied into the device name. Its not a big deal to use 11 more bytes of stack rounding out to an even 24 bytes. Increase BL_NAME_SIZE to 24 to avoid the truncation warning. This fixes the W=1 builds that include this driver. Compile tested only. Fixes: ab244be47a8f ("drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name()") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312050324.0kv4PnfZ-lkp@intel.com/ Suggested-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20250610-jk-nouveua-drm-bl-snprintf-fix-v2-1-7fdd4b84b48e@intel.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()Zhi Wang1-5/+12
The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") Signed-off-by: Zhi Wang <zhiw@nvidia.com> Link: https://lore.kernel.org/r/20250527163712.3444-1-zhiw@nvidia.com [ Rebase onto Blackwell changes. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-06-13drm/nouveau/gsp: Fix potential integer overflow on integer shiftsColin Ian King1-1/+1
The left shift int 32 bit integer constants 1 is evaluated using 32 bit arithmetic and then assigned to a 64 bit unsigned integer. In the case where the shift is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. Fixes: 6c3ac7bcfcff ("drm/nouveau/gsp: support deeper page tables in COPY_SERVER_RESERVED_PDES") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250522131512.2768310-1-colin.i.king@gmail.com
2025-06-13Revert "drm/prime: remove drm_prime_lookup_buf_by_handle"Christian König3-10/+49
This reverts commit c2aa5603af309968a10f8e0d929ec7662ada5f78. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://lore.kernel.org/r/aEwls5hPP9p-DPtt@phenom.ffwll.local
2025-06-13drm/format-helper: Update tests after BT.601 changesThomas Zimmermann1-6/+6
Commit a979a54165c2 ("drm/format-helper: Normalize BT.601 factors to 256") improved rounding precision of the BT.601 calculation, which impacts the results of soem of the format-helper tests. Adapt the test to the new results. v2: - fix spelling in commit description Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a979a54165c2 ("drm/format-helper: Normalize BT.601 factors to 256") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250613111711.136993-1-tzimmermann@suse.de
2025-06-13drm/xe: Make dma-fences compliant with the safe access rulesTvrtko Ursulin3-1/+11
Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a sync_fence fd) which will then cause an use- after-free on subsequent access. To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence. For the timeline name we simply make the queue be freed via kfree_rcu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250610164226.10817-5-tvrtko.ursulin@igalia.com
2025-06-13drm/i915: Protect access to driver and timeline nameTvrtko Ursulin3-6/+21
Protect the access to driver and timeline name which otherwise could be freed as dma-fence exported is signalling fences. This prepares the code for incoming dma-fence API changes which will start asserting these accesses are done from a RCU locked section. Now that the safe access is handled in the dma-fence API, the external callers such as sync_file, and our internal code paths, we can drop the similar protection from i915_fence_get_timeline_name(). This prepares the code for incoming dma-fence API changes which will start asserting these accesses are done from a RCU locked section. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> # v1 Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250610164226.10817-3-tvrtko.ursulin@igalia.com
2025-06-13drm/xe/vm: Add a helper xe_vm_range_tilemask_tlb_invalidation()Himal Prasad Ghimiray5-101/+75
Introduce xe_vm_range_tilemask_tlb_invalidation(), which issues a TLB invalidation for a specified address range across GTs indicated by a tilemask. v2 (Matthew Brost) - Move WARN_ON_ONCE to svm caller - Remove xe_gt_tlb_invalidation_vma - s/XE_WARN_ON/WARN_ON_ONCE v3 - Rebase Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250609041616.1723636-1-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-06-13drm/mgag200: Do not include <linux/export.h>Thomas Zimmermann1-1/+0
Fix the compile-time warning drivers/gpu/drm/mgag200/mgag200_ddc.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250612085308.203861-1-tzimmermann@suse.de
2025-06-13drm/ast: Do not include <linux/export.h>Thomas Zimmermann1-1/+0
Fix the compile-time warning drivers/gpu/drm/ast/ast_mode.c: warning: EXPORT_SYMBOL() is not used, but #include <linux/export.h> is present Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250612084257.200907-1-tzimmermann@suse.de
2025-06-13drm/format-helper: Normalize BT.601 factors to 256Thomas Zimmermann1-1/+1
BT.601 weights RGB components by certain factors to convert the color to grayscale. Normalize the constants to 256 instead of 10. Allows for slightly more precise rounding. The division by 256 can be compiled as an 8-bit shift, which might be faster on some hardware. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250603161158.423962-1-tzimmermann@suse.de
2025-06-13drm/xe/bmg: Update Wa_14022085890Vinay Belgaumkar2-0/+9
Set GT min frequency to 1200Mhz once driver load is complete. v2: Review comments (Rodrigo) v3: Apply Wa earlier so user_req_min is not clobbered. v4: Apply to all GTs (Lucas) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-3-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-13drm/xe/bmg: Update Wa_16023588340Vinay Belgaumkar1-1/+1
This allows for additional L2 caching modes. Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340") Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-2-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-13drm/xe/guc: Ignore GuC CT errors when wedgedVinay Belgaumkar1-5/+5
Messaging to GuC may get canceled when device is wedged. Don't flag this as an error in xe_guc_pc code. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250612-wa-14022085890-v4-1-94ba5dcc1e30@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-13Merge tag 'drm-misc-fixes-2025-06-12' of ↵Dave Airlie4-28/+42
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.16-rc2: - Fix infinite EPROBE_DEFER loop in vc4 probing. - Fix amdxdna firmware size. - mode fixes for meson. - Kconfig fix for st7171-i2c. - Fix -EBUSY WARN_ON_ONCE in dma-buf - Use dma_sync_sgtable_for_cpu in udmabuf. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/62c06195-8bc1-4dae-8777-e86d94e4d9d9@linux.intel.com
2025-06-13drm/xe: Add helper function to inject fault into ct_dead_capture()Satyanarayana K V P2-0/+26
When injecting fault to xe_guc_ct_send_recv() & xe_guc_mmio_send_recv() functions, the CI test systems are going out of space and crashing. To avoid this issue, a new helper function is created and when fault is injected into this xe_is_injection_active() helper function, ct dead capture is avoided which suppresses ct dumps in the log. Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250612080402.22011-1-satyanarayana.k.v.p@intel.com
2025-06-13drm/xe: Fix early wedge on GuC load failureDaniele Ceraolo Spurio4-2/+21
When the GuC fails to load we declare the device wedged. However, the very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done before the GT1 GuC objects are initialized, so things go bad when the wedge code attempts to cleanup GT1. To fix this, check the initialization status in the functions called during wedge. Fixes: 7dbe8af13c18 ("drm/xe: Wedge the entire device") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Zhanjun Dong <zhanjun.dong@intel.com> Cc: stable@vger.kernel.org # v6.12+: 1e1981b16bb1: drm/xe: Fix taking invalid lock on wedge Cc: stable@vger.kernel.org # v6.12+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250611214453.1159846-2-daniele.ceraolospurio@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-06-12drm: renesas: rz-du: mipi_dsi: Add function pointers for configuring VCLK ↵Lad Prabhakar1-20/+45
and mode validation Introduce `dphy_conf_clks` and `dphy_mode_clk_check` callbacks in `rzg2l_mipi_dsi_hw_info` to configure the VCLK and validate supported display modes. On the RZ/V2H(P) SoC, the DSI PLL dividers need to be as accurate as possible. To ensure compatibility with both RZ/G2L and RZ/V2H(P) SoCs, function pointers are introduced. Modify `rzg2l_mipi_dsi_startup()` to use `dphy_conf_clks` for clock configuration and `rzg2l_mipi_dsi_bridge_mode_valid()` to invoke `dphy_mode_clk_check` for mode validation. This change ensures proper operation across different SoC variants by allowing fine-grained control over clock configuration and mode validation. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-10-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Add dphy_late_init() callback for RZ/V2H(P)Lad Prabhakar1-0/+4
Introduce the `dphy_late_init` callback in `rzg2l_mipi_dsi_hw_info` to allow additional D-PHY register configurations after enabling data and clock lanes. This is required for the RZ/V2H(P) SoC but not for the RZ/G2L SoC. Modify `rzg2l_mipi_dsi_startup()` to invoke `dphy_late_init` if defined, ensuring SoC-specific initialization is performed only when necessary. This change prepares for RZ/V2H(P) SoC support while maintaining compatibility with existing platforms. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-9-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Add feature flag for 16BPP supportLad Prabhakar1-0/+11
Introduce the `RZ_MIPI_DSI_FEATURE_16BPP` flag in `rzg2l_mipi_dsi_hw_info` to indicate support for 16BPP pixel formats. The RZ/V2H(P) SoC supports 16BPP, whereas this feature is missing on the RZ/G2L SoC. Update the `mipi_dsi_host_attach()` function to check this flag before allowing 16BPP formats. If the SoC does not support 16BPP, return an error to prevent incorrect format selection. This change enables finer-grained format support control for different SoC variants. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-8-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Use mHz for D-PHY frequency calculationsLad Prabhakar1-5/+8
Pass the HSFREQ in milli-Hz to the `dphy_init()` callback to improve precision, especially for the RZ/V2H(P) SoC, where PLL dividers require high accuracy. These changes prepare the driver for upcoming RZ/V2H(P) SoC support. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-7-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Make "rst" reset control optional for RZ/V2H(P)Lad Prabhakar1-1/+1
In preparation for adding support for the Renesas RZ/V2H(P) SoC, make the "rst" reset control optional in the MIPI DSI driver. The RZ/V2H(P) SoC does not provide this reset line, and attempting to acquire it using the mandatory API causes probe failure. Switching to devm_reset_control_get_optional_exclusive() ensures compatibility with both SoCs that provide this reset line and those that do not, such as RZ/V2H(P). Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-6-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Add OF data supportLad Prabhakar2-15/+38
n preparation for adding support for the Renesas RZ/V2H(P) SoC, this patch introduces a mechanism to pass SoC-specific information via OF data in the DSI driver. This enables the driver to adapt dynamically to various SoC-specific requirements without hardcoding configurations. The MIPI DSI interface on the RZ/V2H(P) SoC is nearly identical to the one on the RZ/G2L SoC. While the LINK registers are shared between the two SoCs, the D-PHY registers differ. Also the VCLK range differs on both these SoCs. To accommodate these differences `struct rzg2l_mipi_dsi_hw_info` is introduced and as now passed as OF data. These changes lay the groundwork for the upcoming RZ/V2H(P) SoC support by allowing SoC-specific data to be passed through OF. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-5-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Use VCLK for HSFREQ calculationLad Prabhakar1-17/+23
Update the RZ/G2L MIPI DSI driver to calculate HSFREQ using the actual VCLK rate instead of the mode clock. The relationship between HSCLK and VCLK is: vclk * bpp <= hsclk * 8 * lanes Retrieve the VCLK rate using `clk_get_rate(dsi->vclk)`, ensuring that HSFREQ accurately reflects the clock rate set in hardware, leading to better precision in data transmission. Additionally, use `DIV_ROUND_CLOSEST_ULL` for a more precise division when computing `hsfreq`. Also, update unit conversions to use correct scaling factors for better clarity and correctness. Since `clk_get_rate()` returns the clock rate in Hz, update the HSFREQ threshold comparisons to use Hz instead of kHz to ensure correct behavior. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-4-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Simplify HSFREQ calculationLad Prabhakar1-2/+2
Simplify the high-speed clock frequency (HSFREQ) calculation by removing the redundant multiplication and division by 8. The updated equation: hsfreq = mode->clock * bpp / dsi->lanes; produces the same result while improving readability and clarity. Additionally, update the comment to clarify the relationship between HS clock bit frequency, HS byte clock frequency, and HSFREQ. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-3-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: renesas: rz-du: mipi_dsi: Add min check for VCLK rangeLad Prabhakar1-0/+3
The VCLK range for Renesas RZ/G2L SoC is 5.803 MHz to 148.5 MHz. Add a minimum clock check in the mode_valid callback to ensure that the clock value does not fall below the valid range. Co-developed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250609225630.502888-2-prabhakar.mahadev-lad.rj@bp.renesas.com
2025-06-12drm: omapdrm: reduce clang stack usageArnd Bergmann1-1/+1
The thread sanitizer makes the stack usage explode from extra variable spills in dispc_runtime_resume: drivers/gpu/drm/omapdrm/dss/dispc.c:4735:27: error: stack frame size (1824) exceeds limit (1280) in 'dispc_runtime_resume' [-Werror,-Wframe-larger-than] I could not figure out what exactly is going on here, but I see that whenever dispc_restore_context() is not inlined, that function and its caller shrink below 900 bytes combined of stack usage. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250610092737.2641862-1-arnd@kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2025-06-12drm/xe: Make WA BB part of LRC BOMatthew Brost2-21/+18
No idea why, but without this GuC context switches randomly fail when running IGTs in a loop. Need to follow up why this fixes the aforementioned issue but can live with a stable driver for now. Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Tested-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250612031925.4009701-1-matthew.brost@intel.com
2025-06-12drm/i915/dp: Disable the AUX DPCD probe quirk if it's not requiredImre Deak4-2/+38
Reading DPCD registers has side-effects and some of these can cause a problem for instance during link training. Based on this it's better to avoid the probing quirk done before each DPCD register read, limiting this to the monitor which requires it. The only known problematic monitor is an external SST sink, so keep the quirk disabled always for eDP and MST sinks. Reenable the quirk after a hotplug event and after resuming from a power state without hotplug support, until the subsequent EDID based detection. v2: Add a helper for determining the need/setting the probing. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250609125556.109538-2-imre.deak@intel.com
2025-06-12drm/dp: Add an EDID quirk for the DPCD register access probeImre Deak2-13/+37
Reading DPCD registers has side-effects and some of these can cause a problem for instance during link training. Based on this it's better to avoid the probing quirk done before each DPCD register read, limiting this to the monitor which requires it. Add an EDID quirk for this. Leave the quirk enabled by default, allowing it to be disabled after the monitor is detected. v2: Fix lockdep wrt. drm_dp_aux::hw_mutex when calling drm_dp_dpcd_set_probe_quirk() with a dependent lock already held. v3: Add a helper for determining if DPCD probing is needed. (Jani) v4: - s/drm_dp_dpcd_set_probe_quirk/drm_dp_dpcd_set_probe (Jani) - Fix documentation of drm_dp_dpcd_set_probe(). - Add comment at the end of internal quirk entries. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250609125556.109538-1-imre.deak@intel.com
2025-06-12drm/xe: Use WRITE_ONCE for range->tile_invalidated updateMatthew Brost1-2/+5
Updating range->tile_invalidated should be done with WRITE_ONCE to pair with READ_ONCE in opportunistic checks. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhrost <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250604234712.2441130-1-matthew.brost@intel.com
2025-06-12drm/xe: Don't use drm exec locking in SVM pagefaultsMatthew Brost1-23/+13
Only the VM dma-resv lock is needed in SVM pagefaults so xe_vm_lock/unlock can be used instead of drm exec. Micro optimization but should save some CPU cycles in a critical path. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://lore.kernel.org/r/20250603174012.2195759-1-matthew.brost@intel.com
2025-06-12drm/edid: Add support for quirks visible to DRM core and driversImre Deak1-1/+7
Add support for EDID based quirks which can be queried outside of the EDID parser iteself by DRM core and drivers. There are at least two such quirks applicable to all drivers: the DPCD register access probe quirk and the 128b/132b DPRX Lane Count Conversion quirk (see 3.5.2.16.3 in the v2.1a DP Standard). The latter quirk applies to panels with specific EDID panel names, support for defining a quirk this way will be added as a follow-up. v2: Reset global_quirks in drm_reset_display_info(). v3: (Jani) - Use one list for both the global and internal quirks. - Drop change for panel name specific quirks. - Add comment about the way quirks should be queried. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250605082850.65136-4-imre.deak@intel.com
2025-06-12drm/edid: Define the quirks in an enum listImre Deak1-106/+112
An enum list is better suited to define a quirk list, do that. This makes looking up a quirk more robust and also allows for separating quirks internal to the EDID parser and global quirks which can be queried outside of the EDID parser (added as a follow-up). Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250605082850.65136-3-imre.deak@intel.com
2025-06-12drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUSImre Deak1-1/+1
Reading DPCD registers has side-effects in general. In particular accessing registers outside of the link training register range (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) is explicitly forbidden by the DP v2.1 Standard, see 3.6.5.1 DPTX AUX Transaction Handling Mandates 3.6.7.4 128b/132b DP Link Layer LTTPR Link Training Mandates Based on my tests, accessing the DPCD_REV register during the link training of an UHBR TBT DP tunnel sink leads to link training failures. Solve the above by using the DP_LANE0_1_STATUS (0x202) register for the DPCD register access quirk. Cc: <stable@vger.kernel.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250605082850.65136-2-imre.deak@intel.com
2025-06-12drm/xe/lrc: Use a temporary buffer for WA BBLucas De Marchi1-4/+20
In case the BO is in iomem, we can't simply take the vaddr and write to it. Instead, prepare a separate buffer that is later copied into io memory. Right now it's just a few words that could be using xe_map_write32(), but the intention is to grow the WA BB for other uses. Fixes: 617d824c5323 ("drm/xe: Add WA BB to capture active context utilization") Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250604-wa-bb-fix-v1-1-0dfc5dafcef0@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit ef48715b2d3df17c060e23b9aa636af3d95652f8) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2025-06-12drm/prime: remove drm_prime_lookup_buf_by_handleChristian König3-49/+10
This was added by Sima +10 years ago as a solution to avoid exporting multiple dma-bufs for the same GEM object. I tried to remove it before, but wasn't 100% sure about all the side effects. Now Thomas recent modified drm_gem_prime_handle_to_dmabuf() which makes it obvious that this is a superflous step. We try to look up the DMA-buf by handle handle and if that fails for some reason (must likely because the handle is a duplicate) the code just use the DMA-buf from the GEM object. Just using the DMA-buf from the GEM object in the first place has the same effect as far as I can see. Some more history from Sima: In d0b2c5334f41 ("drm/prime: Always add exported buffers to the handle cache") I added this additional lookup. It wasn't part of the bugfix, but back then the handle list was just a linked list and you could do lookups in either direction. And I guess I felt like doing a quick lookup before we grab the next lock makes sense. Premature optimization, I'm confessing to the crime guilty as charged :-/ Then Chris Wilson in 077675c1e8a1 ("drm: Convert prime dma-buf <-> handle to rbtree") and added 2 rb trees to support both directions. At that point that handle2buf lookup really didn't make much sense anymore, but we just kept it and it's been in the tree confusing people ever since. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20250604113234.2520-1-christian.koenig@amd.com
2025-06-12drm/file: add client id to drm_file_errorSunil Khatri1-2/+4
Add client id to the drm_file_error api, client id is a unique id for each drm fd and is quite useful for debugging. v2: Swapped client id and client name order [Chrisitan] Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250530062929.1954784-1-sunil.khatri@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2025-06-12drm/arm/malidp: Silence informational messageAlexander Stein1-1/+1
When checking for unsupported expect an error is printed every time. This spams the log for platforms where this is expected, e.g. ls1028a having a Vivante (etnaviv) GPU and Mali display processor. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250523064042.3275926-1-alexander.stein@ew.tq-group.com
2025-06-12drm/ssd130x: fix ssd132x_clear_screen() columnsJohn Keeping1-1/+1
The number of columns relates to the width, not the height. Use the correct variable. Signed-off-by: John Keeping <jkeeping@inmusicbrands.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: fdd591e00a9c ("drm/ssd130x: Add support for the SSD132x OLED controller family") Link: https://lore.kernel.org/r/20250611111307.1814876-1-jkeeping@inmusicbrands.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-21 08:02:05 +0300