- 12 Sep, 2022 24 commits
-
-
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 <matthew.d.roper@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-7-matthew.d.roper@intel.comSigned-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
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:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-6-matthew.d.roper@intel.comSigned-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:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-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:
-
- 31 Aug, 2022 1 commit
-
-
Rodrigo Vivi authored
Fix for intel_guc_slpc_set_min_freq() warn: inconsistent returns '&slpc->lock'. v2: Avoid with_intel_runtime_pm with the internal goto/return. (Ashutosh) Also standardize the 'ret' if this came from the efficient setup. And avoid the 'unlikely'. Fixes: 95ccf312 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Reported-by:kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
- 30 Aug, 2022 3 commits
-
-
Matt Roper authored
On client DG2 platforms, optimal performance is achieved with the hardware's default "age based" thread execution setting. However on ATS-M, switching this to "round robin after dependencies" provides better performance. We'll add a new "tuning" feature flag to the ATS-M device info to enable/disable this setting. Bspec: 68331 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220826212718.409948-1-matthew.d.roper@intel.com
-
Matt Roper authored
This reverts commit ca692081. The intent of Wa_14015141709 was to inform us that userspace can no longer control object-level preemption as it has on past platforms (i.e., by twiddling register bit CS_CHICKEN1[0]). The description of the workaround in the spec wasn't terribly well-written, and when we requested clarification from the hardware teams we were told that on the kernel side we should also probably stop setting FF_SLICE_CS_CHICKEN1[14], which is the register bit that directs the hardware to honor the settings in per-context register CS_CHICKEN1. It turns out that this guidance about FF_SLICE_CS_CHICKEN1[14] was a mistake; even though CS_CHICKEN1[0] is non-operational and useless to userspace, there are other bits in the register that do still work and might need to be adjusted by userspace in the future (e.g., to implement other workarounds that show up). If we don't set FF_SLICE_CS_CHICKEN1[14] in i915, then those future workarounds would not take effect. This miscommunication came to light because another workaround (Wa_16013994831) has now shown up that requires userspace to adjust the value of CS_CHICKEN[10] in certain circumstances. To ensure userspace's updates to this chicken bit are handled properly by the hardware, we need to make sure that FF_SLICE_CS_CHICKEN1[14] is once again set by the kernel. Signed-off-by:
-
Andrzej Hajda authored
In case of Small BAR configurations stolen local memory can be unmappable. Since the test does not touch the memory, passing I915_BO_ALLOC_GPU_ONLY flag to i915_gem_object_create_region, will prevent -ENOSPC error from _i915_gem_object_stolen_init. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6565Signed-off-by:
-
- 29 Aug, 2022 1 commit
-
-
Joonas Lahtinen authored
Remove the module parameters for configuring GuC log size. We should instead rely on tuning the defaults to be usable for reporting bugs. v2: - Use correct 1M unit Fixes: 8ad0152a ("drm/i915/guc: Make GuC log sizes runtime configurable") Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 26 Aug, 2022 1 commit
-
-
Matt Roper authored
Although register tuning settings are generally implemented via the workaround infrastructure, it turns out that the DRAW_WATERMARK register is not properly saved/restored by hardware around power events (i.e., RC6 entry) so updates to the value cannot be applied in the usual manner. New workaround Wa_16014892111 informs us that any tuning updates to this register must instead be applied via an INDIRECT_CTX batch buffer. This will ensure that the necessary value is re-applied when a context begins running, even if an RC6 entry had wiped the register back to hardware defaults since the last context ran. Fixes: 6dc85721 ("drm/i915/dg2: Add additional tuning settings") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6642Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220823202449.83727-1-matthew.d.roper@intel.com
-
- 25 Aug, 2022 2 commits
-
-
Juston Li authored
pxp will not start correctly until after mei_pxp bind completes and intel_pxp_init_hw() is called. Wait for the bind to complete before proceeding with startup. This fixes a race condition during bootup where we observed a small window for pxp commands to be sent, starting pxp before mei_pxp bind completed. Changes since v2: - wait for pxp_component to bind instead of returning -EAGAIN (Daniele) Changes since v1: - check pxp_component instead of pxp_component_added (Daniele) - pxp_component needs tee_mutex (Daniele) - return -EAGAIN so caller knows to retry (Daniele) Signed-off-by:
Juston Li <justonli@chromium.org> Reviewed-by:
-
Matt Roper authored
Unlike the Xe_HP platforms, MTL only has a single CCS engine; the quad-based engine masking logic does not apply to this platform (or presumably any future platforms that only have 0 or 1 CCS). Signed-off-by:
-
