- 19 Dec, 2023 40 commits
-
-
Matthew Auld authored
xe_ttm_stolen_cpu_inaccessible() was originally meant to just cover the case where stolen is not directly CPU accessible on some older integrated platforms, and as such a GGTT mapping was also required for CPU access (as per the check in xe_bo_create_pin_map_at()). However with small-bar systems on dgfx we have one more case where stolen is also inaccessible, however here we don't have any fallback GGTT mode for CPU access. Fix the check in xe_bo_create_pin_map_at() to make this distinction clear. In such a case the later vmap() will fail anyway. v2: fix kernel-doc warning v3: Simplify further and remove cpu_inaccessible() Suggested-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
Looks to have been introduced in some very recent changes, in-between merging the driver wide s/lmem/vram/. Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Riana Tauro authored
The overflow caused xe_bo_restore_kernel to return an error Fix overflow in vram manager alloc function. Signed-off-by:
Riana Tauro <riana.tauro@intel.com> Reviewed-by:
-
Jani Nikula authored
Be careful about having const in the compound literal initialization to keep the initializers in rodata. Here, the impact is 1.8k of mutable data moved to rodata. add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-1804 (-1804) Data old new delta __compound_literal 1804 - -1804 Total: Before=42425, After=40621, chg -4.25% add/remove: 0/0 grow/shrink: 1/0 up/down: 1804/0 (1804) RO Data old new delta __compound_literal 7696 9500 +1804 Total: Before=138535, After=140339, chg +1.30% Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230309121746.479146-1-jani.nikula@intel.comSigned-off-by:
-
Lucas De Marchi authored
The PVC pre-production A* steppings are not going to be supported in xe driver - the steppings are important for the WAs and since we are not adding the pre-productions ones, there is no need to add the stepping. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Lucas De Marchi authored
This makes it easier when printing the register-save-restore values to know what is the engine. Signed-off-by:
-
Lucas De Marchi authored
The dump function was originally added with the idea that it could be re-used both for printing the reg-sr data and saving it to pass to GuC via ADS. This was not used by the GuC integration, so remove it now to give place to a new debug. Signed-off-by:
-
Lucas De Marchi authored
This allows to create WA/tuning rules that match the first engine that is either of compute or render class. This matters for platforms that don't have a render engine and that may have arbitrary compute engines fused off: some register programming need to be added to one of those engines. Signed-off-by:
-
Lucas De Marchi authored
Match functions are generally useful for other parts of the code (e.g. xe_tuning.c). Move and rename the single one available to create a place where similar match functions can be added. Signed-off-by:
-
Lucas De Marchi authored
Due to how xe_dss_mask_t is implemented, the type is a pointer. Since this is only used for looking up the bits, make it const so it can be used together with a const gt passed around. Signed-off-by:
-
Lucas De Marchi authored
Replace the inline function with a _Generic() so gt_to_xe() can work with a const struct xe_gt*, which leads to a const struct xe *. This allows a const gt being passed around and when the xe device is needed, compiler won't issue a warning that calling gt_to_xe() would discard the const. Rather, just propagate the const to the xe pointer being returned. Signed-off-by:
-
Lucas De Marchi authored
Add a sentence about the initialization so it's clear for newcomers how to tweak the init functions for new platforms. Signed-off-by:
-
Lucas De Marchi authored
Some register ranges with replication type L3BANK were missing from the driver table. The following warning was triggering when adding a workaround touching the register 0xb188: xe 0000:03:00.0: Did not find MCR register 0xb188 in any MCR steering table Add the L3BANK ranges according to the spec. v2: - Fix typo in one of the ranges: s/0x00BCFF/0x008CFF/ (Matt Roper) - Add termination rule in the init function for L3BANK (Matt Roper) Bspec: 66534 Signed-off-by:
-
Thomas Hellström authored
Fix the below warning by using the correct vma destroy sequence: [ 92.204921] ------------[ cut here ]------------ [ 92.204954] WARNING: CPU: 3 PID: 2449 at drivers/gpu/drm/xe/xe_vm.c:933 xe_vma_destroy+0x280/0x290 [xe] [ 92.205002] Modules linked in: ccm nft_objref cmac nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set nf_tables nfnetlink ip6table_filter iptable_filter bnep sunrpc vfat fat iwlmvm mac80211 intel_rapl_msr ee1004 ppdev intel_rapl_common snd_hda_codec_realtek libarc4 iTCO_wdt snd_hda_codec_generic intel_pmc_bxt x86_pkg_temp_thermal iTCO_vendor_support intel_powerclamp coretemp intel_cstate iwlwifi btusb btrtl btbcm snd_hda_intel btintel snd_intel_dspcfg eeepc_wmi snd_hda_codec asus_wmi bluetooth snd_hwdep snd_seq ledtrig_audio snd_hda_core snd_seq_device sparse_keymap cfg80211 snd_pcm intel_uncore joydev platform_profile mei_me wmi_bmof intel_wmi_thunderbolt snd_timer pcspkr ecdh_generic i2c_i801 snd [ 92.205060] ecc mei rfkill soundcore idma64 i2c_smbus parport_pc parport acpi_pad acpi_tad xe drm_ttm_helper ttm i2c_algo_bit drm_suballoc_helper kunit drm_buddy gpu_sched drm_display_helper drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel nvme nvme_core e1000e ghash_clmulni_intel drm_panel_orientation_quirks video wmi pinctrl_tigerlake usb_storage ip6_tables ip_tables fuse [ 92.205242] CPU: 3 PID: 2449 Comm: xe_vm Tainted: G U 6.1.0+ #120 [ 92.205254] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 92.205266] RIP: 0010:xe_vma_destroy+0x280/0x290 [xe] [ 92.205299] Code: 74 15 48 8b 93 a0 01 00 00 48 8b 83 a8 01 00 00 48 89 42 08 48 89 10 4c 89 ab a0 01 00 00 4c 89 ab a8 01 00 00 e9 1b fe ff ff <0f> 0b e9 a3 fe ff ff 0f 0b e9 82 fe ff ff 66 90 0f 1f 44 00 00 48 [ 92.205322] RSP: 0018:ffffaadd465c3a58 EFLAGS: 00010246 [ 92.205331] RAX: 0000000000000000 RBX: ffff9706d53ed400 RCX: 0000000000000001 [ 92.205341] RDX: ffff9706d53ed480 RSI: ffffffffa756dc2b RDI: ffffffffa760a05e [ 92.205351] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000002c5370a2 [ 92.205361] R10: ffff9706ca520000 R11: 0000000022c5370a R12: ffff9706cad03800 [ 92.205370] R13: 000000000004ffff R14: fffffffffffffff2 R15: 0000000000000000 [ 92.205380] FS: 00007fe98203a940(0000) GS:ffff970dffac0000(0000) knlGS:0000000000000000 [ 92.205392] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 92.205400] CR2: 00007fe982ccb000 CR3: 000000010d6e6003 CR4: 0000000000770ee0 [ 92.205410] PKRU: 55555554 [ 92.205415] Call Trace: [ 92.205419] <TASK> [ 92.205426] vm_bind_ioctl_lookup_vma+0x9bb/0xbf0 [xe] [ 92.205461] ? lock_is_held_type+0xe3/0x140 [ 92.205472] ? xe_vm_find_overlapping_vma+0x77/0x90 [xe] [ 92.205503] ? __vm_bind_ioctl_lookup_vma.constprop.0+0x9e/0xe0 [xe] [ 92.205533] ? __lock_acquire+0x3a3/0x1fb0 [ 92.205543] ? register_lock_class+0x38/0x480 [ 92.205550] ? __lock_acquire+0x3a3/0x1fb0 [ 92.205558] ? __lock_acquire+0x3a3/0x1fb0 [ 92.205567] ? __lock_acquire+0x3a3/0x1fb0 [ 92.205579] ? lock_acquire+0xbf/0x2b0 [ 92.205586] ? lock_acquire+0xcf/0x2b0 [ 92.205597] xe_vm_bind_ioctl+0x977/0x1c30 [xe] [ 92.205630] ? find_held_lock+0x2b/0x80 [ 92.205640] ? lock_release+0x131/0x2c0 [ 92.205648] ? xe_vm_ttm_bo+0x40/0x40 [xe] [ 92.205677] drm_ioctl_kernel+0xa1/0x150 [drm] [ 92.205706] drm_ioctl+0x221/0x420 [drm] [ 92.205727] ? xe_vm_ttm_bo+0x40/0x40 [xe] [ 92.205764] __x64_sys_ioctl+0x8d/0xd0 [ 92.205774] do_syscall_64+0x37/0x90 [ 92.205781] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 92.205790] RIP: 0033:0x7fe982be8d6f [ 92.205797] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 92.205821] RSP: 002b:00007ffde9f9c560 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 92.205832] RAX: ffffffffffffffda RBX: 00007fadeadbe000 RCX: 00007fe982be8d6f [ 92.205842] RDX: 00007ffde9f9c5f0 RSI: 0000000040786445 RDI: 0000000000000003 [ 92.205851] RBP: 00007ffde9f9c5f0 R08: 00007fadeadbe000 R09: 0000000000040000 [ 92.205861] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000040786445 [ 92.205871] R13: 0000000000000003 R14: 0000000000000003 R15: 00007fe982e02000 [ 92.205888] </TASK> [ 92.205892] irq event stamp: 82723 [ 92.205897] hardirqs last enabled at (82731): [<ffffffffa617660e>] __up_console_sem+0x5e/0x70 [ 92.205910] hardirqs last disabled at (82738): [<ffffffffa61765f3>] __up_console_sem+0x43/0x70 [ 92.205922] softirqs last enabled at (82182): [<ffffffffa60f026d>] __irq_exit_rcu+0xed/0x160 [ 92.205935] softirqs last disabled at (82163): [<ffffffffa60f026d>] __irq_exit_rcu+0xed/0x160 [ 92.205947] ---[ end trace 0000000000000000 ]--- Reported-by:
Francois Dugast <francois.dugast@intel.com> Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Matt Roper authored
For Xe_HP platforms that can have multiple CCS engines, the presence/absence of each CCS is inferred by the presence/absence of any DSS in the corresponding quadrant of the GT's DSS mask. This handling is only needed on platforms that can have more than one CCS. The CCS is never fused off on platforms like MTL that can only have one. v2: - Add extra warnings to try to catch mistakes where the register counts in get_num_dss_regs() are updated without corresponding updates to the register parameters passed to load_dss_mask(). (Lucas) - Add kerneldoc for xe_gt_topology_has_dss_in_quadrant() and clarify why we care about quadrants of the DSS space. (Lucas) - Ensure CCS engine counting treats engine mask as 64-bit. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Matt Roper authored
The single function to handle fuse registers for all types of engines is becoming a bit long and hard to follow (and we haven't even added the compute engines yet). Let's split it into dedicated functions for each engine class. v2: - Add note about BCS0 always being present. (Bala) - Add forcewake assertion to read_copy_fuses. (Bala) Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
-
Matthew Auld authored
This seems to be the preferred nomenclature in xe. Currently we are intermixing vram and lmem, which is confusing. v2 (Gwan-gyeong Mun & Lucas): - Rather apply to the entire driver Signed-off-by:
-
Matt Roper authored
Checking whether a single engine's register save/restore entries overflow the expected/pre-allocated GuC ADS regset area isn't terribly useful; we actually want to check whether the combined entries from all engines on the GT overflow the regset space. Reviewed-by:
-
Nirmoy Das authored
The address set by firmware in GEN12_DSMBASE in driver initialization doesn't mean "anything above that and until end of lmem is part of DSM". In fact, there may be a few KB that is not part of DSM on the end of lmem. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size down. Suggested-by:
Nirmoy Das <nirmoy.das@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Update xe_migrate_doc.h with 32 page table structs (not 48) v2: minor typo fix Signed-off-by:
-
Thomas Hellström authored
It appears we don't hold a memory access reference for the accesses in this test, which may results in printed warnings and possibly the GT not woken up for the memory accesses. Add a memory access reference around the test. Signed-off-by:
-
Thomas Hellström authored
We currently don't have any tests that explicitly depends on this config option, so remove that build dependency. Signed-off-by:
-
Lucas De Marchi authored
When this register was added in xe for some workarounds, it was copied from i915 before the registers got changed to add the MCR annotation. The register 0xe4f4 is MCR since gen8, long before any GPU supported by the xe driver. Replace all occurrences with the right register. Signed-off-by:
-
Lucas De Marchi authored
The following warning shows up for TGL: [drm:xe_reg_sr_add [xe]] *ERROR* Discarding save-restore reg 6604 (clear: 00ff0000, set: 00040000, masked: no): ret=-22 [drm:xe_reg_sr_add [xe]] *ERROR* Discarding save-restore reg 6604 (clear: 00ff0000, set: 00040000, masked: no): ret=-22 That is because the same register is being set both by the WAs and the tunings. Like was done in i915, prefer the tuning over the workaround since that is applicable for more platforms. Also fix the tuning: it was incorrectly using the MCR version of the register, but that only became true in XEHP. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/233Reported-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
XE_MAX_DSS_FUSE_REGS was being used to calculate the size of xe_eu_mask_t while it should use XE_MAX_EU_FUSE_REGS. There are no know issues about this but fixing it anyways. Reviewed-by:
-
Lucas De Marchi authored
Fix typo as noticed by Matt Roper: git grep -l persitent | xargs sed -i 's/persitent/persistent/g' ... and then fix coding style issues. Signed-off-by:
-
Lucas De Marchi authored
There's inconsistent use of mutex_init(), in xe_device_create(), with several of them never calling mutex_destroy() in xe_device_destroy(). Migrate all of them to drmm_mutex_init(), so the destroy part is automatically called. Signed-off-by:
-
Matthew Auld authored
In the depths of ttm, when allocating the vma node this should result in -ENOSPC it seems. However we should probably rather reject as part of our own ioctl sanity checking, and then treat as programmer error in the lower levels. Signed-off-by:
-
Matthew Auld authored
With small-bar we likely want to annotate all the kernel users that require CPU access with vram. If xe_bo_create_pin_map() is the central place for that then we should have a central place to annotate. This also simplifies the code and fixes what appears to be a double xe_bo_put(hwe->hwsp) in the error handling. Signed-off-by:
-
Matt Roper authored
The HAS_RENDER_L3CC is set unconditionally so there's no need to keep it as a dedicated flag. For error checking purposes, we can just make sure the 'table' field is initialized properly. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by:
-
Matt Roper authored
Reprogramming the LNCF MOCS registers on render domain reset is not intended to be regular driver programming, but rather the implementation of a specific workaround (Wa_1607983814). This workaround no longer applies on Xe_HP any beyond, so we can expect that these registers, like the rest of the LNCF/LBCF registers, will maintain their values through all engine resets. We should only add these registers to the GuC's save/restore list on platforms that need the workaround. Furthermore, xe_mocs_init_engine() appears to be another attempt to satisfy this same workaround. This is unnecessary on the Xe driver since even on platforms where the workaround is necessary, all single-engine resets are initiated by the GuC and thus the GuC will take care of saving/restoring these registers. The only host-initiated resets we have in Xe are full GT resets which will already (re)initialize these registers as part of the regular xe_mocs_init() flow. v2: - Add needs_wa_1607983814() so that calculate_regset_size() doesn't overallocate regset space when the workaround isn't needed. (Lucas) - On platforms affected by Wa_1607983814, only add the LNCF MOCS registers to the render engine's GuC save/restore list; resets of other engines don't need to save/restore these. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Philippe Lecluse authored
It was incorrectly using dg2_mocs for now. v2 (MattR): - Use REG_GENMASK/REG_FIELD_PREP for bitfields - Add bspec references Bspec: 45101, 45410, 63882 Signed-off-by:
Philippe Lecluse <philippe.lecluse@intel.com> Signed-off-by:
-
Matt Roper authored
The DG1 branch needlessly assigns uc_index twice. Drop the second instance. Signed-off-by:
-
Matt Roper authored
The values in the xe_mocs_info_index enum only match old pre-gen12 hardware not supported by the Xe driver. The only usage of this enum was to set a default value for info->unused_entries_index, but this is unnecessary since every platform in the subsequent switch statement sets a proper platform-specific value (and the XE_MOCS_PTE default doesn't even make sense since the hardware dropped the "use PAT settings" capability in gen12). v2: - Add a check that unusued_entries_index is non-zero; even for platforms where this is a valid table entry, it's never the one we want this value assigned to. (Lucas) Signed-off-by:
-
Matt Roper authored
RKL should use the same "gen12" MOCS handling as TGL/ADL-S/ADL-P. Bspec: 45101 Signed-off-by:
-
Matt Roper authored
TGL/RKL/ADLS/ADLP are all supposed to use the same MOCS table, with values defined in the bspec. Any entries listed in the bspec as reserved/error/undefined should always be initialized to the most cached and least coherent setting possible so that any userspace accidentally referencing those undefined entries will only experience an increase in coherency if spec updates down the road start defining real values. The TGL and gen12 table entries defined in the driver today are identical except that the TGL includes one additional (incorrect) setting for table index 1. Furthermore, the TGL-specific initialization does not define a dedicated value for info->unused_entries_index, so this incorrect table entry 1 also gets used to populate the MOCS registers for all reserved/unused table entries. This incorrect behavior is a holdover from i915 where the platform was enabled with an incorrect setting and by the time we noticed, it was too late to fix the table without breaking ABI compatibility (and on TGL we did indeed have some buggy userspace that was referencing the 'reserved' entry 1). Since the Xe driver starts fresh with a clean slate on ABI, there's no need to repeat the mistakes of i915 here. v2: - Reword/clarify commit message. (Lucas) Bspec: 45101 Signed-off-by:
-
Lucas De Marchi authored
Reduce the use of i915_reg_defs.h so it can be encapsulated in a single place. 1) If it was being included by mistake, remove 2) If it was included for FIELD_GET()/FIELD_PREP()/GENMASK() and the like, just include <linux/bitfield.h> 3) If it was included to be able to define additional registers, move the registers to the relavant headers (regs/xe_regs.h or regs/xe_gt_regs.h) v2: - Squash commit fixing i915_reg_defs.h include and with the one introducing regs/xe_reg_defs.h - Remove more cases of i915_reg_defs.h being used when all it was needed was linux/bitfield.h (Matt Roper) - Move some registers to the corresponding regs/*.h file (Matt Roper) Signed-off-by: -
Lucas De Marchi authored
Keep header guards consistent with regard to ifdef used. Prefer the more commonly used in the driver. $ git grep "ifndef __XE_" -- drivers/gpu/drm/xe | wc -l 8 $ git grep "ifndef _XE_" -- drivers/gpu/drm/xe | wc -l 112 Signed-off-by:
-
Lucas De Marchi authored
The only thing really needed is the base offset, MCHBAR_MIRROR_BASE_SNB. Remove the include and just define it inplace. Signed-off-by:
-
Lucas De Marchi authored
Move a few defines from xe_guc_pc.c to the right register, now that there is one: xe_gt_regs.h. Signed-off-by:
-
