- 12 Sep, 2022 32 commits
-
-
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:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-15-matthew.d.roper@intel.comSigned-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:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-5-matthew.d.roper@intel.comSigned-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:
Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by:
-
Lucas De Marchi authored
This reverts commit 487970e8. Updated bspec and workaround database note Wa_1409120013 is not needed for DG2 (or any Xe_LPD) platform. Simply check by display version 12. v2: Simplify condition check to display version (Matt Roper) Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
The worker is canceled in gt_park path, but earlier it was assumed that gt_park path cannot sleep and the cancel is asynchronous. This caused a race with suspend flow where the worker runs after suspend and causes an unclaimed register access warning. Cancel the worker synchronously since the gt_park is indeed allowed to sleep. v2: Fix author name and sign-off mismatch Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4419 Fixes: 77cdd054 ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220827002135.139349-1-umesh.nerlige.ramappa@intel.comSigned-off-by:
-
Tomas Winkler authored
GSC requires more operational memory than available on chip. Reserve 4M of LMEM for GSC operation. The memory is provided to the GSC as struct resource to the auxiliary data of the child device. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
-
Tomas Winkler authored
Add pxp mode devstate to debugfs to monitor pxp state machine progress. This is useful to debug issues in scenarios in which the pxp state needs to be re-initialized, like during power transitions such as suspend/resume. With this debugfs the state could be monitored to ensure that pxp is in the ready state. CC: Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexander Usyskin authored
The check that hardware and host ready bits are set after start is redundant and may fail and disable driver if there is back-to-back link reset issued right after start. This happens during pxp mode transitions when firmware undergo reset. Remove these checks to eliminate such failures. Signed-off-by:
-
Vitaly Lubart authored
Added transition to PXP mode in resume flow. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
-
Tomas Winkler authored
1. Retrieve extended operational memory physical pointers from the auxiliary device info. 2. Setup memory registers. 3. Notify firmware that the memory is ready by sending the memory ready command. 4. Disable PXP device if GSC is not in PXP mode. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Tomas Winkler authored
Add GSC memory ready command. The command indicates to the firmware that extend operation memory was setup and the firmware may enter PXP mode. CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Vitaly Lubart authored
Exported common mkhi definitions from bus-fixup.c into a separate header file mkhi.h for other driver usage. Signed-off-by:
-
Alexander Usyskin authored
Parametrize operational timeouts in order to support slow firmware on some graphics devices. Signed-off-by:
-
Alexander Usyskin authored
Wait for reset work to complete before initiating stop reset flow sequence. Signed-off-by:
-
Tomas Winkler authored
A work-around for a HW issue in XEHPSDV that manifests itself when SW reads a gsc register when gsc is sending an interrupt. The work-around is to disable interrupts and to use polling instead. Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Alexander Usyskin authored
Define GSC on XeHP SDV (Intel(R) dGPU without display) XeHP SDV uses the same hardware settings as DG1, but uses polling instead of interrupts and runs the firmware in slow pace due to hardware limitations. Signed-off-by:
-
Alexander Usyskin authored
Add slow_firmware flag to the gsc device definition and pass it to mei auxiliary device, this instructs the driver to use longer operation timeouts. Signed-off-by:
-
Tomas Winkler authored
Add slow_firmware flag to the mei auxiliary device info to inform the mei driver about slow underlying firmware. Such firmware will require to use larger operation timeouts. Signed-off-by:
-
Tomas Winkler authored
struct mei_aux_device is an interface structure requires proper documenation. Signed-off-by:
-
Vitaly Lubart authored
Some platforms require the host to poll on the GSC registers instead of relaying on the interrupts. For those platforms, irq initialization should be skipped Signed-off-by:
-
- 08 Sep, 2022 2 commits
-
-
Nirmoy Das authored
Fix regression introduced by commit: "drm/i915: Individualize fences before adding to dma_resv obj" which sets obj->read_domains to 0 for both read and write paths. Also set obj->write_domain to 0 on read path which was removed by the commit. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6639 Fixes: 420a07b8 ("drm/i915: Individualize fences before adding to dma_resv obj") Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Cc: <stable@vger.kernel.org> # v5.16+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907172641.12555-1-nirmoy.das@intel.com
-
Niranjana Vishwanathapura authored
So far, different views (normal, partial, rotated and remapped) into the same object are only supported for GGTT mappings. But with the upcoming VM_BIND feature, PPGTT will also use the partial view mapping. Hence rename ggtt_view to more generic gtt_view. Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Acked-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
- 07 Sep, 2022 2 commits
-
-
John Harrison authored
With the move to un-versioned filenames, it becomes more difficult to know exactly what version of a given firmware is being used. So add the patch level version number to the debugfs output. Also, support matching by patch level when selecting code paths for firmware compatibility. While a patch level change cannot be backwards breaking, it is potentially possible that a new feature only works from a given patch level onwards (even though it was theoretically added in an earlier version that bumped the major or minor version). Signed-off-by:
-
John Harrison authored
There was a misunderstanding in how firmware file compatibility should be managed within i915. This has been clarified as: i915 must support all existing firmware releases forever new minor firmware releases should replace prior versions only backwards compatibility breaking releases should be a new file This patch cleans up the single fallback file support that was added as a quick fix emergency effort. That is now removed in preference to supporting arbitrary numbers of firmware files per platform. The patch also adds support for having GuC firmware files that are named by major version only (because the major version indicates backwards breaking changes that affect the KMD) and for having HuC firmware files with no version number at all (because the KMD has no interface requirements with the HuC). For GuC, the driver will report via dmesg if the found file is older than expected. For HuC, the KMD will no longer require updating for any new HuC release so will not be able to report what the latest expected version is. Signed-off-by:
-
- 06 Sep, 2022 2 commits
-
-
Rodrigo Vivi authored
Specially in GT reset case this could be triggered and try to disable things that had never been enabled. Let's add some protection here. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Matthew Auld authored
Just move the HAS_FLAT_CCS() check into needs_ccs_pages. This also then fixes i915_ttm_memcpy_allowed() which was incorrectly reporting true on DG1, even though it doesn't have small-BAR or flat-CCS. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6605 Fixes: efeb3caf ("drm/i915/ttm: disallow CPU fallback mode for ccs pages") Signed-off-by:
-
- 05 Sep, 2022 1 commit
-
-
Nirmoy Das authored
On system suspend when system memory is low then i915_gem_obj_copy_ttm() could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough, suspend shouldn't continue if i915_ttm_backup() throws an error. v2: Keep the fdo issue till we have a igt test(Matt). v3: Use %pe(Andrzej) References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529Reviewed-by:
Chris P Wilson <chris.p.wilson@intel.com> Signed-off-by:
-
- 01 Sep, 2022 1 commit
-
-
Rodrigo Vivi authored
We need to inform PCODE of a desired ring frequencies so PCODE update the memory frequencies to us. rps->min_freq and rps->max_freq are the frequencies used in that request. However they were unset when SLPC was enabled and PCODE never updated the memory freq. v2 (as Suggested by Ashutosh): if SLPC is in use, let's pick the right frequencies from the get_ia_constants instead of the fake init of rps' min and max. v3: don't forget the max <= min return v4: Move all the freq conversion to intel_rps.c. And the max <= min check to where it belongs. v5: (Ashutosh) Fix old comment s/50 HZ/50 MHz and add a doc explaining the "raw format" Fixes: 7ba79a67 ("drm/i915/guc/slpc: Gate Host RPS when SLPC is enabled") Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Tested-by:Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by:
-
