summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2025-05-16drm/radeon/cik: Clean up doorbellsDr. David Alan Gilbert
Free doorbells in the error paths of cik_init and in cik_fini. Build tested only. Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-05-16drm/nouveau/dp: convert to use ERR_CAST()Zhang Enpei
As opposed to open-code, use ERR_CAST to clearly indicate that this is a pointer to an error value and a type conversion is performed. Signed-off-by: Zhang Enpei <zhang.enpei@zte.com.cn> Link: https://lore.kernel.org/r/20250515201108576jof-gkjSxRfMaGDgKo-pc@zte.com.cn Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/nouveau/fifo: small cleanup in nvkm_chan_cctx_get()Dan Carpenter
"&chan->cgrp->mutex" and "&cgrp->mutex" are the same thing. Use "&cgrp->mutex" consistently. It looks nicer and it silences a Smatch static checker warning. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/aBHaCM66pXaP84ei@stanley.mountain Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/i915/dsi: Enforce pipeline flush with DSI HS transferGareth Yu
With all of the boundary conditions when streaming the commands B2B in our validation (part of the reason we added the flush), the Flush effectively serializes the transmission of each command enqueued within the command dispatcher to one per V. Blank line which simplifies the behavior of the High Speed Arbitration. So, unless we absolutely have to burst these to the Sink, we should be using the Pipeline Flush bit to serialize the commands. Bspec: 19742, 50193 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14247 Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Gareth Yu <gareth.yu@intel.com> Link: https://lore.kernel.org/r/20250509092539.763389-1-gareth.yu@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-16drm/nouveau: Check dma_fence in canonical wayPhilipp Stanner
In nouveau_fence_done(), a fence is checked for being signaled by manually evaluating the base fence's bits. This can be done in a canonical manner through dma_fence_is_signaled(). Replace the bit-check with dma_fence_is_signaled(). Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250424130254.42046-6-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/nouveau: Simplify nouveau_fence_done()Philipp Stanner
nouveau_fence_done() contains an if branch that checks whether a nouveau_fence has either of the two existing nouveau_fence backend ops, which will always evaluate to true. Remove the surplus check. Signed-off-by: Philipp Stanner <phasta@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250424130254.42046-5-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/nouveau: Simplify calls to nvif_event_block()Philipp Stanner
nouveau_fence_signal() returns a de-facto boolean to indicate when nvif_event_block() shall be called. The code can be made more compact and readable by calling nvif_event_block() in nouveau_fence_update() directly. Make those calls in nouveau_fence.c more canonical. Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250424130254.42046-4-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/nouveau: nouveau_fence: Standardize list iterationsPhilipp Stanner
nouveau_fence.c iterates over lists in a non-canonical way. Since the operations done are just basic for-each-loops and list-empty checks, they should be written in the standard form. Use standard list operations. Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20250424130254.42046-3-phasta@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-16drm/xe/mocs: Check if all domains awakeTejas Upadhyay
Check if all domains are awake specially for LNCF regs Fixes: 1182bc74b39b ("drm/xe: Fix MOCS debugfs LNCF readout") Improvements-suggested-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250506142300.1865783-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
2025-05-16drm/xe/pf: Don't allow LMEM provisioning if LMTT isn't available on the devicePiotr Piórkowski
The LMEM provisioning is applicable only on platforms with LMTT. v2: - new commit description - use xe_gt_assert in xe_gt_sriov_pf_config_set_lmem instead return error, - disable pf_lmem_info if LMTT is not available v3: fix condition in xe_gt_assert v4: rebase Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250513071321.700464-1-piotr.piorkowski@intel.com
2025-05-16drm/i915/dmc: Introduce dmc_configure_event()Ville Syrjälä
Instead of hardcoding the event handler indices (for runtime event handler enable/disable) we can simply look for the handler with the appropriate event type. This isolates us from the firmware details a bit better. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-8-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-05-16drm/i915/dmc: Extract is_event_handler()Ville Syrjälä
Extract the helper to determine if the mmio reg+data are the event handler register (DMC_EVT_CTL) for a specific event. We'll have another use for this for runtime event handler enable/disable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-7-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-05-16drm/i915/dmc: Relocate is_dmc_evt_{ctl,htp}_reg()Ville Syrjälä
Move is_dmc_evt_ctl_reg() to a slightly earlier position in the file so that we can reuse it in the pkgc workaround code. Also move is_dmc_evt_htp_reg() just to keep the two together. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-6-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-05-16drm/i915/dmc: Extract dmc_evt_ctl_disable()Ville Syrjälä
We have two copies of the code to generate the "disable this event" value for the DMC_EVT_CTL registers. Extract to a helper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-5-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coeho@intel.com>
2025-05-16drm/i915/dmc: Define all DMC event IDsVille Syrjälä
Define all the DMC event IDs to make life less misrable when having to deal with these. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-4-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-05-16drm/i915/dmc: Hook up PIPEDMC interruptsVille Syrjälä
Hook up PIPEDMC interrupts. We'll need these for: - flip queue signalling - GTT/ATS faults on LNL+ - unclaimed register access errors (supposedly that is what the error interrupt indicated according to Windows code). On LNL+ we get a new level of interrupts registers PIPEDMC_INTERRUPT*. On earlier platforms we only have the INT_VECTOR field in the PIPEDMC_STATUS registers, whose values are defined by the firmware. For now we'll enable the interrupts on LNL+ only. For earlier platforms it's not clear that there is any use for these interrupts, and some ADL machines have exhibited spurious DE_PIPE interrupts with the PIPEDMC interrupts unmasked/enabled. We can revisit enabling these for earlier platforms in the future. For some unknown reason LNL pipe B triggers the error interrupt during the first DC state transition (subsequent transitions are maybe OK?). No clear idea what's going on here yet, so keep the error interrupt disabled for now. Similar to DSB interrupt registers, the unused bits in PIPEDMC_INTERRUPT* seem to act like randomg r/w bits (instead of being hardwired to 0 like one would expect), and so we'll try to avoid setting them so that we don't mistake them for real interrupts. v2: Only enable/unmask for LNL+ Keep the flip queue interrupt masked off for now since we don't have a use for it yet v3: Also keep the error interrupt masked off for now due to LNL pipe B triggering it Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250514174257.8708-1-ville.syrjala@linux.intel.com
2025-05-16drm/i915/dmc: Drop PIPEDMC faults from the fault mask on LNL+Ville Syrjälä
On LNL+ PIPEDMC faults are reported via PIPEDMC interrupts instead of the direct DE_PIPE_* reporting used on earlier platforms. Drop the relevant bits from the fault mask. The bits are tied to zero on LNL, so there is no danger of spurious fault interrupts even with an incorrect mask. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-2-ville.syrjala@linux.intel.com Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
2025-05-16drm/{i915,xe}: convert i915 and xe display members into pointersJani Nikula
As the first step towards making struct intel_display an opaque pointer in i915 and xe drivers, convert the struct drm_i915_private and struct xe_device display members into pointers. Initially, add temporary struct intel_display __display members, and point display at it to avoid dynamic allocation. In the future, we can drop this, and switch to dynamic allocation. The conversion is done simply with sed: sed -i 's/&\([a-zA-Z0-9_>.-]*\)\(dev_priv\|i915\|xe\)->display\([^.]\)/\1\2->display\3/g' \ $(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe) sed -i 's/\(dev_priv\|i915\|xe\)->display\./\1->display->/g' \ $(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe) With a couple of manual tweaks on top. v2: Initialize i915->display also in selftest mock_gem_device() Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250507152254.2398934-1-jani.nikula@intel.com
2025-05-16drm/i915: do not reference i915->display inlineJani Nikula
Always use a local variable for display instead of referencing i915->display inline. This makes it easier to convert i915->display into a pointer. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/afcf305e8c4ea452cee37479530958f36a10c840.1746610601.git.jani.nikula@intel.com
2025-05-16drm/xe/display: do not reference xe->display inlineJani Nikula
Always use a local variable for display instead of referencing xe->display inline. This makes it easier to convert xe->display into a pointer. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/c99483ad86022d02f780bac73445baaf27a6edce.1746610601.git.jani.nikula@intel.com
2025-05-16drm/xe/rpm: use to_xe_device() instead of container_ofJani Nikula
Drop the dependency on display being a sub-struct of xe_device. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/3528f2cd5965e97248c161b8aa25a9df69606a39.1746610601.git.jani.nikula@intel.com
2025-05-16Merge drm/drm-next into drm-intel-nextJani Nikula
Backmerge to sync with v6.15-rc, xe, and specifically async flip changes in drm-misc. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-05-16Merge tag 'drm-xe-fixes-2025-05-15-1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Core Changes: - Add timeslicing and allocation restriction for SVM Driver Changes: - Fix shrinker debugfs name - Add HW workaround to Xe2 - Fix SVM when mixing GPU and CPU atomics - Fix per client engine utilization due to active contexts not saving timestamp with lite restore enabled. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/qil4scyn6ucnt43u5ju64bi7r7n5r36k4pz5rsh2maz7isle6g@lac3jpsjrrvs
2025-05-16Merge tag 'drm-misc-fixes-2025-05-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: dma-buf: - Avoid memory reordering in fence handling ivpu: - Fix buffer size in debugfs code meson: - Avoid integer overflow in mode-clock calculations panel-mipi-dbi: - Fix output with drm_client_setup_with_fourcc() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250515125534.GA41174@linux.fritz.box
2025-05-16Merge tag 'drm-intel-next-fixes-2025-05-15' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Stop writing ALPM registers when PSR is enabled - Use the correct connector while computing the link BPP limit on MST Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://lore.kernel.org/r/aCWlWk5rTE7TH1pN@jlahtine-mobl
2025-05-16Merge tag 'mediatek-drm-next-20250515' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20250515 1. Prepare for support MT8195/88 HDMIv2 and DDCv2 2. DPI: Cleanups and add support for more formats 3. Cleanups and sanitization 4. Replace custom compare_dev with component_compare_of Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://lore.kernel.org/r/20250514233647.15907-1-chunkuang.hu@kernel.org
2025-05-15drm/xe/guc: Track FAST_REQ H2Gs to report where errors came fromJohn Harrison
Most H2G messages are FAST_REQ which means no synchronous response is expected. The messages are sent as fire-and-forget with no tracking. However, errors can still be returned when something goes unexpectedly wrong. That leads to confusion due to not being able to match up the error response to the originating H2G. So add support for tracking the FAST_REQ H2Gs and matching up an error response to its originator. This is only enabled in XE_DEBUG builds given that such errors should never happen in a working system and there is an overhead for the tracking. Further, if XE_DEBUG_GUC is enabled then even more memory and time is used to record the call stack of each H2G and report that with the error. That makes it much easier to work out where a specific H2G came from if there are multiple code paths that can send it. v2: Some re-wording of comments and prints, more consistent use of #if vs stub functions - review feedback from Daniele & Michal). v3: Split config change to separate patch, improve a debug print (review feedback from Michal). v4: Bunch of minor tweaks (review feedback from Michal). Original-i915-code: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250512215324.1457009-5-John.C.Harrison@Intel.com
2025-05-15drm/xe/guc: Rename CONFIG_XE_LARGE_GUC_BUFFERJohn Harrison
Rename XE_LARGE_GUC_BUFFER to XE_DEBUG_GUC to allow for more debug only code (in subsequent patch) without adding more config defines that each control only a single thing. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250512215324.1457009-4-John.C.Harrison@Intel.com
2025-05-15drm/xe/guc: Add missing H2G error code definitionsJohn Harrison
These error codes are not actually used in the driver but it is extremely useful to have them available to understand error messages. v2: Add a bunch more error codes and drop 'status' from names (review feedback by Michal W). v3: Drop 'SUCCESS' response as meaningless in current API (review feedback by Michal W). Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250512215324.1457009-3-John.C.Harrison@Intel.com
2025-05-15drm/xe/guc: Remove double blank lineJohn Harrison
An earlier patch moved a drm_print a few lines lower but accidentally left a double blank line behind. So fix that. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://lore.kernel.org/r/20250512215324.1457009-2-John.C.Harrison@Intel.com
2025-05-15gpu: drm: nova: select AUXILIARY_BUS instead of depending on itAlexandre Courbot
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select it we have no way to include it (and thus to enable NOVA_DRM) unless another driver happens to do it for us. Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250515-aux_bus-v2-3-47c70f96ae9b@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-15gpu: nova-core: select AUXILIARY_BUS instead of depending on itAlexandre Courbot
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select it we have no way to include it (and thus to enable NOVA_CORE) unless another driver happens to do it for us. Fixes: e041d81a0377 ("gpu: nova-core: register auxiliary device for nova-drm") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250515-aux_bus-v2-2-47c70f96ae9b@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-05-15drm/i915/pci: Remove force_probe requirement for DG1Ville Syrjälä
Dunno why we still have .require_force_probe=1 on DG1 after all this time. I'm not aware of any real problems with DG1, so get rid of the force_probe requirement. Generally the difficulty with DG1 is that it requires a 4GiB BAR for the local memory, and that's not something that works on every system. Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250411144313.11660-3-ville.syrjala@linux.intel.com
2025-05-15drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1Ville Syrjälä
The intel-media-driver is currently broken on DG1 because it uses EXEC_CAPTURE with recovarable contexts. Relax the check to allow that. I've also submitted a fix for the intel-media-driver: https://github.com/intel/media-driver/pull/1920 Cc: stable@vger.kernel.org # v6.0+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Testcase: igt/gem_exec_capture/capture-invisible Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts") Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250411144313.11660-2-ville.syrjala@linux.intel.com
2025-05-15drm/xe/guc_submit: Simplify and fix diff calculationLucas De Marchi
With a u32 type, there's no need to check which one is greater: the current is always the latest and if it's less than the previous, it's because it wrapped: just do the unsigned calculation that will lead to the same result, or better the correct one. It fixes an off-by-one in the wrapped calculation, however that doesn't really matter for the timeout calculation. Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250513-time-wrap-v1-1-fba9a69a65c8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-15dma-fence: Change signature of __dma_fence_is_laterTvrtko Ursulin
With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we change the prototype of __dma_fence_is_later() to take fence instead of fence->ops. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250515095004.28318-2-tvrtko.ursulin@igalia.com Signed-off-by: Christian König <christian.koenig@amd.com>
2025-05-15drm/hyperv: Replace simple-KMS with regular atomic helpersRyosuke Yasuoka
Drop simple-KMS in favor of regular atomic helpers to make the code more modular. The simple-KMS helper mix up plane and CRTC state, so it is obsolete and should go away [1]. Since it just split the simple-pipe functions into per-plane and per-CRTC, no functional changes is expected. [1] https://lore.kernel.org/lkml/dae5089d-e214-4518-b927-5c4149babad8@suse.de/ Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Link: https://lore.kernel.org/r/20250427101825.812766-1-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-05-15drm/xe/guc: Don't allocate managed BO for each policy changeMichal Wajdeczko
We shouldn't use xe_managed_bo_create_from_data() to allocate temporary BO, as it will be released only on unload and every change in wedge_mode policy will consume resources (including precious GGTT). Instead just switchover to GuC buffer cache. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250512220018.172-3-michal.wajdeczko@intel.com
2025-05-15drm/xe/guc: Unblock GuC buffer cache for all modesMichal Wajdeczko
Today we were using GuC buffer cache only in the PF mode, but shortly we will want to use it also in native and VF mode. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20250512220018.172-2-michal.wajdeczko@intel.com
2025-05-15Merge tag 'drm-misc-next-2025-05-12' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.16-rc1: Once more, with async flips. UAPI Changes: - Add IN_FORMATS_ASYNC property, use in i915. Cross-subsystem Changes: - Remove some unused debug code in dma-buf. Core Changes: Driver Changes: - Add Novatek NT37801 panel. - Allow submitting empty commands in amdxdna. - Convert cirrus to use managed request_all_regions. - Move Sitronix from tiny to their own place. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/23ded62c-6a62-4195-9c08-4dfb81eafd72@linux.intel.com
2025-05-14drm/mediatek: Replace custom compare_dev with component_compare_ofTang Dongxing
Remove the custom device comparison function compare_dev and replace it with the existing kernel helper component_compare_of Signed-off-by: Tang Dongxing <tang.dongxing@zte.com.cn> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403155419406T5YhIJKId1FWor70EWWHG@zte.com.cn/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-05-14drm/mediatek: mtk_drm_drv: Unbind secondary mmsys components on errAngeloGioacchino Del Regno
When calling component_bind_all(), if a component that is included in the list fails, all of those that have been successfully bound will be unbound, but this driver has two components lists for two actual devices, as in, each mmsys instance has its own components list. In case mmsys0 (or actually vdosys0) is able to bind all of its components, but the secondary one fails, all of the components of the first are kept bound, while the ones of mmsys1/vdosys1 are correctly cleaned up. This is not right because, in case of a failure, the components are re-bound for all of the mmsys/vdosys instances without caring about the ones that were previously left in a bound state. Fix that by calling component_unbind_all() on all of the previous component masters that succeeded binding all subdevices when any of the other masters errors out. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-4-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-05-14drm/mediatek: Fix kobject put for component sub-driversAngeloGioacchino Del Regno
In function mtk_drm_get_all_drm_priv(), this driver is incrementing the refcount for the sub-drivers of mediatek-drm with a call to device_find_child() when taking a reference to all of those child devices. When the component bind fails multiple times this results in a refcount_t overflow, as the reference count is never decremented: fix that by adding a call to put_device() for all of the mmsys devices in a loop, in error cases of mtk_drm_bind() and in the mtk_drm_unbind() callback. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-3-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-05-14drm/mediatek: mtk_drm_drv: Fix kobject put for mtk_mutex device ptrAngeloGioacchino Del Regno
This driver is taking a kobject for mtk_mutex only once per mmsys device for each drm-mediatek driver instance, differently from the behavior with other components, but it is decrementing the kobj's refcount in a loop and once per mmsys: this is not right and will result in a refcount_t underflow warning when mediatek-drm returns multiple probe deferrals in one boot (or when manually bound and unbound). Besides that, the refcount for mutex_dev was not decremented for error cases in mtk_drm_bind(), causing another refcount_t warning but this time for overflow, when the failure happens not during driver bind but during component bind. In order to fix one of the reasons why this is happening, remove the put_device(xx->mutex_dev) loop from the mtk_drm_kms_init()'s put_mutex_dev label (and drop the label) and add a single call to correctly free the single incremented refcount of mutex_dev to the mtk_drm_unbind() function to fix the refcount_t underflow. Moreover, add the same call to the error cases in mtk_drm_bind() to fix the refcount_t overflow. Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250403104741.71045-2-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-05-14drm/xe: Add WA BB to capture active context utilizationUmesh Nerlige Ramappa
Context Timestamp (CTX_TIMESTAMP) in the LRC accumulates the run ticks of the context, but only gets updated when the context switches out. In order to check how long a context has been active before it switches out, two things are required: (1) Determine if the context is running: To do so, we program the WA BB to set an initial value for CTX_TIMESTAMP in the LRC. The value chosen is 1 since 0 is the initial value when the LRC is initialized. During a query, we just check for this value to determine if the context is active. If the context switched out, it would overwrite this location with the actual CTX_TIMESTAMP MMIO value. Note that WA BB runs as the last part of the context restore, so reusing this LRC location will not clobber anything. (2) Calculate the time that the context has been active for: The CTX_TIMESTAMP ticks only when the context is active. If a context is active, we just use the CTX_TIMESTAMP MMIO as the new value of utilization. While doing so, we need to read the CTX_TIMESTAMP MMIO for the specific engine instance. Since we do not know which instance the context is running on until it is scheduled, we also read the ENGINE_ID MMIO in the WA BB and store it in the PPHSWP. Using the above 2 instructions in a WA BB, capture active context utilization. v2: (Matt Brost) - This breaks TDR, fix it by saving the CTX_TIMESTAMP register "drm/xe: Save CTX_TIMESTAMP mmio value instead of LRC value" - Drop tile from LRC if using gt "drm/xe: Save the gt pointer in LRC and drop the tile" v3: - Remove helpers for bb_per_ctx_ptr (Matt) - Add define for context active value (Matt) - Use 64 bit CTX TIMESTAMP for platforms that support it. For platforms that don't, live with the rare race. (Matt, Lucas) - Convert engine id to hwe and get the MMIO value (Lucas) - Correct commit message on when WA BB runs (Lucas) v4: - s/GRAPHICS_VER(...)/xe->info.has_64bit_timestamp/ (Matt) - Drop support for active utilization on a VF (CI failure) - In xe_lrc_init ensure the lrc value is 0 to begin with (CI regression) v5: - Minor checkpatch fix - Squash into previous commit and make TDR use 32-bit time - Update code comment to match commit msg Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4532 Cc: <stable@vger.kernel.org> # v6.13+ Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250509161159.2173069-8-umesh.nerlige.ramappa@intel.com (cherry picked from commit 82b98cadb01f63cdb159e596ec06866d00f8e8c7) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-14drm/xe: Save the gt pointer in lrc and drop the tileUmesh Nerlige Ramappa
Save the gt pointer in the lrc so that it can used for gt based helpers. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250509161159.2173069-7-umesh.nerlige.ramappa@intel.com (cherry picked from commit 741d3ef8b8b88fab2729ca89de1180e49bc9cef0) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-14drm/xe: Save CTX_TIMESTAMP mmio value instead of LRC valueUmesh Nerlige Ramappa
For determining actual job execution time, save the current value of the CTX_TIMESTAMP register rather than the value saved in LRC since the current register value is the closest to the start time of the job. v2: Define MI_STORE_REGISTER_MEM to fix compile error v3: Place MI_STORE_REGISTER_MEM sorted by MI_INSTR (Lucas) Fixes: 65921374c48f ("drm/xe: Emit ctx timestamp copy in ring ops") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250509161159.2173069-6-umesh.nerlige.ramappa@intel.com (cherry picked from commit 38b14233e5deff51db8faec287b4acd227152246) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-14drm/xe: Timeslice GPU on atomic SVM faultMatthew Brost
Ensure GPU can make forward progress on an atomic SVM GPU fault by giving the GPU a timeslice of 5ms v2: - Reduce timeslice to 5ms - Double timeslice on retry - Split out GPU SVM changes into independent patch v5: - Double timeslice in a few more places Fixes: 2f118c949160 ("drm/xe: Add SVM VRAM migration") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20250512135500.1405019-5-matthew.brost@intel.com (cherry picked from commit a5d8d3be1dea8154edbbea481081469627665659) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-14drm/gpusvm: Add timeslicing support to GPU SVMMatthew Brost
Add timeslicing support to GPU SVM which will guarantee the GPU a minimum execution time on piece of physical memory before migration back to CPU. Intended to implement strict migration policies which require memory to be in a certain placement for correct execution. Required for shared CPU and GPU atomics on certain devices. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://lore.kernel.org/r/20250512135500.1405019-4-matthew.brost@intel.com (cherry picked from commit 8dc1812b5b3a42311d28eb385eed88e2053ad3cb) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-05-14drm/xe: Strict migration policy for atomic SVM faultsMatthew Brost
Mixing GPU and CPU atomics does not work unless a strict migration policy of GPU atomics must be device memory. Enforce a policy of must be in VRAM with a retry loop of 3 attempts, if retry loop fails abort fault. Removing always_migrate_to_vram modparam as we now have real migration policy. v2: - Only retry migration on atomics - Drop alway migrate modparam v3: - Only set vram_only on DGFX (Himal) - Bail on get_pages failure if vram_only and retry count exceeded (Himal) - s/vram_only/devmem_only - Update xe_svm_range_is_valid to accept devmem_only argument v4: - Fix logic bug get_pages failure v5: - Fix commit message (Himal) - Mention removing always_migrate_to_vram in commit message (Lucas) - Fix xe_svm_range_is_valid to check for devmem pages - Bail on devmem_only && !migrate_devmem (Thomas) v6: - Add READ_ONCE barriers for opportunistic checks (Thomas) - Pair READ_ONCE with WRITE_ONCE (Thomas) v7: - Adjust comments (Thomas) Fixes: 2f118c949160 ("drm/xe: Add SVM VRAM migration") Cc: stable@vger.kernel.org Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20250512135500.1405019-3-matthew.brost@intel.com (cherry picked from commit a9ac0fa455b050d03e3032501368048fb284d318) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-10 05:04:14 +0000