summaryrefslogtreecommitdiff
path: root/include/drm
AgeCommit message (Collapse)Author
2026-02-17drm/pagemap: pass pagemap_addr by referenceArnd Bergmann
Passing a structure by value into a function is sometimes problematic, for a number of reasons. Of of these is a warning from the 32-bit arm compiler: drivers/gpu/drm/drm_gpusvm.c: In function '__drm_gpusvm_unmap_pages': drivers/gpu/drm/drm_gpusvm.c:1152:33: note: parameter passing for argument of type 'struct drm_pagemap_addr' changed in GCC 9.1 1152 | dpagemap->ops->device_unmap(dpagemap, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1153 | dev, *addr); | ~~~~~~~~~~~ This particular problem is harmless since we are not mixing compiler versions inside of the compiler. However, passing this by reference avoids the warning along with providing slightly better calling conventions as it avoids an extra copy on the stack. Fixes: 75af93b3f5d0 ("drm/pagemap, drm/xe: Support destination migration over interconnect") Fixes: 2df55d9e66a2 ("drm/xe: Support pcie p2p dma as a fast interconnect") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260216134644.1025365-1-arnd@kernel.org Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 95162db0208aee122d10ac1342fe97a1721cd258) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-02-17drm/pagemap: pass pagemap_addr by referenceArnd Bergmann
Passing a structure by value into a function is sometimes problematic, for a number of reasons. Of of these is a warning from the 32-bit arm compiler: drivers/gpu/drm/drm_gpusvm.c: In function '__drm_gpusvm_unmap_pages': drivers/gpu/drm/drm_gpusvm.c:1152:33: note: parameter passing for argument of type 'struct drm_pagemap_addr' changed in GCC 9.1 1152 | dpagemap->ops->device_unmap(dpagemap, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1153 | dev, *addr); | ~~~~~~~~~~~ This particular problem is harmless since we are not mixing compiler versions inside of the compiler. However, passing this by reference avoids the warning along with providing slightly better calling conventions as it avoids an extra copy on the stack. Fixes: 75af93b3f5d0 ("drm/pagemap, drm/xe: Support destination migration over interconnect") Fixes: 2df55d9e66a2 ("drm/xe: Support pcie p2p dma as a fast interconnect") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260216134644.1025365-1-arnd@kernel.org Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2026-02-12drm/i915: Remove i915_reg.h from intel_display_irq.cUma Shankar
Move VLV_IRQ_REGS to common header for interrupt to make intel_display_irq.c free from including i915_reg.h. v2: Move interrupt to dedicated header (Jani) Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260205094341.1882816-18-uma.shankar@intel.com
2026-02-12drm/i915: Remove i915_reg.h from i9xx_wm.cUma Shankar
Move FW_BLC_SELF to common header to make i9xx_wm.c free from i915_reg.h include. Introduce a common intel_gmd_misc_regs.h to define common miscellaneous register definitions across graphics and display. v3: MISC header included as needed, drop from i915_reg (Jani) v2: Introdue a common misc header for GMD Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260205094341.1882816-13-uma.shankar@intel.com
2026-02-12drm/i915: Remove i915_reg.h from intel_overlay.cUma Shankar
Move GEN2_ISR and some interrupt definitions to common header. This removes dependency of i915_reg.h from intel_overlay.c. v3: Rename interrupt header with regs suffix (Jani) v2: Create a separate file for common interrupts (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260205094341.1882816-11-uma.shankar@intel.com
2026-02-12drm/{i915, xe}: Extract pcode definitions to common headerUma Shankar
There are certain register definitions which are commonly shared by i915, xe and display. Extract the same to a common header to avoid duplication. Move GEN6_PCODE_MAILBOX to common pcode header to make intel_cdclk.c free from including i915_reg.h. v3: Include pcode header as required, instead in i915_reg.h (Jani) v2: Make the header granular and per feature (Jani) Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260205094341.1882816-6-uma.shankar@intel.com
2026-02-10drm/xe/nvlp: Add NVL-P platform definitionShekhar Chauhan
Add platform definition along with device IDs for NVL-P. Here is the list of device descriptor fields and associated Bspec references: .dma_mask_size (Bspec 74198) .has_cached_pt (Bspec 71582) .has_display (Bspec 74196) .has_flat_ccs (Bspec 74110) .has_page_reclaim_hw_assist (Bspec 73451) .max_gt_per_tile (Bspec 74196) .va_bits (Bspec 74198) .vm_max_level (Bspec 59507) v2: - Add list of descriptor fields and Bspec references. (Matt) Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260206-nvl-p-upstreaming-v3-12-636e1ad32688@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2026-02-10drm/atomic-helper: Add private_obj atomic_create_state helperMaxime Ripard
Now that we have an atomic_create_state callback for drm_private_objs, we can provide a helper for it. It's somewhat different from the other similar helpers though, because we definitely expect drm_private_obj to be subclassed. It wouldn't make sense for a driver to use it as-is. So we can't provide a straight implementation of the atomic_create_state callback, but rather we provide the parts that will deal with the drm_private_obj initialization, and we will leave the allocation and initialization of the subclass to drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-3-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/atomic: Add new atomic_create_state callback to drm_private_objMaxime Ripard
The drm_private_obj initialization was inconsistent with the rest of the KMS objects. Indeed, it required to pass a preallocated state in drm_private_obj_init(), while all the others objects would have a reset callback that would be called later on to create the state. However, reset really is meant to reset the hardware and software state. That it creates an initial state is a side-effect that has been used in all objects but drm_private_obj. This is made more complex since some drm_private_obj, the DisplayPort ones in particular, need to be persistent across and suspend/resume cycle, and such a cycle would call drm_mode_config_reset(). Thus, we need to add a new callback to allocate a pristine state for a given private object. This discussion has also came up during the atomic state readout discussion, so it might be introduced into the other objects later on. Until all drivers are converted to that new allocation pattern, we will only call it if the passed state is NULL. This will be removed eventually. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm/atomic: Make drm_atomic_private_obj_init fallibleMaxime Ripard
Since we're going to move the drm_private_obj state allocation to a callback, we need to be able to deal with its possible failure. Make drm_private_obj_init return an error code on failure. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-1-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-10drm: Allow driver-managed destruction of colorop objectsChaitanya Kumar Borah
Some drivers might want to embed struct drm_colorop inside driver-specific objects, similar to planes or CRTCs. In such cases, freeing only the drm_colorop is incorrect. Add a drm_colorop_funcs callback to allow drivers to provide a destroy hook that cleans up the full enclosing object. Make changes in helper functions to accept helper functions as argument. Pass NULL for now to retain current behavior. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-3-chaitanya.kumar.borah@intel.com
2026-02-10drm/colorop: Add destroy helper for colorop objectsChaitanya Kumar Borah
Add a helper that performs common cleanup and frees the associated object. This can be used by drivers if they do not require any driver-specific teardown. v2: - Add function documentation only before definition (Jani) Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Alex Hung <alex.hung@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260202094202.2871478-2-chaitanya.kumar.borah@intel.com
2026-02-06drm/fbdev-emulation: Remove empty placeholdersThomas Zimmermann
Only DRM clients for fbdev emulation invoke fbdev helpers. Hence remove the empty placeholders for non-fbdev builds, as they are unused. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260205141142.412048-1-tzimmermann@suse.de
2026-02-06gpu: Move DRM buddy allocator one level up (part two)Joel Fernandes
Move the DRM buddy allocator one level up so that it can be used by GPU drivers (example, nova-core) that have usecases other than DRM (such as VFIO vGPU support). Modify the API, structures and Kconfigs to use "gpu_buddy" terminology. Adapt the drivers and tests to use the new API. The commit cannot be split due to bisectability, however no functional change is intended. Verified by running K-UNIT tests and build tested various configurations. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> [airlied: I've split this into two so git can find copies easier. I've also just nuked drm_random library, that stuff needs to be done elsewhere and only the buddy tests seem to be using it]. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-02-06gpu: Move DRM buddy allocator one level up (part one)Joel Fernandes
Move the DRM buddy allocator one level up so that it can be used by GPU drivers (example, nova-core) that have usecases other than DRM (such as VFIO vGPU support). Modify the API, structures and Kconfigs to use "gpu_buddy" terminology. Adapt the drivers and tests to use the new API. The commit cannot be split due to bisectability, however no functional change is intended. Verified by running K-UNIT tests and build tested various configurations. Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Dave Airlie <airlied@redhat.com> [airlied: I've split this into two so git can find copies easier. I've also just nuked drm_random library, that stuff needs to be done elsewhere and only the buddy tests seem to be using it]. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-02-05Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get bug fixes from v6.19-rc7. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-01-28BackMerge tag 'v6.19-rc7' into drm-nextDave Airlie
Linux 6.19-rc7 This is needed for msm and rust trees. Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-27drm/connector: Add a new 'panel_type' propertyMario Limonciello (AMD)
If the driver can make an assertion whether a connected panel is an OLED panel or not then it can attach a property to the connector that userspace can use as a hint for color schemes. Reviewed-by: Leo Li <sunpeng.li@amd.com> Link: https://patch.msgid.link/20260106170017.68158-2-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-01-27drm/{i915, xe}/pcode: move display pcode calls to parent interfaceJani Nikula
Call the parent driver pcode functions through the parent interface function pointers instead of expecting both to have functions of the same name. In i915, add the interface to existing intel_pcode.[ch], while in xe move them to new display/xe_display_pcode.[ch] and build it only for CONFIG_DRM_XE_DISPLAY=y. Do not add separate write and write_timeout calls in the interface. Instead, handle the default 1 ms timeout in the intel_parent.c glue layer. This drops the last intel_pcode.h includes from display, and allows us to remove the corresponding xe compat header. v2: initialize .pcode in i915 Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260126112925.2452171-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-26drm/{i915, xe}/dsb: move DSB buffer to parent interfaceJani Nikula
Move the DSB buffer handling to the display parent interface, making display more independent of i915 and xe driver implementations. Since the DSB parent interface is only called from intel_dsb.c, add the wrappers there with smaller visibility instead of the usual intel_parent.[ch], and using struct intel_dsb as the context parameter for convenience. Unfortunately, memset() being a macro in linux/fortify-string.h, we can't use that as the function pointer name. dsb->memset() would be using the macro and leading to build failures. Therefore, use .fill() for the memset() functionality. v2: s/memset/fill/ Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/df117c862a6d34dae340e4a85c2482b4e29c8884.1768923917.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-23drm/i915: Document the GMCH_CTRL register a bitVille Syrjälä
The actual GMCH_CRTL lives in the host bridge aka. device 0, but device 2 has a read-only mirror on i85x/i865+. Document that fact. Also remove the ancient tales about where the defines are used. Those haven't been true in a long time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251208182637.334-20-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-01-23drm/i915: Clean up PCI config space reg definesVille Syrjälä
The PCI config space register defines in i915_drm.h are a bit of a mess; Whitespace is all over the place, register masks and values are defined in inconsistent ways. Clean it up a bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251208182637.334-19-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-01-23drm/i915: Get rid of the INTEL_GMCH_CTRL aliasVille Syrjälä
INTEL_GMCH_CTRL and I830_GMCH_CTRL are the same register. Get rid of the INTEL_GMCH_CTRL name. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251208182637.334-18-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-01-23Merge tag 'drm-misc-next-2026-01-22' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: Core Changes: - buddy: Fix free_trees memory leak, prevent a BUG_ON - dma-buf: Start to introduce cgroup memory accounting in heaps, Remove sysfs stats, add new tracepoints - hdmi: Limit infoframes exposure to userspace based on driver capabilities - property: Account for property blobs in memcg Driver Changes: - atmel-hlcdc: Switch to drmm resources, Support nomodeset parameter, various patches to use newish helpers and fix memory safety bugs - hisilicon: Fix various DisplayPort related bugs - imagination: Introduce hardware version checks - renesas: Fix kernel panic on reboot - rockchip: Fix RK3576 HPD interrupt handling, Improve RK3588 HPD interrupt handling - v3d: Convert to drm logging helpers - bridge: - Continuation of the refcounting effort - new bridge: Algoltek AG6311 - panel: - new panel: Anbernic RG-DS Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260122-antique-sexy-junglefowl-1bc5a8@houat
2026-01-22drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATEThomas Hellström
CONFIG_DEVICE_PRIVATE is not selected by default by some distros, for example Fedora, and that leads to a regression in the xe driver since userptr support gets compiled out. It turns out that DRM_GPUSVM, which is needed for xe userptr support compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile without CONFIG_ZONE_DEVICE. Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE, and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and the xe driver's selection of it, re-enabling xe userptr for those configs. v2: - Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set. - Adjust the drm_pagemap.h header accordingly. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 1e372b246199ca7a35f930177fea91b557dac16e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-01-22drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATEThomas Hellström
CONFIG_DEVICE_PRIVATE is not selected by default by some distros, for example Fedora, and that leads to a regression in the xe driver since userptr support gets compiled out. It turns out that DRM_GPUSVM, which is needed for xe userptr support compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile without CONFIG_ZONE_DEVICE. Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE, and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and the xe driver's selection of it, re-enabling xe userptr for those configs. v2: - Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set. - Adjust the drm_pagemap.h header accordingly. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com
2026-01-20drm/bridge: samsung-dsim: samsung_dsim_host_attach: convert to ↵Luca Ceresoli
of_drm_find_and_get_bridge() of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. Also switch to the drm_bridge::next_bridge pointer. This needs to handle both cases: when of_drm_find_panel() succeeds and when it fails. In the 'else' case (i.e. when of_drm_find_panel() fails), just switch to of_drm_find_and_get_bridge() to ensure the bridge is not freed while in use in the function tail, when it is stored in dsi->bridge.next_bridge. In the 'then' case (i.e. when of_drm_find_panel() succeeds), devm_drm_panel_bridge_add() already increments the refcount using devres which ties the bridge allocation lifetime to the device lifetime, so we would not need to do anything. However to have the same behaviour in both branches take an additional reference here, so that the bridge needs to be put whichever branch is taken without more complicated logic. Ensure to clear the bridge pointer however, to avoid calling drm_bridge_put() on an ERR_PTR. Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-12-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-20drm: of: drm_of_panel_bridge_remove(): convert to of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() is deprecated. Move to its replacement of_drm_find_and_get_bridge() which gets a bridge reference, and ensure it is put when done. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-2-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-20drm: of: drm_of_panel_bridge_remove(): fix device_node leakLuca Ceresoli
drm_of_panel_bridge_remove() uses of_graph_get_remote_node() to get a device_node but does not put the node reference. Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function") Cc: stable@vger.kernel.org # v4.15 Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260109-drm-bridge-alloc-getput-drm_of_find_bridge-2-v2-1-8bad3ef90b9f@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-01-20drm/rockchip: inno-hdmi: make inno_hdmi.h header self-containedJani Nikula
Include linux/types.h for u8. Reviewed-by: Andy Yan <andy.yan@rock-chips.com> Link: https://patch.msgid.link/20260107152704.2290146-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-19drm/display: hdmi_state_helper: split InfoFrame functions per typeDmitry Baryshkov
Havign a single set of InfoFrame callbacks doesn't provide enough information to the DRM framework about the InfoFrame types that are actually supported. Also it's not really future-proof: it provides a way to program only a single Vendor-Specific frame, however we might need to support multiple VSIs at the same time (e.g. HDMI vs HDMI Forum VSIs). Provide separate sets of callbacks, one per the InfoFrame type. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-6-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/bridge: refactor HDMI InfoFrame callbacksDmitry Baryshkov
Having only a single set of callbacks, hdmi_clear_infoframe and hdmi_write_infoframe, bridge drivers don't have an easy way to signal to the DRM framework, which InfoFrames are actually supported by the hardware and by the driver and which are not. Also, it makes it extremely easy for HDMI bridge drivers to skip implementing the seemingly required InfoFrames (e.g. HDMI VSI). Last, but not least, those callbacks take a single 'type' parameter, which makes it impossible to implement support for multiple VSIs (which will be required once we start working on HDMI Forum VSI). Split the callbacks into a per-InfoFrame-kind pairs, letting the bridge drivers actually signal supported features. The implementation follows the overall drm_bridge design, where the bridge has a single drm_bridge_funcs implementation and signals, which functions are to be called using the drm_bridge->ops flags. The AVI and HDMI VSI are assumed to be required for a normal HDMI operation (with the drivers getting a drm_warn_once() stub implementation if one is missing). The Audio InfoFrame is handled by the existing DRM_BRIDGE_OP_HDMI_AUDIO, while the SPD and HDR DRM InfoFrames got new drm_bridge_ops values. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/connector: make clear_infoframe callback mandatory for HDMI connectorsDmitry Baryshkov
We already require both hdmi_write_infoframe and hdmi_clear_infoframe for bridges implementing DRM_BRIDGE_OP_HDMI. It makes sense to require the clear_infoframes callback for HDMI connectors utilizing drmm_connector_hdmi_init(). Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-4-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-16Merge tag 'drm-misc-fixes-2026-01-16' of ↵Simona Vetter
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.19-rc6: vmwgfx: - Fix hw regression from refactoring cursor handling on v10 'hardware' - Fix warnings in destructor by merging the 2 release functions - kernel doc fix - error handling in vmw_compat_shader_add() rockchip: - fix vop2 polling - fix regression waiting for cfgdone without config change - fix warning when enabling encoder core: - take gem lock when preallocating in gpuvm. - add single byte read fallback to dp for broken usb-c adapters - remove duplicate drm_sysfb declarations gud: - Fix oops on usb disconnect Simple panel: - Re-add fallback when connector is not set to fix regressions - Set correct type in DataImage SCF0700C48GGU18 nouveau: - locking fixes for cursor handling. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/ce0acfe2-9c1a-42b7-8782-f1e7f34b8544@linux.intel.com
2026-01-16Merge tag 'drm-intel-next-2026-01-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Beyond Display: - Make 'guc_hw_reg_state' static as it isn't exported (Ben) - Fix doc build on mei related interface header (Jani) Display related: - Fix ggtt fb alignment on Xe display (Tvrtko) - More display clean-up towards deduplication and full separation (Jani) - Use the consolidated HDMI tables (Suraj) - Account for DSC slice overhead (Ankit) - Prepare GVT for display modularization (Ankit, Jani) - Enable/Disable DC balance along with VRR DSB (Mitul, Ville) - Protection against unsupported modes in LT PHY (Suraj) - Display W/a addition and fixes (Gustavo) - Fix many SPDX identifier comments (Ankit) - Incorporate Xe3_LPD changes for CD2X divider (Gustavo) - Clean up link BW/DSC slice config computation (Imre) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aWkNThVRSkGAfUVv@intel.com
2026-01-16Merge tag 'drm-misc-next-2026-01-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: Core Changes: - atomic: Introduce Gamma/Degamma LUT size check - gem: Fix a leak in drm_gem_get_unmapped_area - gpuvm: API sanitation for Rust bindings - panic: Few corner-cases fixes Driver Changes: - Replace system workqueue with percpu equivalent - amdxdna: Update message buffer allocation requirements, Update firmware version check - imagination: Add AM62P support - ivpu: Implement warm boot flow - rockchip: Get rid of atomic_check fixups, Add Rockchip RK3506 Support - rocket: Cleanups - bridge: - dw-hdmi-qp: Add support for HPD-less setups - panel: - mantix: Various power management related improvements - new panels: Innolux G150XGE-L05, - dma-buf: - cma: Call clear_page instead of memset Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260115-lilac-dragon-of-opposition-ac0a30@houat
2026-01-14drm/atomic: add max_size check to drm_property_replace_blob_from_id()Dmitry Baryshkov
The function drm_property_replace_blob_from_id() allows checking whether the blob size is equal to a predefined value. In case of variable-size properties (like the gamma / degamma LUTs) we might want to check for the blob size against the maximum, allowing properties of the size lesser than the max supported by the hardware. Extend the function in order to support such checks. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-2-f7f979eb73c8@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-14drm/mode_object: add drm_object_immutable_property_get_value()Dmitry Baryshkov
We have a helper to get property values for non-atomic drivers and another one default property values for atomic drivers. In some cases we need the ability to get value of immutable property, no matter what kind of driver it is. Implement new property-related helper, drm_object_immutable_property_get_value(), which lets the caller to get the value of the immutable property. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260106-drm-fix-lut-checks-v3-1-f7f979eb73c8@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-09drm/dp: Add byte-by-byte fallback for broken USB-C adaptersChia-Lin Kao (AceLan)
Some USB-C hubs and adapters have buggy firmware where multi-byte AUX reads consistently timeout, while single-byte reads from the same address work correctly. Known affected devices that exhibit this issue: - Lenovo USB-C to VGA adapter (VIA VL817 chipset) idVendor=17ef, idProduct=7217 - Dell DA310 USB-C mobile adapter hub idVendor=413c, idProduct=c010 Analysis of the failure pattern shows: - Single-byte probes to 0xf0000 (LTTPR) succeed - Single-byte probes to 0x00102 (TRAINING_AUX_RD_INTERVAL) succeed - Multi-byte reads from 0x00000 (DPCD capabilities) timeout with -ETIMEDOUT - Retrying does not help - the failure is consistent across all attempts The issue appears to be a firmware bug in the AUX transaction handling that specifically affects multi-byte reads. Add a fallback mechanism in drm_dp_dpcd_read_data() that attempts byte-by-byte reading when the normal multi-byte read fails. This workaround only activates for adapters that fail the standard read path, ensuring no impact on correctly functioning hardware. Tested with: - Lenovo USB-C to VGA adapter (VIA VL817) - now works with fallback - Dell DA310 USB-C hub - now works with fallback - Dell/Analogix Slimport adapter - continues to work with normal path Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20251204024647.1462866-1-acelan.kao@canonical.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-01-09Merge tag 'drm-misc-next-2026-01-08' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: UAPI Changes: Cross-subsystem Changes: Core Changes: - draw: Add API to check if a format conversion can be done - panic: Rename draw_panic_static_* to draw_panic_screen_*, Add kunit tests - shmem: Improve tests Driver Changes: - ast: Big endian fixes - etnaviv: Add PPU flop reset support - panfrost: Add GPU_PM_RT support for RZ/G3E SoC - panthor: multiple fixes around VM termination, huge page support - pl111: Fix build regression - v3d: Fix DMA segment size - bridge: - Add connector argument to .hpd_notify - Plenty of patches to convert existing drivers to refcounting - Convert Rockchip's inno hdmi support to a proper bridge - lontium-lt9611uxc: Switch to HDMI audio helpers - panel: - New panel: BOE NV140WUM-T08 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260108-literate-nyala-of-courtesy-de501a@houat
2026-01-08drm/gpuvm: use const for drm_gpuva_op_* ptrsAlice Ryhl
These methods just read the values stored in the op pointers without modifying them, so it is appropriate to use const ptrs here. This allows us to avoid const -> mut pointer casts in Rust. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-3-dbd014005a0b@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-08drm/gpuvm: drm_gpuvm_bo_obtain() requires lock and staged modeAlice Ryhl
In commit 9ce4aef9a5b1 ("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()") we update drm_gpuvm_bo_obtain_prealloc() to take locks internally, which means that it's only usable in immediate mode. In this commit, we notice that drm_gpuvm_bo_obtain() requires you to use staged mode. This means that we now have one variant of obtain for each mode you might use gpuvm in. To reflect this information, we add a warning about using it in immediate mode, and to make the distinction clearer we rename the method with a _locked() suffix so that it's clear that it requires the caller to take the locks. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-2-dbd014005a0b@google.com [ Slightly reword commit message to refer to commit 9ce4aef9a5b1 ("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()"). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-08mei: late_bind: fix struct intel_lb_component_ops kernel-docJani Nikula
Fix kernel-doc warnings on struct intel_lb_component_ops: Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of kernel-doc format: * push_payload - Sends a payload to the authentication firmware And a bunch more. There isn't really support for documenting function pointer struct members in kernel-doc, but at least reference the member properly. Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Cc: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-08Merge tag 'drm-misc-fixes-2026-01-07' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v6.19-rc5: pl111: - Fix error handling in probe mediatek/atomic/tidss: - Fix tidss in another way and revert reordering of pre-enable and post-disable operations, as it breaks other bridge drivers. nouveau: - Fix regression from fwsec s/r fix. pci/vga: - Fix multiple gpu's being reported a 'boot_display' fb-helper: - Fix vblank timeout during suspend/reset Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/f50067e6-243a-4ed8-9781-1e4e4fdebc8e@linux.intel.com
2026-01-07drm/bridge: dw-hdmi-qp: Fix spurious IRQ on resumeSebastian Reichel
After resume from suspend to RAM, the following splash is generated if the HDMI driver is probed (independent of a connected cable): [ 1194.484052] irq 80: nobody cared (try booting with the "irqpoll" option) [ 1194.484074] CPU: 0 UID: 0 PID: 627 Comm: rtcwake Not tainted 6.17.0-rc7-g96f1a11414b3 #1 PREEMPT [ 1194.484082] Hardware name: Rockchip RK3576 EVB V10 Board (DT) [ 1194.484085] Call trace: [ 1194.484087] ... (stripped) [ 1194.484283] handlers: [ 1194.484285] [<00000000bc363dcb>] dw_hdmi_qp_main_hardirq [dw_hdmi_qp] [ 1194.484302] Disabling IRQ #80 Apparently the HDMI IP is losing part of its state while the system is suspended and generates spurious interrupts during resume. The bug has not yet been noticed, as system suspend does not yet work properly on upstream kernel with either the Rockchip RK3588 or RK3576 platform. Fixes: 128a9bf8ace2 ("drm/rockchip: Add basic RK3588 HDMI output support") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251014-rockchip-hdmi-suspend-fix-v1-1-983fcbf44839@collabora.com
2026-01-03drm/atomic-helper: Export and namespace some functionsLinus Walleij
Export and namespace those not prefixed with drm_* so it becomes possible to write custom commit tail functions in individual drivers using the helper infrastructure. Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: stable@vger.kernel.org # v6.17+ Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20251205-drm-seq-fix-v1-3-fda68fa1b3de@ideasonboard.com
2026-01-03Revert "drm/atomic-helper: Re-order bridge chain pre-enable and post-disable"Tomi Valkeinen
This reverts commit c9b1150a68d9362a0827609fc0dc1664c0d8bfe1. Changing the enable/disable sequence has caused regressions on multiple platforms: R-Car, MCDE, Rockchip. A series (see link below) was sent to fix these, but it was decided that it's better to revert the original patch and change the enable/disable sequence only in the tidss driver. Reverting this commit breaks tidss's DSI and OLDI outputs, which will be fixed in the following commits. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/all/20251202-mcde-drm-regression-thirdfix-v6-0-f1bffd4ec0fa%40kernel.org/ Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") Cc: stable@vger.kernel.org # v6.17+ Reviewed-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Tested-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20251205-drm-seq-fix-v1-1-fda68fa1b3de@ideasonboard.com
2026-01-01Merge tag 'drm-xe-next-2025-12-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Core Changes: - Dynamic pagemaps and multi-device SVM (Thomas) Driver Changes: - Introduce SRIOV scheduler Groups (Daniele) - Configure migration queue as low latency (Francois) - Don't use absolute path in generated header comment (Calvin Owens) - Add SoC remapper support for system controller (Umesh) - Insert compiler barriers in GuC code (Jonathan) - Rebar updates (Lucas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/aVOiULyYdnFbq-JB@fedora
2025-12-30drm/bridge: add next_bridge pointer to struct drm_bridgeLuca Ceresoli
Many bridge drivers store a next_bridge pointer in their private data and use it for attach and sometimes other purposes. This is going to be risky when bridge hot-unplug is used. Considering this example scenario: 1. pipeline: encoder --> bridge A --> bridge B --> bridge C 2. encoder takes a reference to bridge B 3. bridge B takes a next_bridge reference to bridge C 4. encoder calls (bridge B)->b_foo(), which in turns references next_bridge, e.g.: b_foo() { bar(b->next_bridge); } If bridges B and C are removed, bridge C can be freed but B is still allocated because the encoder holds a reference to B. So when step 4 happens, 'b->next-bridge' would be a use-after-free. Calling drm_bridge_put() in the B bridge .remove function does not solve the problem as it leaves a (potentially long) risk window between B removal and the final deallocation of B. A safe moment to put the B reference is in __drm_bridge_free(), when the last reference has been put. This can be done by drivers in the .destroy func. However to avoid the need for so many drivers to implement a .destroy func, just offer a next_bridge pointer to all bridges that is automatically put it in __drm_bridge_free(), exactly when the .destroy func is called. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2025-12-30drm/bridge: add of_drm_find_and_get_bridge()Luca Ceresoli
of_drm_find_bridge() does not increment the refcount for the returned bridge, but that is required now. However converting it and all its users is not realistically doable at once given the large amount of (direct and indirect) callers and the complexity of some. Solve this issue by creating a new of_drm_find_and_get_bridge() function that is identical to of_drm_find_bridge() except also it takes a reference. Then of_drm_find_bridge() will be deprecated to be eventually removed. Suggested-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/ Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-19 13:23:58 +0000