- 21 Jun, 2022 1 commit
-
-
Vinay Belgaumkar authored
We have seen multiple RC6 issues where it is useful to know which global forcewake bits are set. Add this to the 'drpc' debugfs output. v2: Review comments (Ashutosh) Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617212032.34577-1-vinay.belgaumkar@intel.com
-
- 20 Jun, 2022 1 commit
-
-
Thomas Hellström authored
When DMAR / VT-d is enabled, the display engine uses overfetching, presumably to deal with the increased latency. To avoid display engine errors and DMAR faults, as a workaround the GGTT is populated with scatch PTEs when VT-d is enabled. However starting with gen10, Write-combined writing of scratch PTES is no longer possible and as a result, populating the full GGTT with scratch PTEs like on resume becomes very slow as uncached access is needed. Therefore, on integrated GPUs utilize the fact that the PTEs are stored in stolen memory which retain content across S3 suspend. Don't clear the PTEs on suspend and resume. This improves on resume time with around 100 ms. While 100+ms might appear like a short time it's 10% to 20% of total resume time and important in some applications. One notable exception is Intel Rapid Start Technology which may cause stolen memory to be lost across what the OS percieves as S3 suspend. If IRST is enabled or if we can't detect whether IRST is enabled, retain the old workaround, clearing and re-instating PTEs. As an additional measure, if we detect that the last ggtt pte was lost during suspend, print a warning and re-populate the GGTT ptes On discrete GPUs, the display engine scans out from LMEM which isn't subject to DMAR, and presumably the workaround is therefore not needed, but that needs to be verified and disabling the workaround for dGPU, if possible, will be deferred to a follow-up patch. v2: - Rely on retained ptes to also speed up suspend and resume re-binding. - Re-build GGTT ptes if Intel rst is enabled. v3: - Re-build GGTT ptes also if we can't detect whether Intel rst is enabled, and if the guard page PTE and end of GGTT was lost. v4: - Fix some kerneldoc issues (Matthew Auld), rebase. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617152856.249295-1-thomas.hellstrom@linux.intel.com
-
- 17 Jun, 2022 4 commits
-
-
Matt Roper authored
Let's replace the assortment of intel_gt_* and intel_uncore_* functions that operate on MCR registers with a cleaner set of interfaces: * intel_gt_mcr_read -- unicast read from specific instance * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated instance * intel_gt_mcr_unicast_write -- unicast write to specific instance * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances We'll also replace the historic "slice" and "subslice" terminology with "group" and "instance" to match the documentation for more recent platforms; these days MCR steering applies to more types of replication than just slice/subslice. v2: - Reference the new kerneldoc from i915.rst. (Jani) - Tweak the wording of the documentation for a couple functions to clarify the difference between "_fw" and non-"_fw" forms. v3: - s/read/write/ to fix copy-paste mistake in a couple comments. (Harish) Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Harish Chegondi <harish.chegondi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220615001019.1821989-3-matthew.d.roper@intel.com
-
Matt Roper authored
Handling of multicast/replicated registers is spread across intel_gt.c and intel_uncore.c today. As multicast handling and the related steering logic gets more complicated with the addition of new platforms and new rules it makes sense to centralize it all in one place. For now the existing functions have been moved to the new .c/.h as-is. Function renames and updates to operate in a more consistent manner will be done in subsequent patches. Signed-off-by:
-
Tvrtko Ursulin authored
Stop displaying engine classes with no engines - it is not a huge problem if they are shown, since the values will correctly be all zeroes, but it does count as misleading. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 055634e4 ("drm/i915: Expose client engine utilisation via fdinfo") Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220616140056.559074-1-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
We have long standing customer complaints that pressing Ctrl-C (or to the effect of) causes engine resets with otherwise well behaving programs. Not only is logging engine resets during normal operation not desirable since it creates support incidents, but more fundamentally we should avoid going the engine reset path when we can since any engine reset introduces a chance of harming an innocent context. Reason for this undesirable behaviour is that the driver currently does not distinguish between banned contexts and non-persistent contexts which have been closed. To fix this we add the distinction between the two reasons for revoking contexts, which then allows the strict timeout only be applied to banned, while innocent contexts (well behaving) can preempt cleanly and exit without triggering the engine reset path. Note that the added context exiting category applies both to closed non- persistent context, and any exiting context when hangcheck has been disabled by the user. At the same time we rename the backend operation from 'ban' to 'revoke' which more accurately describes the actual semantics. (There is no ban at the backend level since banning is a concept driven by the scheduling frontend. Backends are simply able to revoke a running context so that is the more appropriate name chosen.) Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220527072452.2225610-1-tvrtko.ursulin@linux.intel.com
-
- 15 Jun, 2022 1 commit
-
-
Matt Roper authored
As with past platforms, the bspec's performance tuning guide provides recommended MMIO settings. Although not technically "workarounds" we apply these through the workaround framework to ensure that they're re-applied at the proper times (e.g., on engine resets) and that any conflicts with real workarounds are flagged. Bspec: 72161 Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613165314.862029-1-matthew.d.roper@intel.com
-
- 14 Jun, 2022 1 commit
-
-
Matt Roper authored
If we're treating each bit in the EU fuse register as a single EU instead of a pair of EUs, then that also cuts the number of potential EUs per subslice in half. Fixes: 5ac342ef ("drm/i915/pvc: Add SSEU changes") Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220610230801.459577-1-matthew.d.roper@intel.com
-
- 09 Jun, 2022 1 commit
-
-
Matt Roper authored
Ponte Vecchio no longer has MSLICE or LNCF steering, but the bspec does document several new types of multicast register ranges. Fortunately, most of the different MCR types all provide valid values at instance (0,0) so there's no need to read fuse registers and calculate a non-terminated instance. We'll lump all of those range types (BSLICE, HALFBSLICE, TILEPSMI, CC, and L3BANK) into a single category called "INSTANCE0" to keep things simple. We'll also perform explicit steering for each of these multicast register types, even if the implicit steering setup for COMPUTE/DSS ranges would have worked too; this is based on guidance from our hardware architects who suggested that we move away from implicit steering and start explicitly steer all MCR register accesses on modern platforms (we'll work on transitioning COMPUTE/DSS to explicit steering in the future). Note that there's one additional MCR range type defined in the bspec (SQIDI) that we don't handle here. Those ranges use a different steering control register that we never touch; since instance 0 is also always a valid setting there, we can just ignore those ranges. Finally, we'll rename the HAS_MSLICES() macro to HAS_MSLICE_STEERING(). PVC hardware still has units referred to as mslices, but there's no register steering based on mslice for this platform. v2: - Rebase on other recent changes - Swap two table rows to keep table sorted & easy to read. (Harish) Bspec: 67609 Signed-off-by:
-
- 08 Jun, 2022 4 commits
-
-
Matt Roper authored
Another mistake during the conversion to DSS bitmaps: after retrieving the DSS ID intel_sseu_find_first_xehp_dss() we forgot to modulo it down to obtain which ID within the current gslice it is. Fixes: b87d3901 ("drm/i915/sseu: Disassociate internal subslice mask representation from uapi") Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607175716.3338661-1-matthew.d.roper@intel.com
-
Matt Roper authored
A new PVC+DG2 workaround has appeared recently: - Wa_16015675438 And a couple existing DG2 workarounds have been extended to PVC: - Wa_14015795083 - Wa_18018781329 Note that Wa_16015675438 asks us to program a register that is in the 0x2xxx range typically associated with the RCS engine, even though PVC does not have an RCS. By default the GuC will think we've made a mistake and throw an exception when it sees this register on a CCS engine's save/restore list, so we need to pass an extra GuC control flag to tell it that this is expected and not a problem. Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
-
Jani Nikula authored
The arrays are static const, but the pointer shouldn't be static. Fixes: 3d832f37 ("drm/i915/uc: Allow platforms to have GuC but not HuC") Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Matt Roper authored
When converting our DSS masks to bitmaps, we fumbled the condition used to check whether any DSS are present in the first gslice. Since intel_sseu_find_first_xehp_dss() returns a 0-based number, we need a >= condition rather than >. Fixes: b87d3901 ("drm/i915/sseu: Disassociate internal subslice mask representation from uapi") Reported-by:
-
- 07 Jun, 2022 2 commits
-
-
Anshuman Gupta authored
i915 must disable Render DOP clock gating globally. v2: - Addressed cosmetic review comments. Bspec: 52621 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
-
Jani Nikula authored
Only the uapi header is required. Signed-off-by:
-
- 03 Jun, 2022 1 commit
-
-
Matt Roper authored
We missed this setting in the initial device info patch's definition of XE_HPC_FEATURES. Signed-off-by:
-
- 02 Jun, 2022 7 commits
-
-
Stuart Summers authored
Our internal teams have identified a few additional engine registers that are worth inspecting in error state dumps during development & debug. Let's capture and print them as part of our error dump. For simplicity we'll just dump these registers on gen11 and beyond. Most of these registers have existed since earlier platforms (e.g., gen6 or gen7) but were initially introduced only for a subset of the platforms' engines; gen11 seems to be where they became available on all engines. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
Matt Roper authored
PVC splits the mask of enabled DSS over two registers. It also changes the meaning of the EU fuse register such that each bit represents a single EU rather than a pair of EUs. Signed-off-by:
-
Matt Roper authored
As with EU masks, it's easier to store subslice/DSS masks internally in a format that's more natural for the driver to work with, and then only covert into the u8[] uapi form when the query ioctl is invoked. Since the hardware design changed significantly with Xe_HP, we'll use a union to choose between the old "hsw-style" subslice masks or the newer xehp mask. HSW-style masks will be stored in an array of u8's, indexed by slice (there's never more than 6 subslices per slice on older platforms). For Xe_HP and beyond where slices no longer exist, we only need a single bitmask. However we already know that this mask is eventually going to grow too large for a simple u64 to hold, so we'll represent it in a manner that can be operated on by the utilities in linux/bitmap.h. v2: - Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status() v3: - Eliminate sseu->ss_stride and just calculate the stride while specifically handling uapi. (Tvrtko) - Use BITMAP_BITS() macro to refer to size of masks rather than passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko) - Report compute/geometry DSS masks separately when dumping Xe_HP SSEU info. (Tvrtko) - Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko) v4: - Make the bitmap size macro check the size of the .xehp field rather than the containing union. (Tvrtko) - Don't add GEM_BUG_ON() intel_sseu_has_subslice()'s check for whether slice or subslice ID exceed sseu->max_[sub]slices; various loops in the driver are expected to exceed these, so we should just silently return 'false.' v5: - Move XEHP_BITMAP_BITS() to the header so that we can also replace a usage of I915_MAX_SS_FUSE_BITS in one of the inline functions. (Bala) - Change the local variable in intel_slicemask_from_xehp_dssmask() from u16 to 'unsigned long' to make it a bit more future-proof. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Matt Roper authored
Storing the EU mask internally in the same format the I915_QUERY topology queries use makes the final copy_to_user() a bit simpler, but makes the rest of the driver's SSEU more complicated and harder to follow. Let's switch to an internal representation that's more natural: Xe_HP platforms will be a simple array of u16 masks, whereas pre-Xe_HP platforms will be a two-dimensional array, indexed by [slice][subslice]. We'll convert to the uapi format only when the query uapi is called. v2: - Drop has_common_ss_eumask. We waste some space repeating identical EU masks for every single DSS, but the code is simpler without it. (Tvrtko) v3: - Mask down EUs passed to sseu_set_eus at the callsite rather than inside the function. (Tvrtko) - Eliminate sseu->eu_stride and calculate it when needed. (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Although gen11 and gen12 architectures supported the concept of multiple slices, in practice all the platforms that were actually designed only had a single slice (i.e., note the parameters to 'intel_sseu_set_info' that we pass for each platform). We can simplify the code slightly by dropping the multi-slice logic from gen11+ platforms. v2: - Promote drm_dbg to drm_WARN_ON if the slice fuse register reports unexpected fusing. (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support traditional slices (and we make no attempt to return the various new units like gslices, cslices, mslices, etc.) here. The subslice mask lookup is even more problematic; given the distinct masks for geometry vs compute purposes, the combined mask returned here is likely not what userspace would want to act upon anyway. The value is also limited to 32-bits by the nature of the GETPARAM ioctl which is sufficient for the initial Xe_HP platforms, but is unable to convey the larger masks that will be needed on other upcoming platforms. Finally, the value returned here becomes even less meaningful when used on multi-tile platforms where each tile will have its own masks. Signed-off-by:
-
Matt Roper authored
Xe_HP has enough fundamental differences from previous platforms that it makes sense to use a separate SSEU init function to keep things straightforward and easy to understand. We'll also add a has_xehp_dss flag to the SSEU structure that will be used by other upcoming changes. v2: - Add has_xehp_dss flag Signed-off-by:
-
- 31 May, 2022 2 commits
-
-
Stuart Summers authored
Bspec: 64027 Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220527163348.1936146-3-matthew.d.roper@intel.com
-
Matt Roper authored
For PVC, the base die and compute tile have separate stepping values that we need to track; we'll use the existing graphics_step field to represent the compute tile stepping and add a new 'basedie_step' field. Unlike past platforms, steppings for these components are represented by specific bitfields within the PCI revision ID, and we shouldn't make assumptions about the non-CT, non-BD bits staying 0. Let's update our stepping code accordingly. Bspec: 44484 Signed-off-by:
-
- 27 May, 2022 1 commit
-
-
Nirmoy Das authored
_i915_vma_move_to_active() can receive > 1 fences for multiple batch buffers submission. Because dma_resv_add_fence() can only accept one fence at a time, change _i915_vma_move_to_active() to be aware of multiple fences so that it can add individual fences to the dma resv object. v6: fix multi-line comment. v5: remove double fence reservation for batch VMAs. v4: Reserve fences for composite_fence on multi-batch contexts and also reserve fence slots to composite_fence for each VMAs. v3: dma_resv_reserve_fences is not cumulative so pass num_fences. v2: make sure to reserve enough fence slots before adding. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614 Fixes: 544460c3 ("drm/i915: Multi-BB execbuf") Cc: <stable@vger.kernel.org> # v5.16+ Signed-off-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
- 26 May, 2022 5 commits
-
-
Ashutosh Dixit authored
All kmalloc'd kobjects need a kobject_put() to free memory. For example in previous code, kobj_gt_release() never gets called. The requirement of kobject_put() now results in a slightly different code organization. v2: s/gtn/gt/ (Andi) Fixes: b770bcfa ("drm/i915/gt: create per-tile sysfs interface") Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Acked-by:
-
Dale B Stimson authored
Retrieve RP0 and RPn freq for media IP from PCODE and display in per-gt sysfs. This patch adds the following files to gt/gtN sysfs: * media_RP0_freq_mhz * media_RPn_freq_mhz v2: Fixed commit author (Rodrigo) v3: Convert to new uncore interface for pcode functions v4: Adapt to intel_pcode.* function rename v5: #include "intel_pcode.h" in alphabetical order (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Dale B Stimson <dale.b.stimson@intel.com> Signed-off-by:
-
Ashutosh Dixit authored
Extend pcode initialization to pcode on different gt's. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ashutosh Dixit authored
Expose new sysfs to program and retrieve media freq factor. Factor values of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point representation (corresponding to integer values of 0, 128 and 256 respectively). Media freq factor is converted to media_ratio_mode for GuC. It is programmed into GuC using H2G SLPC interface. It is retrieved from GuC through a register read. A cached media_ratio_mode is maintained to preserve set values across GuC resets. This patch adds the following sysfs files to gt/gtN sysfs: * media_freq_factor * media_freq_factor.scale v2: Minor wording change in drm_warn (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Alan Previn authored
Fix our pointer offset usage in error_state_read when there is no i915_gpu_coredump but buf offset is non-zero. This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 error_state dump while the other is forcing full GT resets. (takes a while to trigger). The dmesg call trace: [ 5590.803000] BUG: unable to handle page fault for address: ffffffffa0b0e000 [ 5590.803009] #PF: supervisor read access in kernel mode [ 5590.803013] #PF: error_code(0x0000) - not-present page [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067 PTE 0 [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136 [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00. 3031.A02.2201171222 01/17/2022 [ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10 [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282 [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00 RCX: 0000000000000f8f [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000 RDI: ffff888107ee9071 [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000019 [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000 R15: ffff888107ee9000 [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000) knlGS:0000000000000000 [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004 CR4: 0000000000770ee0 [ 5590.803089] PKRU: 55555554 [ 5590.803091] Call Trace: [ 5590.803093] <TASK> [ 5590.803096] error_state_read+0xa1/0xd0 [i915] [ 5590.803175] kernfs_fop_read_iter+0xb2/0x1b0 [ 5590.803180] new_sync_read+0x116/0x1a0 [ 5590.803185] vfs_read+0x114/0x1b0 [ 5590.803189] ksys_read+0x63/0xe0 [ 5590.803193] do_syscall_64+0x38/0xc0 [ 5590.803197] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 5590.803201] RIP: 0033:0x7f62aaea5912 [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000 RCX: 00007f62aaea5912 [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f RDI: 0000000000000006 [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010 R09: 0000000000101000 [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000006 [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010 R15: 0000000000200000 [ 5590.803238] </TASK> [ 5590.803240] Modules linked in: i915 ttm drm_buddy drm_dp_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers nfnetlink br_netfilter overlay mei_pxp mei_hdcp x86_pkg_temp_thermal coretemp kvm_intel snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm mei_me mei fuse ip_tables x_tables crct10dif_pclmul e1000e crc32_pclmul ptp i2c_i801 ghash_clmulni_intel i2c_smbus pps_core [last unloa ded: ttm] [ 5590.803277] CR2: ffffffffa0b0e000 [ 5590.803280] ---[ end trace 0000000000000000 ]--- Fixes: 0e39037b ("drm/i915: Cache the error string") Signed-off-by:Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
-
- 25 May, 2022 1 commit
-
-
Matt Roper authored
PVC also has a hwconfig table. Actually the current expectation is that all future platforms will have hwconfig, so let's just change the condition to an IP version check so that we don't need to keep updating this for each new platform that shows up. Cc: John Harrison <john.c.harrison@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
- 24 May, 2022 7 commits
-
-
Balasubramani Vivekanandan authored
ADL-N being a subplatform of ADL-P, it lacks support for hwconfig table. Explicit check added to skip ADL-N. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Disable HuC loading since it is not used on these platforms. Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
Initialize ADS system info to reflect the availability of new BCS engines Original-author: CQ Tang Cc: Stuart Summers <stuart.summers@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Stuart Summers authored
Although we already strip 3D-specific flags from PIPE_CONTROL instructions when submitting to a compute engine, there are some additional flags that need to be removed when the platform as a whole lacks a 3D pipeline. Add those restrictions here. v2: - Replace LACKS_3D_PIPELINE checks with !HAS_3D_PIPELINE and add has_3d_pipeline to all platforms except PVC. (Lucas) Bspec: 47112 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
Add PVC's forcewake ranges. v2: - Drop replicated comment completely; move general cleanup of the documentation to a separate patch. Bspec: 67609 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
Matt Roper authored
Let's reorganize some of the forcewake/shadow handling in intel_uncore.c and consolidate the cargo-cult comments on each table into more general comments that apply to all tables. We'll probably move forcewake handling to its own dedicated file in the near future and further enhance this with true kerneldoc. But this is a good intermediate step to help clarify the behavior a bit. Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
Bommu Krishnaiah authored
Update the selftest to include Tile 4 mode and switch to Tile 4 on platforms that supports Tile 4 but no Tile Y and vice versa. Also switch to XY_FAST_COPY_BLT on platforms that supports it. v4: update commit message to reflect the code changes properly. v3: add a function to find X-tile availability for a platform. v2: disable Tile X for iGPU in fastblit and fix checkpath --strict warnings. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5879Signed-off-by:Bommu Krishnaiah <krishnaiah.bommu@intel.com> Co-developed-by:
Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Signed-off-by:
-
- 23 May, 2022 1 commit
-
-
Tvrtko Ursulin authored
Merge tag 'drm-intel-next-2022-05-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-gt-next drm/i915 drm-intel-next -> drm-intel-gt-next cross-merge sync Signed-off-by:
-
