summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-07-10drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs codeSimona Vetter
The object is potentially already gone after the drm_gem_object_put(). In general the object should be fully constructed before calling drm_gem_handle_create(), except the debugfs tracking uses a separate lock and list and separate flag to denotate whether the object is actually initialized. Since I'm touching this all anyway simplify this by only adding the object to the debugfs when it's ready for that, which allows us to delete that separate flag. panthor_gem_debugfs_bo_rm() already checks whether we've actually been added to the list or this is some error path cleanup. v2: Fix build issues for !CONFIG_DEBUGFS (Adrián) v3: Add linebreak and remove outdated comment (Liviu) Fixes: a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS") Cc: Adrián Larumbe <adrian.larumbe@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250709135220.1428931-1-simona.vetter@ffwll.ch
2025-07-09fbcon: Fix outdated registered_fb reference in commentShixiong Ou
The variable was renamed to fbcon_registered_fb, but this comment was not updated along with the change. Correct it to avoid confusion. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Fixes: efc3acbc105a ("fbcon: Maintain a private array of fb_info") [sima: Add Fixes: line.] Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20250709103438.572309-1-oushixiong1025@163.com
2025-07-09drm/ast: Gen7: Switch default registers to gen4+ stateThomas Zimmermann
Change the default register settings for Gen7 to mach Gen4 and later. Gen7 currently uses the settings for Gen1, which is most likely incorrect. Using Gen4+ settings enables E2M linear-access modes in VGACRA2. It appears to be related to the chip's PCIE2MBOX feature, which is unused. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-11-tzimmermann@suse.de
2025-07-09drm/ast: Gen7: Disable VGASR0[1] as on Gen4+Thomas Zimmermann
Set VGACRB6[5], which disables asynchronous sequencer resets via VGASR0[1]. This was most likely an oversight when adding support for Gen7. Aligns Gen7 with the earlier Gen4+. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-10-tzimmermann@suse.de
2025-07-09drm/ast: Split ast_set_def_ext_reg() by chip generationThomas Zimmermann
Duplicate ast_set_def_ext_reg() for individual chip generations and move call it into per-chip source files. Remove the original code. AST2100 and AST2500 reuse the function from earlier chips. AST2600 appears to be incorrect as it uses an older function. Keep this behavior for now. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-9-tzimmermann@suse.de
2025-07-09drm/ast: Handle known struct ast_dramstruct with helpersThomas Zimmermann
Most of struct ast_dramstruct stores hardware state. Some index values have known or special meaning. The known values are - 0xffff - Terminal entry in the array - 0xff00 - Delays the programming for usecs - 0x0004 - Sets the type of DRAM Add constants and helper macros for these cases. Also add a helper macro for testing. Update Gen1 and Gen2+ accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-8-tzimmermann@suse.de
2025-07-09drm/ast: Move struct ast_dramstruct to ast_post.hThomas Zimmermann
Declare struct ast_dramstruct in ast_post.h and remove its original header file. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-7-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen2+ and Gen1 POST code to separate source filesThomas Zimmermann
Move POST code for Gen2+ and Gen1 to separate source files and hide it in ast_2100_post() ans ast_2000_post(). With P2A configuration, the POST logic for these chip generations has been mingled in ast_init_dram_reg(). Hence, handle all generations in a single change. The split simplifies both cases. Also move the DRAM init tables for each Gen into the respective source file. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-6-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen4+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen4+ to separate source file and hide it in ast_2300_post(). With P2A configuration, it performs a full board POST and enables the transmitter chip; otherwise it only enables the transmitter chip. Also fix coding style in several places. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-5-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen6+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen6+ to separate source file and hide it in ast_2500_post(). With P2A configuration, it performs a full board POST; otherwise it enables the transmitter chip. No changes to the overall logic. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-4-tzimmermann@suse.de
2025-07-09drm/ast: Move Gen7+ POST code to separate source fileThomas Zimmermann
Move POST code for Gen7+ to separate source file and hide it in ast_2600_post(). There's not much going on here except for enabling the DP transmitter chip. v2: - simplify logic (Jocelyn) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-3-tzimmermann@suse.de
2025-07-09drm/ast: Declare helpers for POST in headerThomas Zimmermann
Provide POST helpers in header file before splitting up the AST POST code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250706162816.211552-2-tzimmermann@suse.de
2025-07-09dma-buf: heaps: Give default CMA heap a fixed nameJared Kangas
The CMA heap's name in devtmpfs can vary depending on how the heap is defined. Its name defaults to "reserved", but if a CMA area is defined in the devicetree, the heap takes on the devicetree node's name, such as "default-pool" or "linux,cma". To simplify naming, unconditionally name it "default_cma_region", but keep a legacy node in place backed by the same underlying allocator for backwards compatibility. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250610131231.1724627-4-jkangas@redhat.com
2025-07-09dma-buf: heaps: Parameterize heap name in __add_cma_heap()Jared Kangas
Prepare for the introduction of a fixed-name CMA heap by replacing the unused void pointer parameter in __add_cma_heap() with the heap name. Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: John Stultz <jstultz@google.com> Signed-off-by: Jared Kangas <jkangas@redhat.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250610131231.1724627-3-jkangas@redhat.com
2025-07-09dma-buf: system_heap: No separate allocation for attachment sg_tablesT.J. Mercier
struct dma_heap_attachment is a separate allocation from the struct sg_table it contains, but there is no reason for this. Let's use the slab allocator just once instead of twice for dma_heap_attachment. Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://lore.kernel.org/r/20250417180943.1559755-1-tjmercier@google.com
2025-07-09drm/sched: Consolidate drm_sched_rq_select_entity_rrTvrtko Ursulin
Extract out two copies of the identical code to drm_sched_rq_select_entity_rr()'s epilogue to make it smaller and more readable. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Philipp Stanner <phasta@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> [phasta: commit message] Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250708122121.75689-1-tvrtko.ursulin@igalia.com
2025-07-09drm/sti: hda: convert to devm_drm_bridge_alloc() APILuca Ceresoli
devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API") and following commits. The lack of conversion for this driver is a bug since commit a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") which is the first commmit having added a drm_bridge_get/put() pair and thus exposing the incorrect initial refcount issue. Fix this by switching the driver to the new API. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-2-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-09drm/sti: hdmi: convert to devm_drm_bridge_alloc() APILuca Ceresoli
devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. This driver was missed during the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API") and following commits. The lack of conversion for this driver is a bug since commit a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") which is the first commmit having added a drm_bridge_get/put() pair and thus exposing the incorrect initial refcount issue. Fix this by switching the driver to the new API. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/ce9c6aa3-5372-468f-a4bf-5a261259e459@samsung.com/ Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250708-drm-bridge-convert-to-alloc-api-leftovers-v1-1-6285de8c3759@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-09drm/amdgpu: fix the logic to validate fpriv and root boSunil Khatri
Fix the smatch warning, smatch warnings: drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:2146 amdgpu_pt_info_read() error: we previously assumed 'fpriv' could be null (see line 2146) "if (!fpriv && !fpriv->vm.root.bo)", It has to be an OR condition rather than an AND which makes an NULL dereference in case fpriv is NULL. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507090525.9rDWGhz3-lkp@intel.com/ Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20250709071618.591866-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-07-09drm/amdgpu: fix MQD debugfs undefined symbol when DEBUG_FS=nSunil Khatri
Fix undefined reference to amdgpu_mqd_info_fops during debugfs_create_file if DEBUG_FS=n Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Link: https://lore.kernel.org/r/20250708101551.68033-1-sunil.khatri@amd.com Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2025-07-08gpu/trace: make TRACE_GPU_MEM configurableJuston Li
Move the source to a better place in Device Drivers -> Graphics support now that its configurable. v4: - Move source location (Tvrtko) v3: - Patch introduced to replace per-driver config (Lucas) Signed-off-by: Juston Li <justonli@chromium.org> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250611225145.1739201-1-justonli@chromium.org Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-07-08drm/rockchip: vop2: Fix the update of LAYER/PORT select registers when there ↵Andy Yan
are multi display output on rk3588/rk3568 The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL and OVL_PORT_SEL registers, and the configuration of these two registers can be set to take effect when the vsync signal arrives at a certain Video Port. If two threads for two display output choose to update these two registers simultaneously to meet their own plane adjustment requirements(change plane zpos or switch plane from one crtc to another), then no matter which Video Port'svsync signal we choose to follow for these two registers, the display output of the other Video Port will be abnormal. This is because the configuration of this Video Port does not take effect at the right time (its configuration should take effect when its VSYNC signal arrives). In order to solve this problem, when performing plane migration or change the zpos of planes, there are two things to be observed and followed: 1. When a plane is migrated from one VP to another, the configuration of the layer can only take effect after the Port mux configuration is enabled. 2. When change the zpos of planes, we must ensure that the change for the previous VP takes effect before we proceed to change the next VP. Otherwise, the new configuration might overwrite the previous one for the previous VP, or it could lead to the configuration of the previous VP being take effect along with the VSYNC of the new VP. This issue only occurs in scenarios where multi-display output is enabled. Fixes: c5996e4ab109 ("drm/rockchip: vop2: Make overlay layer select register configuration take effect by vsync") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250421102156.424480-1-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Simpify clk get/enable by devm_clk_get_enabled apiAndy Yan
Make use of devm_clk_get_enabled() to replace devm_clk_get() and clk_prepare_enable(), which will make the cleanup of clk code simpler. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-9-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: switch i2c registration to devm functionsAndy Yan
Switch from i2c_add_adapter() to resource managed devm_i2c_add_adapter(), which will make the cleanup code more simpler. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-8-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Use sleep_range instead of udelayAndy Yan
usleep_range is preferred over udelay. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-7-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Move ddc/i2c configuration and HOTPLUG unmute to ↵Andy Yan
inno_hdmi_init_hw Putting these scattered initialization code together is helpful for the following migration to the DRM bridge driver mode. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-6-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Rename function inno_hdmi_reset to inno_hdmi_init_hwAndy Yan
This function not only configure hardware reset register, but also do some other configurations. Therefore, it is more appropriate to name it inno_hdmi_init_hw, which will also facilitate the addition of other functions to this function in the following patch. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-5-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Remove unnecessary parentheses to make checkpatch happyAndy Yan
Remove unnecessary parentheses to make checkpatch happy. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-4-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Refactor register macros to make checkpatch happyAndy Yan
1. Prefer using the BIT macro 2. Macro argument 'n' as '(n)' to avoid precedence issues 3. Add a blank line after enum declarations Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-3-andyshrk@163.com
2025-07-08drm/rockchip: inno_hdmi: Merge register definition to c fileAndy Yan
Since this register definition is only use in one single c file, there is no need to put it in a separate header. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250512124615.2848731-2-andyshrk@163.com
2025-07-08drm/rockchip: dw_hdmi: Use dev_err_probe() to simplify codeYumeng Fang
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. Signed-off-by: Yumeng Fang <fang.yumeng@zte.com.cn> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250515203554564-j1jBXUXR6bdiN6zARicC@zte.com.cn
2025-07-08drm/rockchip: cdn-dp: Convert to drm bridgeChaoyi Chen
Convert it to drm bridge driver, it will be convenient for us to migrate the connector part to the display driver later. Considering that some code depend on the connector, the following changes have been made: - Only process edid in &drm_bridge_funcs.edid_read(), so no need to store additional edid info. - Now cdn_dp_get_sink_capability() only focused on reading DPCD_REV. - Update bpc info in cdn_dp_bridge_atomic_enable() instead of cdn_dp_encoder_mode_set(). Actually, the bpc data will be used in cdn_dp_bridge_atomic_enable(). - Switch to use DRM_BRIDGE_OP_DP_AUDIO helpers. This patch also convert to use devm_drm_bridge_alloc() API. Tested with RK3399 EVB IND board. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250529071334.441-1-kernel@airkyi.com
2025-07-08drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-portHeiko Stuebner
Each window of a vop2 is usable by a specific set of video ports, so while binding the vop2, we look through the list of available windows trying to find one designated as primary-plane and usable by that specific port. The code later wants to use drm_crtc_init_with_planes with that found primary plane, but nothing has checked so far if a primary plane was actually found. For whatever reason, the rk3576 vp2 does not have a usable primary window (if vp0 is also in use) which brought the issue to light and ended in a null-pointer dereference further down. As we expect a primary-plane to exist for a video-port, add a check at the end of the window-iteration and fail probing if none was found. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250610212748.1062375-1-heiko@sntech.de
2025-07-08drm/rockchip: lvds: Convert to drm bridgeChaoyi Chen
Convert it to drm bridge driver, it will be convenient for us to migrate the connector part to the display driver later. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> [on a not-upstream px30 board with lvds display] Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250526015834.102-1-kernel@airkyi.com
2025-07-08Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst
Pull in drm-intel-next for the updates to drm panic handling. Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2025-07-08Merge tag 'drm-msm-next-2025-07-05' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/msm into drm-next Updates for v6.17 CI: - uprev mesa and ci-templates - use shallow clone to speed up build jobs - remove sdm845/cheza jobs. These runners are no more (RIP dear chezas) - fix runner tag for i915 cml runners - uprev igt to pull in msm test fixes Core: - VM_BIND support! - single source of truth for UBWC configuration. Adds a global soc driver for UBWC config which is used from display and GPU. (And later vidc/camera/etc) - Decouple ties between GPU and KMS, adding a `separate_gpu_kms` modparam to allow the GPU and KMS to bind to separate DRM devices. This should better deal with more exotic SoC configurations where the number of GPUs is different from number of DPUs. The default behavior is to still come up as a single unified DRM device to avoid surprising userspace. DP: - major rework of the I/O accessors DPU: - use version checks instead of feature bits - SM8750 support - set min_prefill_lines for SC8180X DSI: - SM8750 support GPU: - speedbin support for X1-85 - X1-45 support MDSS: - SM8750 support Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Robin Clark <robin.clark@oss.qualcomm.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACSVV0217R+kpoWQJeuYGHf6q_4aFyEJuKa=dZZKOnLQzFwppg@mail.gmail.com
2025-07-08Merge tag 'drm-intel-next-2025-07-04' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull #2 for v6.17: Features and functionality: - Add drm_panic support for both i915 and xe drivers (Jocelyn Falempe) - Add initial flip queue implementation, disabled by default, for LNL and PTL (Ville) - Add support for Wildcat Lake (WCL) display, version 30.02 (Matt Roper, Matt Atwood, Dnyaneshwar) - Extend drm_panel and follower support to DDI eDP (Arun) Refactoring and cleanups: - Make all global state objects opaque (Jani) - Move display works to display specific unordered workqueue (Luca) - Add and use struct drm_device based pcode interface (Jani, Lucas) - Use clamp() instead of max()+min() combo (Ankit) - Simplify wait for power well disable (Jani) - Various stylistics cleanups and renames (Jani) Fixes: - Deal with loss of pipe DMC state (Ville) - Fix PTL HDCP2 stream status check (Suraj) - Add workaround for ADL-P DKL PHY DP and HDMI (Nemesa) - Fix skl_print_wm_changes() stack usage with KMSAN (Arnd Bergmann) - Fix PCON capability reads on non-branch devices (Chaitanya) - Fix which platforms have ultra joiner (Ankit) DRM core changes: - Add ttm_bo_kmap_try_from_panic() for xe drm_panic support (Jocelyn Falempe) - Add private pointer to struct drm_scanout buffer for xe/i915 drm_panic support (Jocelyn Falempe) Merges: - Backmerge drm-next for drm_panel and xe changes (Jani) Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6d728bf6ef23681b00dfbc7da9aeae41042dee02@intel.com
2025-07-07drm/tegra: Use dma_buf from GEM object instanceThomas Zimmermann
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach an implementation detail of PRIME. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250619113100.70292-3-tzimmermann@suse.de
2025-07-07drm/tegra: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250619113100.70292-2-tzimmermann@suse.de
2025-07-07drm/vgem/vgem_drv convert to use faux_deviceGreg Kroah-Hartman
The vgem driver does not need to create a platform device, as there is no real platform resources associated it, it only did so because it was simple to do that in order to get a device to use for resource management of drm resources. Change the driver to use the faux device instead as this is NOT a real platform device. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/2025070114-iron-shiny-b92e@gregkh
2025-07-07drm/vkms: convert to use faux_deviceGreg Kroah-Hartman
The vkms driver does not need to create a platform device, as there is no real platform resources associated it, it only did so because it was simple to do that in order to get a device to use for resource management of drm resources. Change the driver to use the faux device instead as this is NOT a real platform device. Tested-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/2025070147-antics-pleat-edd2@gregkh
2025-07-07drm/gem-shmem: Do not map s/g table by defaultThomas Zimmermann
The vast majority of drivers that use GEM-SHMEM helpers do not use an s/g table for imported buffers; specifically all drivers that use DRM_GEM_SHMEM_DRIVER_OPS. Therefore convert the initializer macro to DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGT and remove the latter. This helps to avoid swiotbl errors, such as seen with some Aspeed systems ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) The error is caused by the system's limited DMA capabilities and can happen with any GEM-SHMEM-based driver. It results in a performance penalty. In the case of vgem and vkms, the devices do not support DMA at all, which can result in failure to map the buffer object into the kernel's address space. [1][2] Avoiding the s/g table fixes this problem. The other drivers based on GEM-SHMEM, imagination, lima, panfrost, panthor, v3d and virtio, use the s/g table of imported buffers. Neither driver uses the default initializer, so they won't be affected by this change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Zenghui Yu <zenghui.yu@linux.dev> Closes: https://lore.kernel.org/dri-devel/6d22bce3-4533-4cfa-96ba-64352b715741@linux.dev/ # [1] Reported-by: José Expósito <jose.exposito89@gmail.com> Closes: https://lore.kernel.org/dri-devel/20250311172054.2903-1-jose.exposito89@gmail.com/ # [2] Tested-by: Zenghui Yu <zenghui.yu@linux.dev> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://lore.kernel.org/r/20250630143537.309052-1-tzimmermann@suse.de
2025-07-07drm/bridge: tc358767: fix uninitialized variable regressionLuca Ceresoli
Commit a59a27176914 ("drm/bridge: tc358767: convert to devm_drm_bridge_alloc() API") split tc_probe_bridge_endpoint() in two functions, thus duplicating the loop over the endpoints in each of those functions. However it missed duplicating the of_graph_parse_endpoint() call which initializes the struct of_endpoint, resulting in an uninitialized read. Fixes: a59a27176914 ("drm/bridge: tc358767: convert to devm_drm_bridge_alloc() API") Cc: stable@vger.kernel.org Reported-by: Colin King (gmail) <colin.i.king@gmail.com> Closes: https://lore.kernel.org/all/056b34c3-c1ea-4b8c-9672-c98903ffd012@gmail.com/ Reviewed-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250704-drm-bridge-alloc-fix-tc358767-regression-v2-1-ec0e511bedd0@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-07drm/bridge: analogix_dp: Use devm_drm_bridge_alloc() APIMarek Szyprowski
devm_drm_bridge_alloc() is the new API to be used for allocating (and partially initializing) a private driver struct embedding a struct drm_bridge. Analogix DP driver somehow missed the automated conversion in commit 9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to devm_drm_bridge_alloc() API"), what causes the following warning: ------------[ cut here ]------------ WARNING: lib/refcount.c:25 at drm_bridge_attach+0x2c/0x248, CPU#1: kworker/u8:1/34 refcount_t: addition on 0; use-after-free. Modules linked in: CPU: 1 UID: 0 PID: 34 Comm: kworker/u8:1 Not tainted 6.16.0-rc3-next-20250627-dirty #15839 PREEMPT Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound deferred_probe_work_func Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x68/0x88 dump_stack_lvl from __warn+0x94/0x1f0 __warn from warn_slowpath_fmt+0x124/0x1bc warn_slowpath_fmt from drm_bridge_attach+0x2c/0x248 drm_bridge_attach from analogix_dp_bind+0x70/0xc8 analogix_dp_bind from exynos_dp_bind+0x58/0xc4 exynos_dp_bind from component_bind_all+0x11c/0x27c component_bind_all from exynos_drm_bind+0xe8/0x198 exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8 try_to_bring_up_aggregate_device from __component_add+0xb0/0x170 __component_add from exynos_dp_probe+0xc0/0x164 exynos_dp_probe from platform_probe+0x5c/0xb8 platform_probe from really_probe+0xe0/0x3d8 really_probe from __driver_probe_device+0x9c/0x1e0 __driver_probe_device from driver_probe_device+0x30/0xc0 driver_probe_device from __device_attach_driver+0xa8/0x120 __device_attach_driver from bus_for_each_drv+0x84/0xdc bus_for_each_drv from __device_attach+0xb0/0x20c __device_attach from bus_probe_device+0x8c/0x90 bus_probe_device from deferred_probe_work_func+0x98/0xe0 deferred_probe_work_func from process_one_work+0x24c/0x70c process_one_work from worker_thread+0x1b8/0x3bc worker_thread from kthread+0x13c/0x264 kthread from ret_from_fork+0x14/0x28 ... ---[ end trace 0000000000000000 ]--- Fix this by switching the driver to the new API. Note the above warning only appears starting with commit a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") which is the first commmit having added a drm_bridge_get/put() pair and thus exposing the incorrect initial refcount issue. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: a7748dd127ea ("drm/bridge: get/put the bridge reference in drm_bridge_add/remove()") Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250627165652.580798-1-m.szyprowski@samsung.com [Luca: add Fixes tag and mention the reason in commit message] Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-07-06drm/dp: Clean up white space in drm_edp_backlight_probe_state()Dan Carpenter
This code needs to be indented one more tab. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/30b896c2-ae71-4cf2-9511-2713da7e1632@sabinyo.mountain Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-06drm/fbdev-client: Skip DRM clients if modesetting is absentThierry Reding
Recent generations of Tegra have moved the display components outside of host1x, leading to a device that has no CRTCs attached and hence doesn't support any of the modesetting functionality. When this is detected, the driver clears the DRIVER_MODESET and DRIVER_ATOMIC flags for the device. Unfortunately, this causes the following errors during boot: [ 15.418958] ERR KERN drm drm: [drm] *ERROR* Failed to register client: -95 [ 15.425311] WARNING KERN drm drm: [drm] Failed to set up DRM client; error -95 These originate from the fbdev client checking for the presence of the DRIVER_MODESET flag and returning -EOPNOTSUPP. However, if a driver does not support DRIVER_MODESET this is entirely expected and the error isn't helpful. Prevent this misleading error message by setting up the DRM clients only if modesetting is enabled. Changes in v2: - use DRIVER_MODESET check to avoid registering any clients Reported-by: Jonathan Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250613122838.2082334-1-thierry.reding@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-05drm/bridge: adv7511: Fix DRM_BRIDGE_OP_HDMI_{AUDIO|CEC_ADAPTER} setupCristian Ciocaltea
When driver is built with either CONFIG_DRM_I2C_ADV7511_AUDIO or CONFIG_DRM_I2C_ADV7511_CEC disabled, drm_bridge_connector_init() is expected to fail with -EINVAL. That is because all required audio (or CEC) related callbacks in adv7511_bridge_funcs ended up being NULL. Set DRM_BRIDGE_OP_HDMI_AUDIO and DRM_BRIDGE_OP_HDMI_CEC_ADAPTER bridge ops only when the aforementioned kernel config options have been enabled. Fixes: ae01d3183d27 ("drm/bridge: adv7511: switch to the HDMI connector helpers") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250704-adv7511-bridge-ops-fix-v1-1-c1385922066e@collabora.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-07-05drm/msm: Small function param doc fixRob Clark
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507032334.9SCwc952-lkp@intel.com/ Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2025-07-05drm/msm: Take the ioctls away from the KMS-only driverRob Clark
KMS-only drivers should only allocate dumb buffers. The driver custom ioctls are only meant for the usermode gpu driver (mesa), and not for general consumption, so they don't make sense for standalone KMS drivers. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/662598/
2025-07-05drm/msm: Clean up split driver featuresRob Clark
Avoid the possibility of missing features between the split and unified drm driver cases by defining DRIVER_FEATURES_GPU / KMS and using those in the drm_driver initializations. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/662595/
generated by cgit (git 2.34.1) at 2025-09-09 23:43:05 +0000