summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/gt
AgeCommit message (Collapse)AuthorFilesLines
2025-03-04drm/i915: Use REG_BIT() & co. for ring fault registersVille Syrjälä2-17/+17
Update the ring fault registers to use the modern REG_BIT() stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-4-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Relocate RING_FAULT bitsVille Syrjälä1-7/+9
We share the bit definitions between the older RING_FAULT registers and their various gen12+ counterparts. Currently the bits are defined next to the new registers which isn't what we typically do. Move the bit definitions next the older register offsets, and leave breadcrumbs around the gen12+ registers to make it easier to find the right bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-3-ville.syrjala@linux.intel.com
2025-03-04drm/i915: Bump RING_FAULT engine ID bitsVille Syrjälä1-1/+1
The fault engine ID field has been 5 bits since icl. Bump our define to match. The extra bits were unused before icl so we should be able to use the larger mask unconditionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250211231941.22769-2-ville.syrjala@linux.intel.com
2025-02-27Merge tag 'drm-intel-next-2025-02-24' of ↵Dave Airlie30-47/+74
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next drm/i915 feature pull for v6.15: Features and functionality: - Enable DP 128b/132b SST DSC (Jani, Imre) - Allow DSB to perform commits when VRR is enabled (Ville) - Compute HDMI PLLs for SNPS/C10 PHYs for rates not in fixed tables (Ankit) - Allow DSB usage when PSR is enabled on LNL+ (Jouni) - Enable Panel Replay mode change without full modeset (Jouni) - Enable async flips with compressed buffers on ICL+ (Ville) - Support luminance based brightness control via DPCD for eDP (Suraj) - Enable VRR enable/disable without full modeset (Mitul, Ankit) - Add debugfs facility for force testing HDCP 1.4 (Suraj) - Add scaler tracepoints, improve plane tracepoints (Ville) - Improve DMC wakelock debugging facilities (Gustavo) - Allow GuC SLPC default strategies on MTL+ for performance (Rodrigo) - Provide more information on display faults (Ville) Refactoring and cleanups: - Continue conversions to struct intel_display (Ville, Jani, Suraj, Imre) - Joiner and Y plane reorganization (Ville) - Move HDCP debugfs to intel_hdcp.c (Jani) - Clean up and unify LSPCON interfaces (Jani) - Move code out of intel_display.c to reduce its size (Ville) - Clean up and simplify DDI port enabling/disabling (Imre) - Make LPT LP a dedicated PCH type, refactor (Jani) - Simplify DSC range BPG offset calculation (Ankit) - Scaler cleanups (Ville) - Remove unused code from GVT (David Alan Gilbert) - Improve plane debugging (Ville) - DSB and VRR refactoring (Ville) Fixes: - Check if vblank is sufficient for DSC prefill and scaler (Mitul) - Fix Mesa clear color alignment regression (Ville) - Add missing TC DP PHY lane stagger delay (Imre) - Fix DSB + VRR usage for PTL+ (Ville) - Improve robustness of display VT-d workarounds (Ville) - Fix platforms for dbuf tracker state service programming (Ravi) - Fix DMC wakelock support conditions (Gustavo) - Amend DMC wakelock register ranges (Gustavo) - Disable the Common Primary Timing Generator (CMTG) (Gustavo) - Enable C20 PHY SSC (Suraj) - Add workaround for DKL PHY DP mode write (Nemesa) - Fix build warnings on clamp() usage (Guenter Roeck, Ankit) - Fix error handling while adding a connector (Imre) - Avoid full modeset at probe on vblank delay mismatches (Ville) - Fix encoder HDMI check for HDCP line rekeying (Suraj) - Fix HDCP repeater authentication during topology change (Suraj) - Handle display PHY power state reset for power savings (Mika) - Fix typos all over the place (Nitin) - Update HDMI TMDS C20 parameters for various platforms (Dnyaneshwar) - Guarantee a minimum hblank time for 128b/132b and 8b/10b MST (Arun, Imre) - Do not hardcode LSPCON settle timeout (Giedrius Statkevičius) Xe driver changes: - Re-use display vmas when possible (Maarten) - Remove double pageflip (Maarten) - Enable DP tunneling (Imre) - Separate i915 and xe tracepoints (Ville) DRM core changes: - Increase DPCD eDP display control CAP size to 5 bytes (Suraj) - Add DPCD eDP version 1.5 definition (Suraj) - Add timeout parameter to drm_lspcon_set_mode() (Giedrius Statkevičius) Merges: - Backmerge drm-next (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87h64j7b7n.fsf@intel.com
2025-02-25Merge tag 'v6.14-rc4' into drm-nextDave Airlie1-2/+2
Backmerge Linux 6.14-rc4 at the request of tzimmermann so misc-next can base on rc4. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-02-18drm/i915/gt: add wait on depth stall done bit handlingJuha-Pekka Heikkila2-0/+9
Add writing of WAIT_ON_DEPTH_STALL_DONE_DISABLE for gen12, this is performance optimization. Bspec: 46132 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12411 Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214155712.2849848-2-juhapekka.heikkila@gmail.com
2025-02-18drm/i915/huc: Switch to use hrtimer_setup()Nam Cao1-2/+2
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/all/d293dd4dd9cb6a9bb9e99f3fc11ea174c6525bf8.1738746904.git.namcao@linutronix.de
2025-02-18Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-6/+30
Backmerging to get bugfixes from v6.14-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2025-02-17drm/i915/gt: Use spin_lock_irqsave() in interruptible contextKrzysztof Karas1-2/+2
spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock. Try to remedy the problem by saving irq state before spin lock acquisition. v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pusppq5ybyszau2oocboj3mtj5x574gwij323jlclm5zxvimmu@mnfg6odxbpsv (cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-17drm/i915/gt: Replace kmap with its safer kmap_local_page counterpartAndi Shyti2-6/+6
kmap_local_page(), unlike kmap(), performs a contextualized mapping of pages. This means the pages are mapped locally to the thread that created them, making them invisible outside the thread and safer to use. Replace kmap() and kunmap() with kmap_local_page() and kunmap_local() counterparts for improved safety. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214003437.1311476-1-andi.shyti@linux.intel.com
2025-02-13drm/i915/gt: Use spin_lock_irqsave() in interruptible contextKrzysztof Karas1-2/+2
spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock. Try to remedy the problem by saving irq state before spin lock acquisition. v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message Fixes: 2f2cc53b5fe7 ("drm/i915/guc: Close deregister-context race against CT-loss") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pusppq5ybyszau2oocboj3mtj5x574gwij323jlclm5zxvimmu@mnfg6odxbpsv
2025-02-13drm/i915: Use device wedged eventRaag Jadav1-0/+3
Now that we have device wedged event provided by DRM core, make use of it and support both driver rebind and bus-reset based recovery. With this in place, userspace will be notified of wedged device on gt reset failure. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-5-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-11drm/i915: Convert intel_display_power_{get,put}*() to intel_displayVille Syrjälä1-2/+4
Pass intel_display to the display power stuff. These are spread all over the place so tend to hinder clean conversions of whole files. TODO: The gt part/unpark power domain shenanigans need some kind of more abstract interface... v2: Deal with cmtg Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-7-ville.syrjala@linux.intel.com
2025-02-05Merge drm/drm-next into drm-intel-nextJani Nikula12-60/+42
Sync with v6.14-rc1. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-02-05Merge drm/drm-next into drm-intel-gt-nextTvrtko Ursulin30-68/+151
We need 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope") in order to land a i915 PMU simplification and a fix. That landed in 6.12 and we are stuck at 6.9 so lets bump things forward. Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2025-02-05drm/i915/slpc: Add sysfs for SLPC power profilesVinay Belgaumkar6-0/+125
Default SLPC power profile is Base(0). Power Saving mode(1) has conservative up/down thresholds and is suitable for use with apps that typically need to be power efficient. Selected power profile will be displayed in this format- $ cat slpc_power_profile [base] power_saving $ echo power_saving > slpc_power_profile $ cat slpc_power_profile base [power_saving] v2: Disable waitboost in power saving profile, update sysfs format and add some kernel doc for SLPC (Rodrigo) v3: Update doc with info about power profiles (Rodrigo) v4: Checkpatch warning and remove extra line (Rodrigo) Cc: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250117215753.749906-1-vinay.belgaumkar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-03drm/i915/guc: Debug print LRC state entries only if the context is pinnedDaniele Ceraolo Spurio1-6/+14
After the context is unpinned the backing memory can also be unpinned, so any accesses via the lrc_reg_state pointer can end up in unmapped memory. To avoid that, make sure to only access that memory if the context is pinned when printing its info. v2: fix newline alignment Fixes: 28ff6520a34d ("drm/i915/guc: Update GuC debugfs to support new GuC") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115001334.3875347-1-daniele.ceraolospurio@intel.com (cherry picked from commit 5bea40687c5cf2a33bf04e9110eb2e2b80222ef5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-02-03drm/i915/pmu: Fix zero delta busyness issueUmesh Nerlige Ramappa1-0/+16
When running igt@gem_exec_balancer@individual for multiple iterations, it is seen that the delta busyness returned by PMU is 0. The issue stems from a combination of 2 implementation specific details: 1) gt_park is throttling __update_guc_busyness_stats() so that it does not hog PCI bandwidth for some use cases. (Ref: 59bcdb564b3ba) 2) busyness implementation always returns monotonically increasing counters. (Ref: cf907f6d29421) If an application queried an engine while it was active, engine->stats.guc.running is set to true. Following that, if all PM wakeref's are released, then gt is parked. At this time the throttling of __update_guc_busyness_stats() may result in a missed update to the running state of the engine (due to (1) above). This means subsequent calls to guc_engine_busyness() will think that the engine is still running and they will keep updating the cached counter (stats->total). This results in an inflated cached counter. Later when the application runs a workload and queries for busyness, we return the cached value since it is larger than the actual value (due to (2) above) All subsequent queries will return the same large (inflated) value, so the application sees a delta busyness of zero. Fix the issue by resetting the running state of engines each time intel_guc_busyness_park() is called. v2: (Rodrigo) - Use the correct tag in commit message - Drop the redundant wakeref check in guc_engine_busyness() and update commit message Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13366 Fixes: cf907f6d2942 ("i915/guc: Ensure busyness counter increases motonically") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250123193839.2394694-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 431b742e2bfc9f6dd713f261629741980996d001) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-30Revert "drm/i915/gt: Log reason for setting TAINT_WARN at reset"Sebastian Brzezinka1-5/+1
This reverts commit 835443da6f50d9516b58bba5a4fdf9e563d961c7. Logging with gt_err() causes CI to detect an error even in cases of intentional error injection. Since real errors are already correctly reported by CI, this additional message is unnecessary. Furthermore, a GT wedge is already being logged elsewhere, so instead of adjusting the log level, revert the above mentioned commit to prevent redundant error reporting. Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/pynwwza2xyvicokflxc6lduwwrzwoihihaan54ago3m2xzzagu@qva2ue4tydie
2025-01-29drm/i915/guc: Debug print LRC state entries only if the context is pinnedDaniele Ceraolo Spurio1-6/+14
After the context is unpinned the backing memory can also be unpinned, so any accesses via the lrc_reg_state pointer can end up in unmapped memory. To avoid that, make sure to only access that memory if the context is pinned when printing its info. v2: fix newline alignment Fixes: 28ff6520a34d ("drm/i915/guc: Update GuC debugfs to support new GuC") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250115001334.3875347-1-daniele.ceraolospurio@intel.com
2025-01-28drm/i915/guc/slpc: Add helper function slpc_measure_powerSk Anirban1-1/+16
Previously, the RPS function was being used, which utilizes raw frequency to calculate measured power. This commit introduces a dedicated function specifically for measuring power in SLPC, ensuring more accurate and reliable power measurements. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113095912.356147-3-sk.anirban@intel.com
2025-01-28drm/i915/selftests: Correct frequency handling in RPS power measurementSk Anirban1-1/+1
Fix the frequency calculation by ensuring it uses the raw frequency only. Update live_rps_power test to use the correct frequency values for logging and comparison. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250113095912.356147-2-sk.anirban@intel.com
2025-01-28drm/i915: Add Wa_22010465259 in its respective WA listRanu Maurya1-6/+7
Add Wa_22010465259 which points to an existing WA, but was missing from the comment list. While at it, update the other WAs and their applicable platforms as well. v1: Initial commit. v2: Add DG2 platform to Wa_22010465259. v3: Removed DG2 platform to Wa_22010465259 since it was for preproduction. Signed-off-by: Ranu Maurya <ranu.maurya@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250116093115.2437154-1-ranu.maurya@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2025-01-28drm/i915/pmu: Fix zero delta busyness issueUmesh Nerlige Ramappa1-0/+16
When running igt@gem_exec_balancer@individual for multiple iterations, it is seen that the delta busyness returned by PMU is 0. The issue stems from a combination of 2 implementation specific details: 1) gt_park is throttling __update_guc_busyness_stats() so that it does not hog PCI bandwidth for some use cases. (Ref: 59bcdb564b3ba) 2) busyness implementation always returns monotonically increasing counters. (Ref: cf907f6d29421) If an application queried an engine while it was active, engine->stats.guc.running is set to true. Following that, if all PM wakeref's are released, then gt is parked. At this time the throttling of __update_guc_busyness_stats() may result in a missed update to the running state of the engine (due to (1) above). This means subsequent calls to guc_engine_busyness() will think that the engine is still running and they will keep updating the cached counter (stats->total). This results in an inflated cached counter. Later when the application runs a workload and queries for busyness, we return the cached value since it is larger than the actual value (due to (2) above) All subsequent queries will return the same large (inflated) value, so the application sees a delta busyness of zero. Fix the issue by resetting the running state of engines each time intel_guc_busyness_park() is called. v2: (Rodrigo) - Use the correct tag in commit message - Drop the redundant wakeref check in guc_engine_busyness() and update commit message Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13366 Fixes: cf907f6d2942 ("i915/guc: Ensure busyness counter increases motonically") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250123193839.2394694-1-umesh.nerlige.ramappa@intel.com
2025-01-23drm/i915/gt: fix typos in i915/gt files.Nitin Gote28-38/+38
Fix all typos in files under drm/i915/gt reported by codespell tool. v2: Fix grammar mistake in comment. <Andi> v3: Correct typo in commit log. <Krzysztof Niemiec> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250120081517.3237326-2-nitin.r.gote@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-22Merge tag 'kthread-for-6.14-rc1' of ↵Linus Torvalds3-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks Pull kthread updates from Frederic Weisbecker: "Kthreads affinity follow either of 4 existing different patterns: 1) Per-CPU kthreads must stay affine to a single CPU and never execute relevant code on any other CPU. This is currently handled by smpboot code which takes care of CPU-hotplug operations. Affinity here is a correctness constraint. 2) Some kthreads _have_ to be affine to a specific set of CPUs and can't run anywhere else. The affinity is set through kthread_bind_mask() and the subsystem takes care by itself to handle CPU-hotplug operations. Affinity here is assumed to be a correctness constraint. 3) Per-node kthreads _prefer_ to be affine to a specific NUMA node. This is not a correctness constraint but merely a preference in terms of memory locality. kswapd and kcompactd both fall into this category. The affinity is set manually like for any other task and CPU-hotplug is supposed to be handled by the relevant subsystem so that the task is properly reaffined whenever a given CPU from the node comes up. Also care should be taken so that the node affinity doesn't cross isolated (nohz_full) cpumask boundaries. 4) Similar to the previous point except kthreads have a _preferred_ affinity different than a node. Both RCU boost kthreads and RCU exp kworkers fall into this category as they refer to "RCU nodes" from a distinctly distributed tree. Currently the preferred affinity patterns (3 and 4) have at least 4 identified users, with more or less success when it comes to handle CPU-hotplug operations and CPU isolation. Each of which do it in its own ad-hoc way. This is an infrastructure proposal to handle this with the following API changes: - kthread_create_on_node() automatically affines the created kthread to its target node unless it has been set as per-cpu or bound with kthread_bind[_mask]() before the first wake-up. - kthread_affine_preferred() is a new function that can be called right after kthread_create_on_node() to specify a preferred affinity different than the specified node. When the preferred affinity can't be applied because the possible targets are offline or isolated (nohz_full), the kthread is affine to the housekeeping CPUs (which means to all online CPUs most of the time or only the non-nohz_full CPUs when nohz_full= is set). kswapd, kcompactd, RCU boost kthreads and RCU exp kworkers have been converted, along with a few old drivers. Summary of the changes: - Consolidate a bunch of ad-hoc implementations of kthread_run_on_cpu() - Introduce task_cpu_fallback_mask() that defines the default last resort affinity of a task to become nohz_full aware - Add some correctness check to ensure kthread_bind() is always called before the first kthread wake up. - Default affine kthread to its preferred node. - Convert kswapd / kcompactd and remove their halfway working ad-hoc affinity implementation - Implement kthreads preferred affinity - Unify kthread worker and kthread API's style - Convert RCU kthreads to the new API and remove the ad-hoc affinity implementation" * tag 'kthread-for-6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks: kthread: modify kernel-doc function name to match code rcu: Use kthread preferred affinity for RCU exp kworkers treewide: Introduce kthread_run_worker[_on_cpu]() kthread: Unify kthread_create_on_cpu() and kthread_create_worker_on_cpu() automatic format rcu: Use kthread preferred affinity for RCU boost kthread: Implement preferred affinity mm: Create/affine kswapd to its preferred node mm: Create/affine kcompactd to its preferred node kthread: Default affine kthread to its preferred NUMA node kthread: Make sure kthread hasn't started while binding it sched,arm64: Handle CPU isolation on last resort fallback rq selection arm64: Exclude nohz_full CPUs from 32bits el0 support lib: test_objpool: Use kthread_run_on_cpu() kallsyms: Use kthread_run_on_cpu() soc/qman: test: Use kthread_run_on_cpu() arm/bL_switcher: Use kthread_run_on_cpu()
2025-01-17drm/i915/uc: Include requested frequency in slow firmware load messagesJohn Harrison2-10/+13
To aid debug of sporadic issues, include the requested frequency in the debug message as well as the actual frequency. That way we know for certain that the clamping is not because the driver forgot to ask. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241221014329.4048408-1-John.C.Harrison@Intel.com
2025-01-15drm/i915: Add debug print about hw config table sizeJohn Harrison1-0/+3
Add debug info to help investigate a very rare bug: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13385 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241221011925.3944625-1-John.C.Harrison@Intel.com
2025-01-13drm/i915/guc/slpc: Print more SLPC debug status informationRodrigo Vivi1-0/+17
Let's peek on the Balancer and DCC status, now that we are using the default strategies. v2: fix identation v3: fix typo (Vinay) Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250110144640.1032250-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-13drm/i915/guc/slpc: Allow GuC SLPC default strategies on MTL+Rodrigo Vivi1-7/+15
The Balancer and DCC strategies were left off on a fear that these strategies would conflict with the i915's waitboost. However, on MTL and Beyond these strategies are only active in certain conditions where the system is TDP limited. So, they don't conflict, but help the waitboost by guaranteeing a bit more of GT frequency. Without these strategies we were likely leaving some performance behind on some scenarios. With this change in place, the enabling/disabling of DCC and Balancer will now be chosen by GuC, on a platform/GT basis. v2: - Fix typos and be clear on GuC decision on platform basis (Vinay) - Limit change to MTL and beyond, where GuC started to take TDP limit into consideration. v3: Fix compilation. Actually amend the changes... Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250110144640.1032250-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-13Merge tag 'drm-intel-gt-next-2025-01-10' of ↵Dave Airlie9-57/+39
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: - More robust engine resets on Haswell and older (Nitin) - Dead code removal (David) - Selftest, logging and tracing improvements (Sk, Nitin, Sebastian, Apoorva) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z4DidoEACFu7D6iG@jlahtine-mobl.ger.corp.intel.com
2025-01-11drm/i915/selftest: Change throttle criteria for rpsRaag Jadav1-5/+6
Current live_rps_control() implementation errors out on throttling. This was done with the assumption that throttling to minimum frequency is a catastrophic failure, which is incorrect. Throttling can happen due to variety of reasons and often times out of our control. Also, the resulting frequency can be at any given point below the maximum allowed. Change throttle criteria to reflect this logic and drop the error, as it doesn't necessarily mean selftest failure. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250102110618.174415-1-raag.jadav@intel.com
2025-01-09drm/i915/gt: Prefer IS_ENABLED() instead of defined() on config optionNitin Gote1-1/+1
Use IS_ENABLED() instead of defined() for checking whether a kconfig option is enabled. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103062651.798249-2-nitin.r.gote@intel.com
2025-01-08treewide: Introduce kthread_run_worker[_on_cpu]()Frederic Weisbecker3-3/+3
kthread_create() creates a kthread without running it yet. kthread_run() creates a kthread and runs it. On the other hand, kthread_create_worker() creates a kthread worker and runs it. This difference in behaviours is confusing. Also there is no way to create a kthread worker and affine it using kthread_bind_mask() or kthread_affine_preferred() before starting it. Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]() that behaves just like kthread_run(). kthread_create_worker[_on_cpu]() will now only create a kthread worker without starting it. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
2025-01-08drm/i915/gt: Prevent uninitialized pointer readsApoorva Singh1-1/+1
Initialize rq to NULL to prevent uninitialized pointer reads. Signed-off-by: Apoorva Singh <apoorva.singh@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241227112920.1547592-1-apoorva.singh@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-01-07Merge drm/drm-next into drm-intel-nextJani Nikula5-16/+55
Backmerge to get the DRM DP payload and ACT helpers to drm-intel-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-30drm/i915: Remove unused intel_ring_cacheline_alignDr. David Alan Gilbert2-25/+0
The last use of intel_ring_cacheline_align() was removed in 2017 by commit afa8ce5b3080 ("drm/i915: Nuke legacy flip queueing code") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Tvrtko Ursulin <tursulin@igalia.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241227113754.25871-3-tursulin@igalia.com
2024-12-30drm/i915: Remove unused intel_huc_suspendDr. David Alan Gilbert2-14/+0
intel_huc_suspend() was added in 2022 by commit 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence") but hasn't been used. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Tvrtko Ursulin <tursulin@igalia.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241227113754.25871-2-tursulin@igalia.com
2024-12-23drm/i915/gt: Log reason for setting TAINT_WARN at resetSebastian Brzezinka1-1/+5
TAINT_WARN is used to notify CI about non-recoverable failures, which require device to be restarted. In some cases, there is no sufficient information about the reason for the restart. The test runner is just killed, and DUT is rebooted, logging only 'probe with driver i915 failed with error -4' to dmesg. Printing error to dmesg before TAINT_WARN, would explain why the device has been restarted, and what caused the malfunction in the first place. Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241220131714.1309483-1-andi.shyti@linux.intel.com
2024-12-20drm/i915/dg1: Fix power gate sequence.Rodrigo Vivi1-1/+1
sub-pipe PG is not present on DG1. Setting these bits can disable other power gates and cause GPU hangs on video playbacks. VLK: 16314, 4304 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13381 Fixes: 85a12d7eb8fe ("drm/i915/tgl: Fix Media power gate sequence.") Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219210019.70532-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-20drm/i915/gt: Use ENGINE_TRACE for tracing.Nitin Gote1-10/+11
Instead of drm_err(), prefer gt_err() and ENGINE_TRACE() for GEM tracing in i915. So, it will be good to use ENGINE_TRACE() over drm_err() drm_device based logging for engine debug log. v2: Bit more specific in commit description (Andi) v3: Use gt_err() along with ENGINE_TRACE() in place of drm_err() (Andi) Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217100058.2819053-1-nitin.r.gote@intel.com
2024-12-19drm/i915/selftests: Implement frequency logging for energy reading validationSk Anirban1-3/+14
Add RC6 & RC0 frequency printing to ensure accurate energy readings aimed at addressing GPU energy leaks and power measurement failures. Also update sleep time for RC6 mode to match RC0. v2: - Improved commit message. v3: - Used pr_err log to display frequency (Anshuman) - Sorted headers alphabetically (Sai Teja) v4: - Improved commit message. - Fix pr_err log (Sai Teja) v5: - Add error & debug logging for RC0 power and frequency checks (Anshuman) v6: - Modify debug logging for RC0 power and frequency checks (Sai Teja) v7: - Use pr_debug if RC0 power isn't measured but frequency is (Anshuman) - Improved commit message (Badal) - Change API to read actual frequency without applying forcewake (Badal) - Update sleep time for RC6 mode (Anshuman) Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241129154716.2764974-1-sk.anirban@intel.com
2024-12-19Merge tag 'drm-intel-gt-next-2024-12-18' of ↵Dave Airlie5-16/+55
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Driver Changes: - More accurate engine busyness metrics with GuC submission (Umesh) - Ensure partial BO segment offset never exceeds allowed max (Krzysztof) - Flush GuC CT receive tasklet during reset preparation (Zhanjun) - Code cleanups and refactoring (David, Lucas) - Debugging improvements (Jesus) - Selftest improvements (Sk) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Z2KadNXgumx1aQMP@jlahtine-mobl.ger.corp.intel.com
2024-12-18drm/i915/gt: Increase a time to retry RING_HEAD resetNitin Gote1-2/+7
Issue seen again where engine resets fails because the engine resumes from an incorrect RING_HEAD. HEAD is still not 0 even after writing into it. This seems to be timing issue and we experimented different values from 5ms to 50ms and found out that 50ms works best based on testing. So, if write doesn't succeed at first then retry again. v2: add a comment (Andi Shyti) Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12806 Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217063532.2729031-1-nitin.r.gote@intel.com
2024-12-17drm/i915/guc: Update guc_err message to show outstanding g2h responsesJesus Narvaez1-2/+6
Updating the guc_error message to show how many g2h responses are still outstanding, in order to help with future debugging. Signed-off-by: Jesus Narvaez <jesus.narvaez@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241213204720.3918056-1-jesus.narvaez@intel.com
2024-12-14i915/guc: Accumulate active runtime on gt resetUmesh Nerlige Ramappa1-1/+14
On gt reset, if a context is running, then accumulate it's active time into the busyness counter since there will be no chance for the context to switch out and update it's run time. v2: Move comment right above the if (John) Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-4-umesh.nerlige.ramappa@intel.com
2024-12-14i915/guc: Ensure busyness counter increases motonicallyUmesh Nerlige Ramappa2-1/+9
Active busyness of an engine is calculated using gt timestamp and the context switch in time. While capturing the gt timestamp, it's possible that the context switches out. This race could result in an active busyness value that is greater than the actual context runtime value by a small amount. This leads to a negative delta and throws off busyness calculations for the user. If a subsequent count is smaller than the previous one, just return the previous one, since we expect the busyness to catch up. Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-3-umesh.nerlige.ramappa@intel.com
2024-12-14i915/guc: Reset engine utilization buffer before registrationUmesh Nerlige Ramappa1-0/+21
On GT reset, we store total busyness counts for all engines and re-register the utilization buffer with GuC. At that time we should reset the buffer, so that we don't get spurious busyness counts on subsequent queries. To repro this issue, run igt@perf_pmu@busy-hang followed by igt@perf_pmu@most-busy-idle-check-all for a couple iterations. Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241127174006.190128-2-umesh.nerlige.ramappa@intel.com
2024-12-11Merge drm/drm-next into drm-intel-nextRodrigo Vivi9-39/+49
Catching up with 6.13-rc2. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-06drm/i915/selftests: Add delay to stabilize frequency in live_rps_powerSk Anirban1-0/+1
Add delays to allow frequency stabilization before power measurement to fix sporadic power conservation issues in live_rps_power test. v2: - Move delay to respective function (Badal) Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241203061114.2790448-1-sk.anirban@intel.com