aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2026-03-02drm/syncobj: Fix handle <-> fd ioctls with dirty stackJulian Orth1-2/+2
Consider the following application: #include <fcntl.h> #include <string.h> #include <drm/drm.h> #include <sys/ioctl.h> int main(void) { int fd = open("/dev/dri/renderD128", O_RDWR); struct drm_syncobj_create arg1; ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &arg1); struct drm_syncobj_handle arg2; memset(&arg2, 1, sizeof(arg2)); // simulate dirty stack arg2.handle = arg1.handle; arg2.flags = 0; arg2.fd = 0; arg2.pad = 0; // arg2.point = 0; // userspace is required to set point to 0 ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &arg2); } The last ioctl returns EINVAL because args->point is not 0. However, userspace developed against older kernel versions is not aware of the new point field and might therefore not initialize it. The correct check would be if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) return -EINVAL; However, there might already be userspace that relies on this not returning an error as long as point == 0. Therefore use the more lenient check. Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") Signed-off-by: Julian Orth <ju.orth@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260301-point-v1-1-21fc5fd98614@gmail.com
2026-03-02drm/panthor: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-1/+1
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260227133113.235940-8-tzimmermann@suse.de
2026-03-02drm/panfrost: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-1/+1
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Rob Herring <robh@kernel.org> Cc: Steven Price <steven.price@arm.com> Cc: "Adrián Larumbe" <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260227133113.235940-7-tzimmermann@suse.de
2026-03-02drm: renesas: rz-du: mipi_dsi: Set DSI dividerChris Brandt1-1/+15
Before the MIPI DSI clock source can be configured, the target divide ratio needs to be set. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Fixes: 5a4326f2e3b1 ("clk: renesas: rzg2l: Remove DSI clock rate restrictions") Link: https://patch.msgid.link/20260227015216.2721504-1-chris.brandt@renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-03-02Merge tag 'drm-misc-next-2026-02-26' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-nextDave Airlie179-3547/+7015
drm-misc-next for v7.1: UAPI Changes: connector: - Add panel_type property fourcc: - Add ARM interleaved 64k modifier nouveau: - Query Z-Cull info with DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO Cross-subsystem Changes: coreboot: - Clean up coreboot framebuffer support dma-buf: - Provide revoke mechanism for shared buffers - Rename move_notify callback to invalidate_mappings and update users. - Always enable move_notify - Support dma_fence_was_initialized() test - Protect dma_fence_ops by RCU and improve locking - Fix sparse warnings Core Changes: atomic: - Allocate drm_private_state via callback and convert drivers atomic-helper: - Use system_percpu_wq buddy: - Make buddy allocator available to all DRM drivers - Document flags and structures colorop: - Add destroy helper and convert drivers fbdev-emulation: - Clean up gem: - Fix drm_gem_objects_lookup() error cleanup Driver Changes: amdgpu: - Set panel_type to OELD for eDP atmel-hlcdc: - Support sana5d65 LCD controller bridge: - anx7625: Support USB-C plus DT bindings - connector: Fix EDID detection - dw-hdmi-qp: Support Vendor-Specfic and SDP Infoframes; improve others - fsl-ldb: Fix visual artifacts plus related DT property 'enable-termination-resistor' - imx8qxp-pixel-link: Improve bridge reference handling - lt9611: Support Port-B-only input plus DT bindings - tda998x: Support DRM_BRIDGE_ATTACH_NO_CONNECTOR; Clean up - Support TH1520 HDMI plus DT bindings - Clean up imagination: - Clean up komeda: - Fix integer overflow in AFBC checks mcde: - Improve bridge handling nouveau: - Provide Z-cull info to user space - gsp: Support GA100 - Shutdown on PCI device shutdown - Clean up panel: - panel-jdi-lt070me05000: Use mipi-dsi multi functions - panel-edp: Support Add AUO B116XAT04.1 (HW: 1A); Support CMN N116BCL-EAK (C2); Support FriendlyELEC plus DT changes - Fix Kconfig dependencies panthor: - Add tracepoints for power and IRQs rcar-du: - dsi: fix VCLK calculation rockchip: - vop2: Use drm_ logging functions - Support DisplayPort on RK3576 sysfb: - corebootdrm: Support system framebuffer on coreboot firmware; detect orientation - Clean up pixel-format lookup sun4i: - Clean up tilcdc: - Use DT bindings scheme - Use managed DRM interfaces - Support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Clean up a lot of obsolete code v3d: - Clean up vc4: - Use system_percpu_wq - Clean up verisilicon: - Support DC8200 plus DT bindings virtgpu: - Support PRIME imports with enabled 3D Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260226143615.GA47200@linux.fritz.box
2026-03-01gpu: nova-core: Kconfig: Sort select statements alphabeticallyJoel Fernandes1-1/+1
Reorder the select statements in NOVA_CORE Kconfig to be in alphabetical order. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260224225323.3312204-3-joelagnelf@nvidia.com [acourbot@nvidia.com: fix conflict due to patch reordering.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-27drm/xe/vf: Redo LRC creation while in VF fixupsTomasz Lis4-13/+59
If the xe module within a VM was creating a new LRC during save/ restore, this LRC will be invalid. The fixups procedure may not be able to reach it, as there will be a race to add the new LRC reference to an exec queue. Even if the new LRC which was being created during VM migration is added to EQ in time for fixups, said LRC may still remain damaged. In a small percentage of specially crafted test cases, the resulting LRC was still damaged and caused GPU hang. Any LRC which could be created in such a situation, have to be re-created. Due to VM having arbitrarily set amount of CPU cores, it is possible to limit the amount to 1. In such case, there is a possibility that kernel will switch CPU contexts in a way which allows to miss VF migration recovery running in parallel (by simply not switching to the LRC creation thread during recovery). Therefore checking if the migration is in progress just after LRC creation, is not enough to ensure detection. Free the incorrectly created LRC, and trigger a re-run of the creation, but only after waiting for default LRC to get fixups. Use additional atomic value increased after fixups, to ensure any VF migration that avoided detection by just checking for recovery in progress, will be caught. v2: Merge marker and wait for default LRC, reducing amount of calls within xe_init_eq(). Alter the LRC creation loop to remove a race with post-migration fixups worker. v3: Kerneldoc fixes. Rename fixups_complete_count. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-5-tomasz.lis@intel.com
2026-02-27drm/xe/vf: Wait for all fixups before using default LRCsTomasz Lis2-8/+10
When a context is being created during save/restore, the LRC creation needs to wait for GGTT address space to be shifted. But it also needs to have fixed default LRCs. This is mandatory to avoid the situation where LRC will be created based on data from before the fixups, but reference within exec queue will be set too late for fixups. This fixes an issue where contexts created during save/restore have a large chance of having one unfixed LRC, due to the xe_lrc_create() being synced for equal start to race with default LRC fixups. v2: Move the fixups confirmation further, behind all fixups. Revert some renames. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-4-tomasz.lis@intel.com
2026-02-27drm/xe: Wrappers for setting and getting LRC referencesTomasz Lis3-19/+60
There is a small but non-zero chance that VF post migration fixups are running on an exec queue during teardown. The chances are decreased by starting the teardown by releasing guc_id, but remain non-zero. On the other hand the sync between fixups and EQ creation (wait_valid_ggtt) drastically increases the chance for such parallel teardown if queue creation error path is entered (err_lrc label). The exec queue itself is not going to cause an issue, but LRCs have a small chance of getting freed during the fixups. Creating a setter and a getter makes it easier to protect the fixup operations with a lock. For other driver activities, the original access method (without any protection) can still be used. v2: Separate lock, only for LRCs. Kerneldoc fixes. Subject tag fix. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-3-tomasz.lis@intel.com
2026-02-27drm/xe/queue: Call fini on exec queue creation failTomasz Lis2-13/+13
Every call to queue init should have a corresponding fini call. Skipping this would mean skipping removal of the queue from GuC list (which is part of guc_id allocation). A damaged queue stored in exec_queue_lookup list would lead to invalid memory reference, sooner or later. Call fini to free guc_id. This must be done before any internal LRCs are freed. Since the finalization with this extra call became very similar to __xe_exec_queue_fini(), reuse that. To make this reuse possible, alter xe_lrc_put() so it can survive NULL parameters, like other similar functions. v2: Reuse _xe_exec_queue_fini(). Make xe_lrc_put() aware of NULLs. Fixes: 3c1fa4aa60b1 ("drm/xe: Move queue init before LRC creation") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> (v1) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-2-tomasz.lis@intel.com
2026-02-27drm/xe: restrict multi-lrc to VCS/VECS enginesXin Wang4-0/+29
Tighten uapi validation to restrict multi-lrc support to VIDEO_DECODE and VIDEO_ENHANCE engines only. This check should have been in place from the start, as the driver typically avoids allowing uapi cases that we have no userspace consumer for. Additionally, the GuC firmware on ModSched platforms no longer supports multi-lrc on non-media engines. V4: - use a unified mask for all platforms since engine instance count is an independent runtime check (Matt Roper, Matthew Brost) V3: - store a multi-lrc enable class mask in xe->info and populate from xe_device_desc in xe_pci.c (Matthew Brost) V2: - correct the typo (Shuicheng) - move the check earlier to avoid VM lookup (Shuicheng, Matt Roper) - remove the graphics version check (Matt Roper) - input more details in the commit info (Matt Roper) Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260225022014.45394-1-x.wang@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-27drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3pMatt Roper2-0/+6
A recent bspec tuning guide update asks us to program COMMON_SLICE_CHICKEN4[5] on Xe3 and Xe3p platforms. Add this setting to our LRC tuning RTP table so that the setting will become part of each context's LRC. Bspec: 72161, 55902 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260224235055.3038710-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-27drm/i915: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-3/+3
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260227133113.235940-5-tzimmermann@suse.de
2026-02-27drm/ttm: Fix ttm_pool_beneficial_order() return typeTvrtko Ursulin1-1/+1
Fix a nasty copy and paste bug, where the incorrect boolean return type of the ttm_pool_beneficial_order() helper had a consequence of avoiding direct reclaim too eagerly for drivers which use this feature (currently amdgpu). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 7e9c548d3709 ("drm/ttm: Allow drivers to specify maximum beneficial TTM pool size") Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.19+ Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260227124901.3177-1-tvrtko.ursulin@igalia.com
2026-02-27drm/nouveau: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-1/+1
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: nouveau@lists.freedesktop.org Link: https://patch.msgid.link/20260227133113.235940-6-tzimmermann@suse.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-02-27drm/tests: Mark slow tests as slowMaxime Ripard2-3/+3
Some DRM tests cross the 1s execution time threshold that defines a test as slow. Let's flag them as such. Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-27drm/sched: Remove racy hack from drm_sched_fini()Philipp Stanner1-37/+1
drm_sched_fini() contained a hack to work around a race in amdgpu. According to AMD, the hack should not be necessary anymore. In case there should have been undetected users, commit 975ca62a014c ("drm/sched: Add warning for removing hack in drm_sched_fini()") had added a warning one release cycle ago. Thus, it can be derived that the hack can be savely removed by now. Remove the hack. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260108083019.63532-2-phasta@kernel.org
2026-02-27drm/i915/overlay: Convert overlay to parent interfaceVille Syrjälä8-101/+160
Convert the direct i915_overlay_*() calls from the display side to go over a new parent interface instead. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) v3: Rebase due to the NULL check in intel_overlay_cleanup() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130150.16816-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Move i915 specific code into i915_overlay.cVille Syrjälä6-490/+550
Relocate the i915 driver specific parts of the overlay code into i915_overlay.c. This leaves intel_overlay.c with just the display specific code. The one annoyance here is the DSPCLK_GATE_D register access being done from i830_overlay_clock_gating(). The register definition lives on the display side as we do need to access it on other platforms there. Since it's just one register and bit, I decided to just duplicate that part in i915_reg.h. v2: Use kzalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226133855.17690-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Don't use fetch_and_zero() in display codeVille Syrjälä1-5/+3
We don't generally want fetch_and_zero() on the display side, so stop using it in the display side intel_overlay_cleanup(). Fortunately we don't really have anything to do here apart from freeing the data. And we'll keep on clearing the pointer, just in case something somewhere cares about it. Note that once i915_overlay_cleanup() is converted to the parent interface we can't call it unconditionally (as xe won't have it). So we need to keep the early bailout for overlay==NULL. v2: Adjust the commit message since we do apparently have fetch_and_zero() in display code as well (Jani) v3: Skip i915_overlay_cleanup() if the overlay wasn't initialized Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130113.16714-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Split 'struct intel_overlay'Ville Syrjälä2-52/+81
Split the i915 driver specific bits from 'struct intel_overlay' into a seaarate 'struct i915_overlay'. The latter will move to the i915 side of the parent vs. display driver split. The display side will also need to know the virtual address of the register map. That now gets passed as the return value from i915_overlay_setup(), so that the display side doesn't need to know how the mapping was achieved. v2: Use kzalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-17-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: s/dev_priv/i915/Ville Syrjälä1-2/+2
Rename the one lingering 'dev_priv' variable to the more modern 'i915' in the overlay code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-16-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Make i830_overlay_clock_gating() i915 specificVille Syrjälä1-9/+15
i830_overlay_clock_gating() will remain on the i915 side of the parent vs. display driver split. Stop using display specific stuff inside it. The one annoyance here is access to the display engine's DSPCLK_GATE_D register. The proper way to deal with that might be to move it to the display side, but that seems a bit hard right now. So leave it where it is for now. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-15-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Adjust i915 specific interfacesVille Syrjälä1-22/+29
Adjust the names ("i915_overlay_" prefix) and calling convention (pass the driver agnostic 'struct drm_device'() of the functions that will provide the remainder of the parent driver interface to be used by the overlay display code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-14-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Rename low level i915 specific functionsVille Syrjälä1-15/+14
Some of the lower level functions in the overlay code will move to the i915 side of the upcoming parent vs. display driver split. Move all such functions to the "i915_overlay_" namespace to make it easier to see what belongs where. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-13-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Abstract buffer (un)pinningVille Syrjälä1-7/+17
Make the buffer (un)pinning a bit more abstract so that the display side of the code doesn't need to know about i915 specific things (i915_ggtt_offset() and i915_vma_unpin()). In preparation for the full parent vs. display driver split we'll also pass in the drm_device to these functions, although not strictly needed yet. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-12-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_cleanup()Ville Syrjälä1-8/+14
Pull the i915 specific bits of the overlay cleanup into a separate function (i915_overlay_cleanup()) to accommodate the upcoming parent vs. display driver split. For now we'll also have to pass in the overlay struct, but that will disappear once the i915 vs. display split is completed. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-11-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_setup()Ville Syrjälä1-14/+24
Pull the gem/gt related bits of the overlay setup into a separate function (i915_overlay_setup()) that will eventually move to the i915 side of the parent vs. display driver split. For now we'll also have to pass in the overlay struct, but that will disappear once the i915 vs. display split is completed. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-10-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_reset()Ville Syrjälä1-1/+13
overlay->frontbuffer_bits tracking will move to the i915 side of the parent vs. display driver split, so extract the reset part of that into a new function (i915_overlay_reset()). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-9-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Use struct drm_gem_object as the typeVille Syrjälä1-18/+19
Use 'struct drm_gem_object' for the BO instead of 'struct drm_i915_gem_object', to avoid having the display side know anything about the i915 specific BO type. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-8-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Introduce i915_overlay_obj_lookup()Ville Syrjälä1-10/+23
Extract the BO lookup and tiling check into a new helper called i915_overlay_obj_lookup(). This will have to move to the i915 side of the parent vs. display driver split. There is a slight change here in that we now do the tiling check before taking the modeset locks, but those locks don't protect the BO tiling stuff in any way, so nothing is really different here. Note that the hardware should support X-tiled scanout also for the overlay, but I guess no one ever bothered to hook it up and test it. So the check should stay at least for now. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-7-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Relocate the underrun checkVille Syrjälä1-6/+7
Move the underrun check out from intel_overlay_continue() so that the DOVSTA register access can stay on the display side of the parent vs. display driver split. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-6-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Remove redundant overlay->activeVille Syrjälä1-5/+1
Now that we have overlay->frontbuffer_bits, overlay->active is completely redundant, so remove it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-5-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_is_active()Ville Syrjälä1-7/+15
Pull the "is the overlay active?" check to a helper (i915_overlay_is_active()). This will have to move to the i915 side of the parent vs. display driver split. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-4-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Track current frontbuffer_bitsVille Syrjälä1-7/+12
Store the current frontbuffer_bits in the overlay data. The main benefit here is that we get rid of the 'crtc->pipe' usage from intel_overlay_flip_prepare() which will have to move to the i915 side of the parent vs. display driver split. And since the goal is to get rid of the crtc stuff, move those out from intel_overlay_off_tail() into intel_overlay_switch_off() since the i915 side doesn't use those anymore, and the display side doesn't need those anymore after that anyway. intel_overlay_off_tail() will itself move to the i915 side of the fence once the driver split is done. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-3-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Remove GPU hang snapshot stuffVille Syrjälä3-111/+0
The overlay snapshot stuff is a bit annoying because some of it more or less of belongs on the gt side, and some on the display side. Remove the whole thing to avoid having to deal with it when splitting the overlay code around the i915 vs. display boundary. I don't think I've ever actually used this for anything, so no real loss from my POV. And it can always be resurrected later should the need arise. v2: Rebase due to kmalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-2-ville.syrjala@linux.intel.com
2026-02-27drm/xe/compat: Remove unused i915_reg.h from compat headerUma Shankar1-6/+0
Display Code is made independent of i915_reg.h, hence it can be dropped from compat header. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260226175531.2324526-1-uma.shankar@intel.com
2026-02-27drm/i915/backlight: Remove try_vesa_interfaceSuraj Kandpal1-12/+7
Some panels need VESA DPCD AUX backlight but VBT says otherwise. This is why we try with Intel backlight interface over VESA backlight interface. This causes a blankout on such panels without any fallback mechanism. Remove try_vesa_interface and use VESA AUX backlight interface as a fallback mechanism. While at in sneak in a small comment cleanup too. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15679 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260224031322.2568874-1-suraj.kandpal@intel.com
2026-02-27Merge tag 'amd-drm-fixes-7.0-2026-02-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixesDave Airlie8-28/+42
amd-drm-fixes-7.0-2026-02-26: amdgpu: - UserQ fixes - DC fix - RAS fixes - VCN 5 fix - Slot reset fix - Remove MES workaround that's no longer needed Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260226161330.3549393-1-alexander.deucher@amd.com
2026-02-27Merge tag 'drm-xe-fixes-2026-02-26' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixesDave Airlie3-21/+81
- W/a fix for multi-cast registers (Roper) - Fix xe_sync initialization issues (Shuicheng) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aaBGHy_0RLGGIBP5@intel.com
2026-02-26drm/xe/configfs: Free ctx_restore_mid_bb in releaseShuicheng Lin1-0/+1
ctx_restore_mid_bb memory is allocated in wa_bb_store(), but xe_config_device_release() only frees ctx_restore_post_bb. Free ctx_restore_mid_bb[0].cs as well to avoid leaking the allocation when the configfs device is removed. Fixes: b30d5de3d40c ("drm/xe/configfs: Add mid context restore bb") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260225013448.3547687-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-26drm/xe/xe3p_xpc: Drop stale MCR steering TODO commentMatt Roper1-6/+0
Proper steering+termination for Xe3p_XPC NODE and BANK multicast ranges was added in commit 6d5511e56b2d ("drm/xe/xe3p_xpc: Add MCR steering for NODE and L3BANK ranges") but we forgot to remove the corresponding TODO comment at the top of the block. Drop it now to avoid confusion. Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260225203719.3310570-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-26drm/i915/dpt: pass opaque struct intel_dpt around instead of i915_address_spaceJani Nikula8-50/+51
struct i915_address_space is used in an opaque fashion in the display parent interface, but it's just one include away from being non-opaque. And anyway the name is rather specific. Switch to using the struct intel_dpt instead, which embeds struct i915_address_space anyway. With the definition hidden in i915_dpt.c, this can't be accidentally made non-opaque, and the type seems rather more generic anyway. We do have to add a new helper i915_dpt_to_vm(), as there's one case in intel_fb_pin_to_dpt() that requires direct access to struct i915_address_space. But this just underlines the point about opacity. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/daa39178c0b0305b010564952d691f06e3cd63ca.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: rename struct i915_dpt to intel_dptJani Nikula1-11/+11
Rename struct i915_dpt to intel_dpt. This may seem rather inconsistent considering we just renamed the functions the other way round, but the intent here is to lift struct intel_dpt to the display parent interface as the generic opaque type for DPT instead of the very specific struct i915_address_space. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/afb89dcce35c5b0cff2007b58d6ee20fd3200c24.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: rename i915 specific functions to i915_dpt_ prefixJani Nikula3-12/+10
Follow the common convention of naming functions by file name, in this case also clarifying which functions are i915 specific. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/9bb94942ed4a15bcdd89be3f0029a2cb6cdf170d.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: switch to i915 runtime pm callsJani Nikula1-3/+2
The i915 specific code doesn't need to, and should not, call the display runtime pm functions. Just call the i915 functions directly, instead of routing through the parent interface. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/e8e00552ebf439b5f7b5d293014cce950c9c2999.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: drop _common from the DPT file namesJani Nikula6-5/+5
With the intel_dpt.[ch] file names vacated, and i915 specific code moved away, we can rename the intel_dpt_common.[ch] files to the simpler name. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/3f2da737a26bb71a7bc05a3e6c456302e3c72656.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: remove display/intel_dpt.hJani Nikula6-23/+12
The remaining functions declared in intel_dpt.h are i915 specific, and so are the users, so we can move them to i915_dpt.h. There are some useless intel_dpt.h includes around that we can remove. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/de16eddbb49110b56ff44899d9498e3081da91fa.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: move suspend/resume to parent interfaceJani Nikula7-64/+89
Add per-vm DPT suspend/resume calls to the display parent interface, and lift the generic code away from i915 specific code. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/080945a49559ec1f5183ad409e1526736e828d90.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-02-26drm/i915/dpt: move create/destroy to parent interfaceJani Nikula8-30/+48
Move the DPT create/destroy calls to the display parent interface. With this, we can remove the dummy xe implementation. Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patch.msgid.link/9753b21466c668872f468ccff827eab7be034b0c.1772030909.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.