- 19 Sep, 2022 2 commits
-
-
Janusz Krzysztofik authored
Due to i915_perf assuming that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration, we need to defer removal of the context from the list until last reference to the context is put. However, there is a risk of triggering kernel warning on contexts list not empty at driver release time if we deleagate that task to a worker for i915_gem_context_release_work(), unless that work is flushed first. Unfortunately, it is not flushed on driver release. Fix it. Instead of additionally calling flush_workqueue(), either directly or via a new dedicated wrapper around it, replace last call to i915_gem_drain_freed_objects() with existing i915_gem_drain_workqueue() that performs both tasks. Fixes: 75eefd82 ("drm/i915: Release i915_gem_context from a worker") Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Cc: stable@kernel.org # v5.16+ Signed-off-by:
-
Matt Roper authored
MTL has separate forcewake tables for the primary/render GT and the media GT; each GT's intel_uncore will use a separate forcewake table and should only initialize the domains that are relevant to that GT. The GT ack register also moves to a new location of (GSI base + 0xDFC) on this platform. Note that although our uncore handlers take care of transparently redirecting all register accesses in the media GT's GSI range to their new offset at 0x380000, the forcewake ranges listed in the table should use the final, post-translation offsets. NOTE: There are two ranges in the media IP that have multicast registers where the two register instances reside in different power wells (either VD0 or VD2). We don't have an easy way to deal with this today (and in fact we don't even access these register ranges in the driver today), so for now we just mark those ranges as FORCEWAKE_ALL which will cause all of the media power wells to be grabbed, ensuring proper operation. If we start reading/writing in those ranges in the future, we can re-visit whether it's worth adding extra steering complexity into our forcewake support. Bspec: 67788, 67789, 52077 Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220910001631.1986601-1-matthew.d.roper@intel.com
-
- 16 Sep, 2022 9 commits
-
-
John Harrison authored
A patch was merged to remove the GuC log size override module parameters. That patch was broken and caused kernel error messages on boot in non CONFIG_DEBUG_GUC|GEM builds: [ 12.085121] i915 0000:00:02.0: [drm] *ERROR* Zero GuC log crash dump size! [ 12.092035] i915 0000:00:02.0: [drm] *ERROR* Zero GuC log debug size! So fit it. Fixes: f54e515c ("drm/i915/guc: Remove log size module parameters") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Julia Lawall <Julia.Lawall@inria.fr> Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913010929.2734885-2-John.C.Harrison@Intel.com
-
Ashutosh Dixit authored
For MTL, when reading from HW, RP0, RP1 (actuall RPe) and RPn freq use an entirely different set of registers with different fields, bitwidths and units. v2: Move MTL check into a separate function (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ashutosh Dixit authored
PERF_LIMIT_REASONS register for MTL media gt is different now. v2: Avoid static inline for intel_gt_perf_limit_reasons_reg() (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
-
Tilak Tangudu authored
Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log" bits are identical to the lower 16 RO "status" bits except that the "log" bits remain set until cleared, thereby ensuring the throttling occurrence is not missed. The clear fop clears the upper 16 "log" bits, the get fop gets all 32 "log" and "status" bits. v2: Expand commit message and clarify "log" and "status" bits in comment (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
This, along with the changes already landed in commit 1c66a12a ("drm/i915: Handle each GT on init/release and suspend/resume") makes engines from all GTs actually known to the driver. To accomplish this we need to sprinkle a lot of for_each_gt calls around but is otherwise pretty un-eventuful. v2: - Consolidate adjacent GT loops in a couple places. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Walk all GTs when suspending. Signed-off-by:
-
Tvrtko Ursulin authored
Walk all GTs from i915_gem_resume when resuming engines. Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
Chris Wilson authored
If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated. v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz) Signed-off-by:
Chris Wilson <chris.p.wilson@intel.com> Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by:
-
John Harrison authored
Going forwards, the intention is for GuC firmware files to be named for their major version only and HuC firmware files to have no version number in the name at all. This patch adds those entries for all platforms that are officially GuC/HuC enabled. Also, update the expected GuC version numbers to the latest firmware release for those platforms. Signed-off-by:
-
- 15 Sep, 2022 3 commits
-
-
Lucas De Marchi authored
Continue converting the driver to the convention of last version first, extending it to the future platforms. Now, any GRAPHICS_VER >= 11 will be handled by the first branch. Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220908-if-ladder-v2-3-7a7b15545c93@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20220912-copy-engine-v1-1-ef92fd81758d@intel.com
-
Lucas De Marchi authored
Instead of calling read_clock_frequency() to walk the if/else ladder per platform, move the ladder to intel_gt_init_clock_frequency() and use one function per branch. With the new logic, it's now clear the call to gen9_get_crystal_clock_freq() was just dead code, as gen9 is handled by another function and there is no version 10. Remove that function and the caller. v2: Correctly handle intel_gt_check_clock_frequency() that also calls the function to read clock frequency (Gustavo) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Continue converting the driver to the convention of last version first, extending it to the future platforms. Now, any GRAPHICS_VER >= 11 will be handled by the first branch. With the new ranges it's easier to see what platform a branch started to be taken. Besides the >= 11 change, the branch taken for GRAPHICS_VER == 10 is also different, but currently there is no such platform in i915. Signed-off-by:
-
- 14 Sep, 2022 7 commits
-
-
John Harrison authored
The earlier update to support reduced versioning of firmware files introduced an issue with the firmware override module parameter. A self test would specify an invalid file name (invalid meaning not in the table) both with and without setting the override flag. The *non-override* case would cause an infinite loop. I.e. a situation that is impossible to hit outside of the selftest because either the file name has come from the table in first place or it came from an override. However, the override case was also broken in that it would bypass some of the later processing. The first fix is to update the scanning loop code so that if an invalid file is passed in, it will exit rather than loop forever. So if the impossible situation did somehow occur in the future, it wouldn't be such a big problem. The second flips the logic on the override early exit to be negative rather than positive. That way if an explicit override has been set, then it won't try to scan for backup options (because there is no point anyway - the user wanted X and if X is not available, that's their problem). It also means that it won't skip code that still needs to be run once a valid firmware file has been selected. v2: Also remove ANSI colour codes that accidentally got left in an error message in the original patch. Fixes: 665ae9c9 ("drm/i915/uc: Support for version reduced and multiple firmware files") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> 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 <tvrtko.ursulin@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by:
-
Anshuman Gupta authored
Release all mmap mapping for all lmem objects which are associated with userfault such that, while pcie function in D3hot, any access to memory mappings will raise a userfault. Runtime resume the dgpu(when gem object lies in lmem). This will transition the dgpu graphics function to D0 state if it was in D3 in order to access the mmap memory mappings. v2: - Squashes the patches. [Matt Auld] - Add adequate locking for lmem_userfault_list addition. [Matt Auld] - Reused obj->userfault_count to avoid double addition. [Matt Auld] - Added i915_gem_object_lock to check i915_gem_object_is_lmem. [Matt Auld] v3: - Use i915_ttm_cpu_maps_iomem. [Matt Auld] - Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld] - Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld] - Delete the mmaped obj from lmem_userfault_list in obj destruction path. [Matt Auld] - Get a wakeref for object destruction patch. [Matt Auld] - Use intel_wakeref_auto to delay runtime PM. [Matt Auld] v4: - Avoid using mmo offset to get the vma_node. [Matt Auld] - Added comment to use the lmem_userfault_lock. [Matt Auld] - Get lmem_userfault_lock in i915_gem_object_release_mmap_offset. [Matt Auld] - Fixed kernel test robot generated warning. v5: - Addressed the cosmetics comments. [Andi] - Changed i915_gem_runtime_pm_object_release_mmap_offset() name to i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic. PCIe Specs 5.3.1.4.1 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
-
Anshuman Gupta authored
Refactor userfault_wakeref to re-use for discrete lmem mmap mapping as well, as on discrete GTT mmap are not supported. Moving userfault_wakeref from ggtt to gt structure. Signed-off-by:
-
Chris Wilson authored
When testing whether we can get the GPU to leak information about non-privileged state, we first need to ensure that the output buffer is set to a known value as the HW may opt to skip the write into memory for a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a) so that is both non-zero and distinct from the poison values used during the test. v2: Use i915_gem_object_pin_map_unlocked Reported-by:
CQ Tang <cq.tang@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by:
Karolina Drobnik <karolina.drobnik@intel.com> Reviewed-by:
-
Chris Wilson authored
Ensure that we always signal the semaphore when timing out, so that if it happens to be stuck waiting for the semaphore we will quickly recover without having to wait for a reset. Reported-by:
-
Chris Wilson authored
In order to keep the context image parser simple, we assume that all commands follow a similar format. A few, especially not MI commands on the render engines, have fixed lengths not encoded in a length field. This caused us to incorrectly skip over 3D state commands, and start interpreting context data as instructions. Eventually, as Daniele discovered, this would lead us to find addition LRI as part of the data and mistakenly add invalid LRI commands to the context probes. Stop parsing after we see the first !MI command, as we know we will have seen all the context registers by that point. (Mostly true for all gen so far, though the render context does have LRI after the first page that we have been ignoring so far. It would be useful to extract those as well so that we have the full list of user accessible registers.) Similarly, emit a warning if we do try to emit an invalid zero-length LRI. Testcase: igt@i915_selftest@live@gt_lrc Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6580 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6670Reported-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
Chris Wilson authored
Even though the initial protocontext we load onto HW has the register cleared, by the time we save it into the default image, BB_OFFSET has had the enable bit set. Reclear BB_OFFSET for each new context. Testcase: igt/i915_selftests/gt_lrc v2: Extend it for gen8. v3: BB_OFFSET is recorded per engine from Gen9 onwards Signed-off-by:
-
- 13 Sep, 2022 2 commits
-
-
Lucas De Marchi authored
Support for reading the fuses to check what are the Link Copy engines was added in commit ad5f74f3 ("drm/i915/pvc: read fuses for link copy engines"). However they were added unconditionally because the FUSE3 register is present since graphics version 10. However the bitfield with meml3 fuses only exists since graphics version 12. Moreover, Link Copy engines are currently only available in PVC. Tying additional copy engines to the meml3 fuses is not correct for other platforms. Make sure there is a check for `12.60 <= ver < 12.70`. Later platforms may extend this function later if it's needed to fuse off copy engines. Currently it's harmless as the Link Copy engines are still not exported: info->engine_mask only has BCS0 set and the register is only read for platforms that do have it. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912-copy-engine-v1-1-ef92fd81758d@intel.com
-
Gaosheng Cui authored
i915_gem_lmem_obj_ops has been removed since commit 213d5092 ("drm/i915/ttm: Introduce a TTM i915 gem object backend"), so remove it. Signed-off-by:
Gaosheng Cui <cuigaosheng1@huawei.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 12 Sep, 2022 17 commits
-
-
Lucas De Marchi authored
Just like is done for compute and copy engines, extract a function to handle media engines. While at it, be consistent on using or not the uncore/gt/info variable aliases. Reviewed-by:
-
Lucas De Marchi authored
Check for media IP version instead of graphics since this is figuring out the media engines' configuration. Currently the only platform with non-matching graphics/media version is Meteor Lake: update the check in gen11_vdbox_has_sfc() so it considers not only version 12, but also any later version which then includes that platform. Reviewed-by:
-
Matt Roper authored
Top-level handling of standalone media interrupts will be processed as part of the primary GT's interrupt handler (since primary and media GTs share an MMIO space, unlike remote tile setups). When we get down to the point of handling engine interrupts, we need to take care to lookup VCS and VECS engines in the media GT rather than the primary. There are also a couple of additional "other" instance bits that correspond to the media GT's GuC and media GT's power management interrupts; we need to direct those to the media GT instance as well. Bspec: 45605 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Matt Roper authored
When we hook up interrupts (in the next patch), interrupts for the media GT are still processed as part of the primary GT's interrupt flow. As such, we should share the same IRQ lock with the primary GT. Let's convert gt->irq_lock into a pointer and just point the media GT's instance at the same lock the primary GT is using. v2: - Point media's gt->irq_lock at the primary GT lock properly. (Daniele) - Fix jump target for intel_root_gt_init_early errors. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
Xe_LPM+ platforms have "standalone media." I.e., the media unit is designed as an additional GT with its own engine list, GuC, forcewake, etc. Let's allow platforms to include media GTs in their device info. v2: - Simplify GSI register handling and split it out to a separate patch for ease of review. (Daniele) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Acked-by:
-
Matt Roper authored
The aux table invalidation registers are a bit unique --- they're engine-centric registers that reside in the GSI register space rather than within the engines' regular MMIO ranges. That means that when issuing invalidation on engines in the standalone media GT, the GSI offset must be added to the regular MMIO offset for the invalidation registers. Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
-
Matt Roper authored
GT non-engine registers (referred to as "GSI" registers by the spec) have the same relative offsets on standalone media as they do on the primary GT, just with an additional "GSI offset" added to their MMIO address. If we store this GSI offset in the standalone media's intel_uncore structure, it can be automatically applied to all GSI reg reads/writes that happen on that GT, allowing us to re-use our existing GT code with minimal changes. Forcewake and shadowed register tables for the media GT (which will be added in a future patch) are listed as final addresses that already include the GSI offset, so we also need to add the GSI offset before doing lookups of registers in one of those tables. v2: - Add comment on raw_reg_*() macros explaining why we don't bother with GSI offsets in them. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
In preparation for enabling a second GT, there are a number of GT/uncore operations that happen during initialization or suspend flows that need to be performed on each GT, not just the primary, Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
In a multi-GT system we need to initialize MMIO access for each GT, not just the primary GT. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
As we start supporting multiple uncore structures in future patches, the MMIO cleanup (which may also get called mid-init if there's a failure) will become more complicated. Moving to DRM-managed actions will help keep things simple. Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-8-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
The common early GT init is needed for initialization of all GT types (root/primary, remote tile, standalone media). Since standalone media (coming in a future patch) will be implemented in a separate file, rename and expose the function for use. Signed-off-by:
-
Matt Roper authored
We're going to introduce an additional intel_gt for MTL's media unit soon. Let's provide a bit more multi-GT initialization framework in preparation for that. The initialization will pull the list of GTs for a platform from the device info structure. Although necessary for the immediate MTL media enabling, this same framework will also be used farther down the road when we enable remote tiles on xehpsdv and pvc. v2: - Re-add missing test for !HAS_EXTRA_GT_LIST in intel_gt_probe_all(). v3: - Move intel_gt_definition struct to intel_gt_types.h. (Jani) - Drop gtdef->setup(). For now we'll just use a switch() based on GT type since we don't have too many different handlers for the foreseeable future. (Jani) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Unmapping of the MMIO range can be done as a DRM-managed action, which will take care of the unmapping on device teardown and error paths. This will also ensure proper ordering with respect to other DRM-managed actions that we'll be using to clean up non-primary GTs in upcoming patches. We have not yet enabled any non-root GTs in the driver yet, so the kfree() of the GT structure is effectively dead code. When we do start enabling non-root GTs in upcoming patches, those are going to be using DRM-managed allocations tied to the device lifetime, so we don't need to explicitly free them (and kfree would be incorrect anyway). Signed-off-by:
-
Matt Roper authored
We're slowly transitioning the init-time kzalloc's of the driver over to DRM-managed allocations; let's make sure the uncore objects allocated for non-root GTs are thus allocated. Signed-off-by:
-
Matt Roper authored
The original intent of intel_uncore_mmio_debug as described in commit 0a9b2630 ("drm/i915: split out uncore_mmio_debug") was to be a singleton structure that could be shared between multiple GTs' uncore objects in a multi-tile system. Somehow we went off track and started allocating separate instances of this structure for each GT, which defeats that original goal. But in reality, there isn't even a need to share the mmio_debug between multiple GTs; on all modern platforms (i.e., everything after gen7) unclaimed register accesses are something that can only be detected for display registers. There's no point in grabbing the debug spinlock and checking for unclaimed accesses on an uncore used by an xehpsdv or pvc remote tile GT, or the uncore used by a mtl standalone media GT since all of the display accesses go through the primary intel_uncore. The simplest solution is to simply leave uncore->debug NULL on all intel_uncore instances except for the primary one. This will allow us to avoid the pointless debug spinlock acquisition we've been doing on MMIO accesses coming in through these intel_uncores. Signed-off-by:
-
Matt Roper authored
Moving the locking for MMIO debug (and the final check for unclaimed accesses when resuming debug after a userspace-initiated forcewake) will make it simpler to completely skip MMIO debug handling on uncores that don't support it in future patches. Signed-off-by:
-
Ashutosh Dixit authored
Perf limit reasons bit positions were off by one. Fixes: fa68bff7 ("drm/i915/gt: Add sysfs throttle frequency interfaces") Cc: stable@vger.kernel.org # v5.18+ Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by:
-
