- Jul 22, 2021
-
-
Faith Ekstrand authored
In the unlikely event that pci_register_device() fails, we were tearing down our PMU setup but not globals. This leaves a bunch of memory slabs lying around. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Fixes: 32eb6bcf ("drm/i915: Make request allocation caches global") [danvet: Fix conflicts against removal of the globals_flush infrastructure.] Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Faith Ekstrand authored
We should tear down in the opposite order we set up. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Daniel Vetter authored
This essentially reverts commit 84a10749 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jan 24 11:36:08 2018 +0000 drm/i915: Shrink the GEM kmem_caches upon idling mm/vmscan.c:do_shrink_slab() is a thing, if there's an issue with it then we need to fix that there, not hand-roll our own slab shrinking code in i915. Also when this was added there was only one other caller of kmem_cache_shrink (added 2005 to the acpi code). Now there's a 2nd one outside of i915 code in a kunit test, which seems legit since that wants to very carefully control what's in the kmem_cache. This out of a total of over 500 calls to kmem_cache_create. This alone should have been warning sign enough that we're doing something silly. Noticed while reviewing a patch set from Jason to fix up some issues in our i915_init() and i915_exit() module load/cleanup code. Now that i915_globals.c isn't any different than normal init/exit functions, we should convert them over to one unified table and remove i915_globals.[hc] entirely. v2: Improve commit message (Jason) Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721183229.4136488-1-daniel.vetter@ffwll.ch
-
- Jul 21, 2021
-
-
Matt Roper authored
Workarounds are documented in the bspec with an exclusive upper bound (i.e., a "fixed" stepping that no longer needs the workaround). This makes our driver's use of an inclusive upper bound for stepping ranges confusing; the differing notation between code and bspec makes it very easy for mistakes to creep in. Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over to use an exclusive upper bound like the bspec does. This also has the benefit of helping make sure workarounds are properly handled for new minor steppings that show up (e.g., an A1 between the A0 and B0 we already knew about) --- if the new intermediate stepping pulls in hardware fixes early, there will be an update to the workaround definition which lets us know we need to change our code. If the new stepping does not pull a hardware fix earlier, then the new stepping will already be captured properly by the "[begin, fix)" range in the code. We'll probably need to be extra vigilant in code review of new workarounds for the near future to make sure developers notice the new semantics of workaround bounds. But we just migrated a bunch of our platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so people are already adjusting to the new macros and now is a good time to make this change too. [mattrope: Split out GT changes to apply through gt-next tree] Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-8-matthew.d.roper@intel.com
-
Matt Roper authored
DFR programming (which we enable as an optimization on gen11, but must ensure is disabled on gen12) should be handled as a GT workaround rather than clock gating initialization. This will ensure that the programming of these registers is verified with our typical workaround checks. Signed-off-by:
-
Matt Roper authored
While doing a quick sanity check of the ICL workarounds in the driver I noticed a few things that should be updated: * There's no mention in the bspec that WaPipelineFlushCoherentLines is needed on gen11 (both the current WA database and the old, deprecated page 20196 were checked); it appears this might have just been copied from the gen9 list? Even if this were needed, it doesn't seem like this was the correct implementation anyway since the gen9 workaround is supposed to be implemented in the indirect context bb (as we do in gen8_emit_flush_coherentl3_wa() on gen8/gen9). * WaForwardProgressSoftReset does not appear in the current workaround database. The old deprecated workaround list has a note indicating the workaround was dropped in 2017, so we should be safe to drop it from the code too. While we're at it, add the formal workaround ID number to WaDisableBankHangMode (our hardware team made a transition from text-based workaround names to ID numbers partway through the development of ICL, which is why some workarounds only have names, some only have numbers, and some have both). Bspec: 33450 Signed-off-by:
-
Matt Roper authored
On SKL we've been applying this workaround on H0+ steppings, which is actually backwards; H0 is supposed to be the first stepping where the workaround is no longer needed. Flip the bounds so that the workaround applies to all steppings _before_ H0. On BXT we've been applying this workaround to all steppings, but the bspec tells us it's only needed until C0. Pre-C0 GT steppings only appeared in pre-production hardware, which we no longer support in the driver, so we can drop the workaround completely for this platform. On ICL we've been applying this workaround to all steppings, but there doesn't seem to be any indication that this workaround was ever needed for this platform (even now-deprecated page 20196 of the bspec doesn't mention it). We can go ahead and drop it. I also don't see any mention of this workaround being needed for KBL, although this may be an oversight since the workaround is needed for all steppings of CFL. I'll leave the workaround in place for KBL to be safe. Bspec: 14091, 33450 Signed-off-by:
-
Maarten Lankhorst authored
The FIXED mapping is only used for ttm, and tells userspace that the mapping type is pre-defined. This disables the other type of mmap offsets when discrete memory is used, so fix the selftests as well. Document the struct as well, so it shows up in docbook. Cc: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mauld: Included minor fixes from the review comments] Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714122833.766586-1-maarten.lankhorst@linux.intel.com
-
Faith Ekstrand authored
In 93b71330 ("drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser""), the parameters to intel_engine_cmd_parser() were altered without updating the docs, causing Fi.CI.DOCS to start failing. Fixes: 93b71330 ("drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"") Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720182108.2761496-1-jason@jlekstrand.net Signed-off-by:
-
- Jul 20, 2021
-
-
Matthew Auld authored
Add the missing kernel-doc. Signed-off-by:
-
Matthew Auld authored
It's a noop on DG1, and in the future when need to support other devices which let us control the coherency, then it should be an immutable creation time property for the BO. This will likely be controlled through a new gem_create_ext extension. v2: add some kernel doc for the discrete changes, and document the implicit rules Suggested-by:Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210715101536.2606307-2-matthew.auld@intel.com
-
- Jul 16, 2021
-
-
Faith Ekstrand authored
This reverts a6c5e2ae ("drm/i915: Skip over MI_NOOP when parsing"). It complicates the batch parsing code a bit and increases indentation for no reason other than fast-skipping a command that userspace uses only rarely. Sure, there may be IGT tests that fill batches with NOOPs but that's not a case we should optimize for in the kernel. We should optimize for code clarity instead. Signed-off-by:
Jon Bloomfield <jon.bloomfield@intel.com> Acked-by:
-
Faith Ekstrand authored
Asynchronous command parsing was the only thing which ever returned a non-zero error. With that gone, we can drop the error handling from dma_fence_work. Signed-off-by:
-
Faith Ekstrand authored
This reverts the rest of 0edbb9ba ("drm/i915: Move cmd parser pinning to execbuffer"). Now that the only user of i915_gem_object_get_sg without allow_alloc has been removed, we can drop the parameter. This portion of the revert was broken into its own patch to aid review. Signed-off-by:
-
Faith Ekstrand authored
This reverts commit 9e31c1fe. Ever since that commit, we've been having issues where a hang in one client can propagate to another. In particular, a hang in an app can propagate to the X server which causes the whole desktop to lock up. Error propagation along fences sound like a good idea, but as your bug shows, surprising consequences, since propagating errors across security boundaries is not a good thing. What we do have is track the hangs on the ctx, and report information to userspace using RESET_STATS. That's how arb_robustness works. Also, if my understanding is still correct, the EIO from execbuf is when your context is banned (because not recoverable or too many hangs). And in all these cases it's up to userspace to figure out what is all impacted and should be reported to the application, that's not on the kernel to guess and automatically propagate. What's more, we're also building more features on top of ctx error reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the userspace fence wait also relies on that mechanism. So it is the path going forward for reporting gpu hangs and resets to userspace. So all together that's why I think we should just bury this idea again as not quite the direction we want to go to, hence why I think the revert is the right option here. For backporters: Please note that you _must_ have a backport of https://lore.kernel.org/dri-devel/20210602164149.391653-2-jason@jlekstrand.net/ for otherwise backporting just this patch opens up a security bug. v2: Augment commit message. Also restore Jason's sob that I accidentally lost. v3: Add a note for backporters Signed-off-by:
Marcin Slusarz <marcin.slusarz@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Cc: Jason Ekstrand <jason.ekstrand@intel.com> Cc: Marcin Slusarz <marcin.slusarz@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080 Fixes: 9e31c1fe ("drm/i915: Propagate errors on awaiting already signaled fences") Acked-by:
-
Faith Ekstrand authored
This reverts 686c7c35 ("drm/i915/gem: Asynchronous cmdparser"). The justification for this commit in the git history was a vague comment about getting it out from under the struct_mutex. While this may improve perf for some workloads on Gen7 platforms where we rely on the command parser for features such as indirect rendering, no numbers were provided to prove such an improvement. It claims to closed two gitlab/bugzilla issues but with no explanation whatsoever as to why or what bug it's fixing. Meanwhile, by moving command parsing off to an async callback, it leaves us with a problem of what to do on error. When things were synchronous, EXECBUFFER2 would fail with an error code if parsing failed. When moving it to async, we needed another way to handle that error and the solution employed was to set an error on the dma_fence and then trust that said error gets propagated to the client eventually. Moving back to synchronous will help us untangle the fence error propagation mess. This also reverts most of 0edbb9ba ("drm/i915: Move cmd parser pinning to execbuffer") which is a refactor of some of our allocation paths for asynchronous parsing. Now that everything is synchronous, we don't need it. v2 (Daniel Vetter): - Add stabel Cc and Fixes tag Signed-off-by:
-
Maarten Lankhorst authored
I noticed when grepping for DOC: that those were defined in the header, but not actually used. Fix it by removing all chapters and the internal annotation, so the docbook generated chapters are used. This reverts the changes to driver-uapi.rst by the referenced commit 57772953 ("drm/i915: Document the Virtual Engine uAPI") Signed-off-by:
-
- Jul 15, 2021
-
-
Matt Roper authored
The switch from old old IS_FOO_REVID() macros to the new table-based IS_FOO_{GT,DISP}_STEP() macros is needed on both drm-intel-next (for display-based DMC matching) and drm-intel-gt-next (for workaround guards). To avoid conflicts, we'll apply the patches to a topic branch and merge it to both intel branches to ensure the transition to the new macros is clean. Signed-off-by: -
Matt Roper authored
We're past the point at which we usually drop workarounds that were never needed on production hardware. The driver will already print an error and apply taint if loaded on pre-production hardware. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-13-matthew.d.roper@intel.com
-
Matt Roper authored
All of the Cannon Lake hardware that came out had graphics fused off, and our userspace drivers have already dropped their support for the platform; CNL-specific code in i915 that isn't inherited by subsequent platforms is effectively dead code. Let's remove all of the CNL-specific workarounds as a quick and easy first step. References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6899 Signed-off-by:
-
Matt Roper authored
Switch DG1 to use a revid->stepping table as we're trying to do on all platforms going forward. This removes the last use of IS_REVID() and REVID_FOREVER, so remove those now-unused macros as well to prevent their accidental use on future platforms. v2: - Use COMMON_STEP() macro in table. (Anusha) Bspec: 44463 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Switch RKL to use a revid->stepping table as we're trying to do on all platforms going forward. Bspec: 44501 Signed-off-by:
-
Matt Roper authored
Switch JSL/EHL to use a revid->stepping table as we're trying to do on all platforms going forward. v2: - Use COMMON_STEP(). (Anusha) Bspec: 29153 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Switch ICL to use a revid->stepping table as we're trying to do on all platforms going forward. While we're at it, let's include some additional steppings that have popped up, even if we don't yet have any workarounds tied to those steppings (we probably need to audit our workaround list soon to see if any of the bounds have moved or if new workarounds have appeared). Note that the current bspec table is missing information about how to map PCI revision ID to GT/display steppings; it only provides an SoC stepping. The mapping to GT/display steppings (which aren't always the same as the SoC stepping) used to be in the bspec, but was apparently dropped during an update in Nov 2019; I've made my changes here based on an older bspec snapshot that still had the necessary information. We've requested that the missing information be restored. I'm only including the production revids in the table here since we're past the point at which we usually stop trying to support pre-production hardware. An appropriate check is added to intel_detect_preproduction_hw() to print an error and taint the kernel just in case someone still tries to load the driver on old pre-production hardware. v2: - Drop pre-production steppings and add error/taint at startup when loading on pre-production hardware. Bspec: 21141 # pre-Nov 2019 snapshot Signed-off-by:
-
Matt Roper authored
Switch GLK to use a revid->stepping table as we're trying to do on all platforms going forward. Pre-production and placeholder revisions are omitted. Although nothing in the code is using the data from this table at the moment, we expect some upcoming DMC patches to start utilizing it. Bspec: 19131 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Switch BXT to use a revid->stepping table as we're trying to do on all platforms going forward. Note that the REVID macros we had before weren't being used anywhere in the code and weren't even correct; the table values come from the bspec (and omits all the placeholder and preproduction revisions). Although nothing in the code is using the data from this table at the moment, we expect some upcoming DMC patches to start utilizing it. Bspec: 13620 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
We're long past the point where we need to care about pre-production hardware, and we already warn the user and taint the kernel if we detect the driver is being loaded on pre-production hardware. Bspec: 18329 Signed-off-by:
-
Matt Roper authored
Switch SKL to use a revid->stepping table as we're trying to do on all platforms going forward. Also drop the preproduction revisions and add the newer steppings we hadn't already handled. Note that SKL has a case where a newer revision ID corresponds to an older GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1). Also, the lack of a revision ID 0x8 in the table is intentional and not an oversight. We'll re-write the KBL-specific comment to make it clear that these kind of quirks are expected. v2: - Since GT and display steppings are always identical on SKL use a macro to set both values at once in a more readable manner. (Anusha) - Drop preproduction steppings. Bspec: 13626 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
Although we're converting our workarounds to use a revid->stepping lookup table, the function that detects pre-production hardware should continue to compare against PCI revision ID values directly. These are listed in the bspec as integers, so it's easier to confirm their correctness if we just use an integer literal rather than a symbolic name anyway. Bspec: 13620, 19131, 13626, 18329 Signed-off-by:
-
Anusha Srivatsa authored
Simplify the stepping info array name. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.roper@intel.com
-
- Jul 14, 2021
-
-
Matthew Auld authored
We skip filling out the pt with scratch entries if the va range covers the entire pt, since we later have to fill it with the PTEs for the object pages anyway. However this might leave open a small window where the PTEs don't point to anything valid for the HW to consume. When for example using 2M GTT pages this fill_px() showed up as being quite significant in perf measurements, and ends up being completely wasted since we ignore the pt and just use the pde directly. Anyway, currently we have our PTE construction split between alloc and insert, which is probably slightly iffy nowadays, since the alloc doesn't actually allocate anything anymore, instead it just sets up the page directories and points the PTEs at the scratch page. Later when we do the insert step we re-program the PTEs again. Better might be to squash the alloc and insert into a single step, then bringing back this optimisation(along with some others) should be possible. Fixes: 14826673 ("drm/i915: Only initialize partially filled pagetables") Signed-off-by:
-
Matthew Auld authored
Convert all the drm_i915_gem_set_domain bits to proper kernel doc. Suggested-by:
-
Matthew Auld authored
Convert all the drm_i915_gem_caching bits to proper kernel doc. Suggested-by:
-
- Jul 13, 2021
-
-
John Harrison authored
Add several module failure load inject points in the CT buffer creation code path. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Matthew Brost authored
CTB writes are now in the path of command submission and should be optimized for performance. Rather than reading CTB descriptor values (e.g. head, tail) which could result in accesses across the PCIe bus, store shadow local copies and only read/write the descriptor values when absolutely necessary. Also store the current space in the each channel locally. v2: (Michal) - Add additional sanity checks for head / tail pointers - Use GUC_CTB_HDR_LEN rather than magic 1 v3: (Michal / John H) - Drop redundant check of head value v4: (John H) - Drop redundant checks of tail / head values v5: (Michal) - Address more nits v6: (Michal) - Add GEM_BUG_ON sanity check on ctb->space Signed-off-by:
-
Matthew Brost authored
Implement a stall timer which fails H2G CTBs once a period of time with no forward progress is reached to prevent deadlock. v2: (Michal) - Improve error message in ct_deadlock() - Set broken when ct_deadlock() returns true - Return -EPIPE on ct_deadlock() v3: (Michal) - Add ms to stall timer comment (Matthew) - Move broken check to intel_guc_ct_send() Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matthew Brost authored
Add non blocking CTB send function, intel_guc_send_nb. GuC submission will send CTBs in the critical path and does not need to wait for these CTBs to complete before moving on, hence the need for this new function. The non-blocking CTB now must have a flow control mechanism to ensure the buffer isn't overrun. A lazy spin wait is used as we believe the flow control condition should be rare with a properly sized buffer. The function, intel_guc_send_nb, is exported in this patch but unused. Several patches later in the series make use of this function. v2: (Michal) - Use define for H2G room calculations - Move INTEL_GUC_SEND_NB define (Daniel Vetter) - Use msleep_interruptible rather than cond_resched v3: (Michal) - Move includes to following patch - s/INTEL_GUC_SEND_NB/INTEL_GUC_CT_SEND_NB/g v4: (John H) - Update comment, add type local variable Signed-off-by:
-
Matthew Brost authored
With the introduction of non-blocking CTBs more than one CTB can be in flight at a time. Increasing the size of the CTBs should reduce how often software hits the case where no space is available in the CTB buffer. Cc: John Harrison <john.c.harrison@intel.com> Signed-off-by:
-
Matthew Brost authored
Improve the error message when a unsolicited CT response is received by printing fence that couldn't be found, the last fence, and all requests with a response outstanding. Signed-off-by:
-
Matthew Brost authored
In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for processing, so we shouldn't assume any more that GuC will always reply without 10ms. Use bigger value hardcoded value of 1s instead. v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option v3: (Daniel Vetter) - Use hardcoded value of 1s rather than config option v4: (Michal) - Use defines for timeout values Signed-off-by:
-
